fix: keep native context menus open when long-pressing sortable items#585
Open
MatiPl01 wants to merge 8 commits into
Open
fix: keep native context menus open when long-pressing sortable items#585MatiPl01 wants to merge 8 commits into
MatiPl01 wants to merge 8 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
MatiPl01
force-pushed
the
fix/context-menu-long-press
branch
from
03a7ddc to
40add4d
Compare
github-actions
Bot
added
dependencies
Gate the pickup scale/shadow and the transform-based layout on activeItemBroughtToFront, so a bare long press leaves the item untouched (letting a native context menu lift it) while a real drag is unchanged. Ramp the pickup in on drag start so it still animates up smoothly.
…u for the flat one react-native-context-menu-view gives a real UIContextMenuInteraction lift; it is patched (.yarn/patches) to lift a separate static preview view rather than the live sortable view, which the New Architecture snaps mid-interaction. @react-native-menu/menu replaces zeego for the flat example (zeego's iOS backend cannot run on RN 0.86).
Sort props and imports to satisfy react/jsx-sort-props and simple-import-sort, and give the no-op menu handlers a comment body so no-empty-function passes.
The example no longer patches the library. Removing the patch also removes the custom preview + onLayout measurement that only existed to feed it; the plain card still lifts and stays via the stock library, and the sortable item keeps the small scale-down settle documented in the file header.
Move both native context menu demos out of the Features category into a single Context Menu screen under Test examples, with a top tab switching between @react-native-menu/menu and react-native-context-menu-view. Give the native-lift cards an explicitly sized preview so they no longer collapse (disappear) when the OS lifts them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #417. Supersedes #576.
A native context menu inside a sortable item's
renderItem(zeego /react-native-ios-context-menu, backed byUIContextMenuInteractionon iOS) was dismissed the instant you long pressed it: the sortable elevates the item's zIndex on long press, and that stacking-context change closes the menu.This defers the "bring to front" zIndex change until the item is actually dragged (moved past
dragActivationFailOffset), so a plain long press no longer touches the stacking context and the menu stays open, while a real drag still elevates exactly as before.It also exposes
isDraggingon the item context (useItemContext) - true once the active item is actually dragged rather than just long pressed - so consumers can disable interactive children (a context menu, buttons, ...) while dragging.A new "Context Menu" example under Sortable Grid demonstrates the pattern with zeego: the menu opens on a stationary long press and is dismissed the moment the item starts moving, and dragging still reorders.
Verified on an Android emulator and a physical device (New Architecture, RN 0.85): hold opens the native menu and the item animates; starting a drag dismisses/prevents the menu and reorders; a plain long press never dismisses the menu. The drag-time dismissal is done consumer side (drop the menu when
isDraggingflips) since gesture-handler cannot reliably cancel a foreign native long press on activation.