Resize handle jumps around

[cloudkite]

Thanks for this amazing library!

Noticed a small bug/weird behaviour that seems to only happen when you have a collapsed panel:

When dragging a resize handle that is to the right of a collapsed panel the resize handle will jump back to its starting drag position when the panel exceeds its maxSize. Would expect it to stop at the maxSize rather than jumping back to the starting position. I think this would be a better user experience as the jump is quite jarring at the moment

https://codesandbox.io/p/sandbox/react-resizable-panels-forked-fsmcvz?file=%2Fsrc%2FApp.js

CleanShot.2024-03-01.at.21.30.50.mp4

[bvaughn]

That sandbox link does not work.

[cloudkite]

Sorry forgot to make it public, should be accessible now.

[bvaughn]

Got it. Thank you. This is a bug, for sure.

I think the behavior is due to first panel's configuration:

<Panel
  defaultSize={4}
  collapsedSize={4}
  collapsible={true}
  minSize={15}
  maxSize={20}
>

Here is how this library works, at a high level. First, the constraints:

• Resizing one panel always impacts other panels. (In other words, you can't make one panel so big that it causes another panel to shrink below its minimum size.)
• Once you've dragged a resize handle past the min/max size of the panel you're resizing, other panels begin to grow/shrink. (I think this feels more intuitive.) For example, notice how dragging the first resize handle resizes the 3rd panel as well:
• If you reverse drag direction, any resized panels should return toward their original sizes (aka the same resize in reverse)

The above points can be seen with this example group in the video below:

 <PanelGroup direction="horizontal">
   <Panel defaultSize={30} minSize={20}>
     left
   </Panel>
   <PanelResizeHandle />
   <Panel minSize={30}>
     middle
   </Panel>
   <PanelResizeHandle />
   <Panel defaultSize={30} minSize={20}>
     right
   </Panel>
 </PanelGroup>

Kapture.2024-03-02.at.08.16.47.mp4

Okay, so how is the above behavior implemented (particularly the 3rd bullet):

• When a drag starts, this library stores the starting coordinates and group layouts
• As the cursor moves, the delta is (re)applied to the starting layout. (This has the benefit of "rewinding" in the exact same way if you reverse the drag.)
• If a drag delta can't be applied to the group because of min/max constraints (aka if the new sizes don't add up to 100%) the drag is rejected and no change is applied

The third bullet above is what's causing the issue you've reported. There is a certain range of drag that produces an invalid layout because of the first panel's collapsed and minimum size constraints. (Basically that panel stays collapsed until it is greater than ~9.5% width, the mid point between its collapsed size of 4% and its minimum size of 15%.)

I think the problem is that the invalid layout at that delta causes the group to fall back to the original layout (rather than the most recent valid layout). That's kind of an oversight on my part. Having this repro should be enough to help me track it down.

In case it's easier to see this by looking at actual code, I recorded a Replay of this (3ae6f833-4e3b-4ad6-b10b-8392b85b4bb2) with comments showing what I explained above.

[bvaughn]

I think I've fixed it, but I need to do some more testing (at least write some regression tests)

Kapture.2024-03-02.at.08.43.05.mp4

[bvaughn]

Fixed in #312 and published as 2.0.12

---

❤️ → ☕ givebrian.coffee

[cloudkite]

☕️☕️☕️❤️

[bvaughn]

Thanks!🙏