feat/better overlays - #147
Merged
Merged
Conversation
✅ Deploy Preview for rnst-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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.
Motivation
Overlays were originally introduced as a way to keep UI—such as navigation controls, onboarding actions, or persistent branding—floating above a stack while screens transition underneath. The original implementation worked, but it treated overlays as an extension of the regular screen stack and rebuilt much of the screen’s provider tree at the floating layer. This made overlays more expensive than necessary and introduced lifecycle problems, including state resetting when an overlay host remounted.
Animating overlays was also awkward. Users had to call
useScreenAnimation()inside the overlay and manually recreate behavior that already belonged in the screen interpolator. Screens with overlays separated by ordinary screens had no clear transition relationship.This change gives overlays their own sparse stack. Given:
the overlay transition order becomes:
The destination screen’s interpolator can now return an
overlayslot to animate the adjacent overlays. Screens without overlays may also control the currently visible overlay without replacing it.The floating host now reuses the animation and style stores created by the overlay’s owning screen instead of constructing another provider pipeline. This keeps overlays mounted while their route remains in the stack, preserves local component state, and allows
useScreenAnimation()and transitionstyleIds to resolve against the correct owner.The pull request also aligns repeated programmatic dismissals with gesture dismissals, narrows several provider subscriptions, adds lifecycle and adjacency coverage, and documents the new overlay contracts.