Skip to content

4.1.2

Choose a tag to compare

View all tags
@gfazioli gfazioli released this 12 May 12:29
· 54 commits to master since this release
4.1.2
b0c6b56

Note

This changelog rolls up two consecutive patch releases — 4.1.1 (children typing on Split.Resizer) and 4.1.2 (correct lifecycle callbacks on double-click reset, plus a subtle drag-state fix). Public API signatures of Split, Split.Pane, and Split.Resizer are unchanged. The only knob worth noting is that onResizing / onResizeEnd now also fire after a double-click reset — see Behavioral notes below.

Both releases ship fixes for issues reported by @enisdenjo. v4.1.2 also lands a community PR from @mturac. Thanks both! 🙌

✨ Features

1. Custom content inside Split.Resizer

Split.Resizer already rendered an UnstyledButton under the hood and spread its rest props through, so children always reached the DOM at runtime — but the public type rejected them. From v4.1.1, SplitResizerBaseProps declares children?: React.ReactNode, so TypeScript no longer complains when you put a drag-affordance icon, a label, or a fully custom visual handle inside the resizer.

import { Split } from '@gfazioli/mantine-split-pane';
import { Center } from '@mantine/core';
import { IconGripVertical } from '@tabler/icons-react';

<Split.Resizer>
  <Center h="100%">
    <IconGripVertical size={14} stroke={1.5} />
  </Center>
</Split.Resizer>;

Pair with withKnob={false} on the parent <Split> (or on the individual resizer) if you want your content to replace the default knob entirely.

Closes #45.

2. notifyResizing / notifyResizeEnd on SplitPaneHandlers

Two new methods on the Split.Pane imperative handle (the type exposed by SplitPaneHandlers):

  • notifyResizing(size) — forwards size to the consumer's onResizing prop without updating the pane's internal drag tracking.
  • notifyResizeEnd(size) — same, for onResizeEnd.

Used internally by Split.Resizer to emit lifecycle events after a double-click reset without re-marking the pane as dragged. Public on the handle for advanced cases where you build custom resizer choreography and want the same separation between "fire the user callback" and "treat this as a real drag".

🐛 Fixes

1. onResizing and onResizeEnd now fire on double-click reset

A double-click on the resizer has always reset both adjacent panes to their initialWidth / initialHeight values, but the lifecycle callbacks stayed silent — onResizeEnd only fired after a real mouse-up / touch-end drag. Consumers tracking pane dimensions had to bolt on an onDoubleClick listener to learn about the reset.

From v4.1.2, both onResizing and onResizeEnd fire once after the reset settles:

  • On Split.Resizer, with { beforePane, afterPane } carrying the post-reset sizes.
  • On each adjacent Split.Pane, with that pane's own { width, height }.

Closes #44. Initial fix landed via community PR #47 by @mturac.

2. Double-click reset no longer cancels itself across container resizes

A subtle bug spotted during code review: the pane-level onResizeEnd imperative handle does double duty — it both updates dragRatioRef / hasBeenDraggedRef (so the pane keeps its proportional size on container resize) and fires the consumer's onResizeEnd prop. Calling it from the new double-click path re-marked the just-reset pane as "dragged" with the reset ratio, which silently undid the reset on the next container resize.

The fix decouples bookkeeping from callback emission via the new notifyResizing / notifyResizeEnd methods (see New Features above). The regular mouse-up / touch-end paths still use the old onResizeEnd handle method, because in those cases the drag bookkeeping is correct — the user really did drag.

Note

If you observed double-click resets "snapping back" to the dragged size after the browser window changed shape, this is what was happening. v4.1.2 keeps the reset stable across container resizes.

📝 Docs

  • New Custom Resizer Content section in the docs with a dedicated resizerContent demo: three panes separated by two resizers, each carrying a different Tabler icon as a drag handle.
  • Reset with Double Click section rewritten to document the new lifecycle emission and the persistence-across-container-resize guarantee.
  • Both onResizeStart, onResizing, and onResizeEnd events sections (one under Split.Resizer, one under Split.Pane) gained a note about the double-click reset trigger.
  • Upgrade guide (migrations.mdx) gained v4.1.2 and v4.1.1 entries explaining the silent behavior change on lifecycle callbacks and the additive children typing.
  • README feature list now mentions custom resizer content and that the lifecycle events fire on drag, keyboard resize, and double-click reset.

🔧 Internal

  • Regression test for the resizer-level onResizing / onResizeEnd emission after double-click (fires onResizing and onResizeEnd after a double-click reset with the post-reset pane sizes).
  • Regression test for the pane-level forwarding (forwards onResizing and onResizeEnd to each Split.Pane after a double-click reset).
  • Type test ensuring <Split.Resizer>...</Split.Resizer> compiles (renders custom children passed to Split.Resizer).
  • Full Jest suite: 30/30 passing.

Behavioral notes

If your onResizeEnd handler previously assumed "this only fires after a real drag", you will now receive an extra call on every double-click reset. The new call carries the correct post-reset sizes, so the typical fix is no-op. If you keep state machinery keyed off "drag happened" (e.g. dirty-flagging a layout), branch on onDoubleClick instead — that callback fires only when the user actually double-clicks.

The pane's internal drag tracking is intentionally not updated by the new emission, so percentage-based pane sizes will continue to recalculate from initialWidth / initialHeight on container resize after a double-click reset, just as they did before lifecycle events were wired up.

Summary

Two patch releases addressing two distinct reports from @enisdenjo: TypeScript now lets you put arbitrary content inside Split.Resizer (v4.1.1, always worked at runtime), and a double-click reset now fires onResizing / onResizeEnd on the resizer and on each adjacent pane with the post-reset sizes (v4.1.2). A subtle drag-state interaction that would have silently undone the reset on the next container resize was caught by Copilot's review and fixed via two new imperative methods (notifyResizing / notifyResizeEnd) on SplitPaneHandlers. No public API signatures change.

What's Changed

  • fix(resizer): fire onResizing and onResizeEnd on double-click reset by @mturac in #47

New Contributors

Full Changelog: 4.1.1...4.1.2

Contributors

mturac
Assets 2
Loading