-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Transitions block page navigation #6686
Comments
Transitions and navigation have always been a pain. Nobody wants to see two pages at once, piled on top of eachother, whilst waiting for a transition to finish - it's unexpected. To my mind:
If we made the above change, page transitions in SvelteKit would be as seamless and easy as transitions in Svelte are generally. |
About that, we had a little conversation in discord with Brady Fractal and navigation is not only the use case which transitions are painful. I'm using Today there is only Would this granularity be possible one day, according to Svelte's design ? |
I totally agree with @7antra based on my experience the "navigation" it's not equal to page changes. |
it seems related to "conditional transition" |
To make them global, add the |global modifier This is a breaking change closes #6686
To make them global, add the |global modifier This is a breaking change closes #6686
|
Just read the docs, this and another issue about
I really didn't get the point, I am happy to take local as new default but would love to understand it better since I've never had any problems with page navigation and transitions (maybe because I use always |
# Motivation Svelte transitions are executed by default in components regardless if their parent components destroy those or not. This behavior is known as the `|global` transitions setting and is the default in Svelte v3. This leads to issue with the SvelteKit navigation because DOM elements might not be detached and related context might remain active. We generally notice the issue in NNS dapp after navigation when the DOM wrongly contains two `split-pane` elements. In Svelte v4 the default behavior was changed to `|local`. Setting that can already be used in v3 when explicitely set. This setting has for effect to not execute the transition and destroy the components if parents destroy those. i.e. to populate the destroy. # References - documentation: https://svelte.dev/docs/v4-migration-guide#transitions-are-local-by-default - svelte issue: sveltejs/svelte#6686 # Changes - scope all transitions of Svelte to `|local`
# Motivation Svelte transitions are executed by default in components regardless if their parent components destroy those or not. This behavior is known as the `|global` transitions. This leads NNS dapp to various issues in which components are not destroyed and therefore, there context remains active. Until today we solved this by applying a workaround in which we destroyed the all layout in case of navigation. While it solved the issue, this had for side effect to be a bit unpleasant for the eyes as the all page layout disappeared on navigation. By setting all the animation to `|local` we can solve the issue and make the navigation more fluid. # References - documentation: https://svelte.dev/docs/v4-migration-guide#transitions-are-local-by-default - svelte issue: sveltejs/svelte#6686 # PRs - [x] dfinity/gix-components#246 # Previous issues - #1741 - #2861 # Changes - update gix-cmp to set `|local` to any Svelte transitions - set `|local` to the Svelte animations implemented in NNS dapp - remove detail page layout navigating guard # Notes In the login page we will continue to observe `$navigating` because this condition was not only used to solve the issue but, also to present a spinner while the application is loading.
Describe the problem
Transitions can block page navigation if
|local
is not set (sveltejs/kit#628)Describe the proposed solution
Consider whether to make
|local
the default for transitionsAlternatives considered
I couldn't think of another solution
Importance
would make my life easier
The text was updated successfully, but these errors were encountered: