Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: resize should not fail when dragState is null #224

Closed

Conversation

tsufiev
Copy link

@tsufiev tsufiev commented Dec 4, 2023

Resolves #223

Copy link

vercel bot commented Dec 4, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
react-resizable-panels ✅ Ready (Inspect) Visit Preview 💬 Add feedback Dec 6, 2023 4:09pm

@tsufiev
Copy link
Author

tsufiev commented Dec 4, 2023

I have to agree that guarding against nullish dragState so deep in the logic is not ideal, since most likely the root cause lies somewhere inside PanelResizeHandle.ts file. I presume that getting nullish dragState in the code that handles panel resizing means that resizeHandler has been invoked without the prior invocation of startDragging. However due to the overall logic of binding and unbinding event listeners inside PanelResizeHandle.ts being a bit convoluted, I cannot understand when and why that happens :/.

@tsufiev tsufiev force-pushed the fix-destructuring-null-drag-state branch from 692ca08 to 71a8cb2 Compare December 6, 2023 16:08
@tsufiev tsufiev changed the title fix: reliably process initialDragState when it's null fix: resize should not fail when dragState is null Dec 6, 2023
@tsufiev
Copy link
Author

tsufiev commented Dec 6, 2023

@bvaughn I've managed to reproduce the issue 2 times out of ~100, so it's quite rare. Both times it happened during dragging the panel to collapsed state. The attempt of resize while dragState stored in committedValuesRef is null happens inside onMove handler.

My mental picture of this is that when resize handle gets released and cursor is moved at the same time, sometimes the onMove handler gets one more chance to get executed before useEffect clean-up code kicks in and removes all the listeners.

@bvaughn
Copy link
Owner

bvaughn commented Dec 6, 2023

Interesting. Would be super nice to capture a case of this happening in Replay.

@bvaughn bvaughn mentioned this pull request Dec 10, 2023
7 tasks
@bvaughn
Copy link
Owner

bvaughn commented Dec 10, 2023

Cherry picking this change into my release branch caused 11 e2e tests to fail (same as with CI).

This highlights that there are several triggers for resize actions, and drag is only one of them. This change would effectively block keyboard and imperative API resizes.

I will think on this change some more before the v1 release but we can't land the thing proposed here.

Edit ddb4a52

@bvaughn bvaughn closed this Dec 10, 2023
bvaughn added a commit that referenced this pull request Dec 13, 2023
Checklist:
- [x] Remove pixel size constraints
- [x] Replaced `dataAttributes` prop with ...rest (to support all
HTMLAttributes)
- [x] Review and pull in changes from open PRs:
  - [x] #228
  - [x] #224
- [x] Audit open issues and close ones that are no longer releveant
- [x] Remove any unnecessary async initialization logic necessitated by
pixel constraints

I think this library's feature set is stable enough in my mind for a 1.0
release. It might be controversial but I have decided to cut pixel-based
constraints from that release as they added too much complexity to the
initialization and validation logic.

---------

Co-authored-by: Timur Sufiev <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants