Closed psychedelicious closed 10 months ago
Between the first and second passes in validatePanelGroupLayout, remainingSize ends up negative. I suppose this results in resizePanel deciding there isn't enough room and saying the new final size is 0. Maybe the pixel-constrained panels need first dibs on remaining space? I'm a bit lost, this deep in the logic.
It's possible this issue was being caused by a floating point precision issue. I've tried to better account for that (in an upcoming release) by using .toFixed
when distributing drag delta across a group of panels.
I left a comment on the Replay.
tl;dr I don't know if I'm going to fix this because I think it's mostly only likely to occur with pixel layouts, and I'm going to drop pixel support. It ended up being more work than I think I have the bandwidth to support, and I don't personally need it in any of my projects.
Going to close this issue since I don't plan to take action on it. Happy to continue talking here though.
Dropping support for pixel layouts is a bummer, but it sounds like the right choice for this library. Thanks for taking the time to try to make it work, and for making the choice to keep the library focused on what it can and does do well.
Thank you so much for understanding 🙏🏼
Previous issue: #210
v63
The problem still occurs, but not immediately when on the first resize event.
https://app.replay.io/recording/unexpected-collapses-on-window-resize-w-pixels--787e207f-0524-48e3-b8f6-a0418ca98587
Also note that later on in the replay, the left panel expands and right panel collapses - same unexpected calculations.
Between the first and second passes in
validatePanelGroupLayout
,remainingSize
ends up negative. I suppose this results inresizePanel
deciding there isn't enough room and saying the new final size is 0. Maybe the pixel-constrained panels need first dibs on remaining space? I'm a bit lost, this deep in the logic.