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

beforeInvalidate and afterInvalidate events #6375

Open
ponderingexistence opened this issue Aug 29, 2022 · 3 comments
Open

beforeInvalidate and afterInvalidate events #6375

ponderingexistence opened this issue Aug 29, 2022 · 3 comments
Labels
feature / enhancement New feature or request
Milestone

Comments

@ponderingexistence
Copy link

ponderingexistence commented Aug 29, 2022

Describe the problem

I have a progress bar at the top of my site that appears upon every navigation that happens client-side (much like the one in kit.svelte.dev). I'm using the beforeNavigate and afterNavigate events to show and then hide the progress bar.

Occasionally I need to call invalidate() to re-run all the load functions (because the authentication status has changed, for example). I would like to show the same loader when the load functions are re-running as well — because when you think about it, running invalidate() is kind of life refreshing the page.

Describe the proposed solution

It would be nice if SvelteKIt provided two other lifecycle functions called beforeInvalidate and afterInvalidate or something along those lines.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

@dummdidumm
Copy link
Member

Something like this would be good, although we would probably make it a store (similar to $navigating) rather than an event because you can't cancel it (you can cancel navigation in beforeNavigate).

@dummdidumm dummdidumm added the feature / enhancement New feature or request label Aug 29, 2022
This was referenced Sep 2, 2022
@Rich-Harris
Copy link
Member

In #6522 we trigger beforeNavigate and afterNavigate for invalidations (you can discriminate based on type), and also set the $navigating store, which makes these additions unnecessary

@Rich-Harris
Copy link
Member

Ignore my previous comment, we ended up not merging that PR. See the discussion therein for details

@Rich-Harris Rich-Harris added this to the post-1.0 milestone Sep 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature / enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants