You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I currently have a situation where I want to invalidate page data while $page.state is currently set to something indicating shallow routing to the same URL. I want to preserve that state upon invalidating data, but doing so also resets $page.state to an empty object.
Describe the proposed solution
As a breaking change, we could decouple these, so that invalidating data keeps $page.state untouched. It would then be the developer's responsibility to call replaceState() to reset $page.state.
Alternatives considered
Alternatively, we could add an option to invalidate()/invalidateAll() to control whether $page.state gets reset. This would be a way to introduce this in a non-breaking way, but it feels off somehow.
Importance
would make my life easier
Additional Information
If we make this an option, and we don't worry about breaking changes, what would we make the default? I'm not sure.
If you're invalidating some data and you've used pushState/replaceState to navigate to a different URL than the one you started on, then that new URL would be getting used to decide what new page to get the data from (I assume?), and so clearing $page.state probably does make sense, so you get the proper, normal version of that page.
On the other hand, if you're using pushState/replaceState to represent a temporary thing that does not get its own URL, then invalidating the data and clearing $page.state causes that state to be lost, as the URL isn't enough to reconstruct the app's current state.
The text was updated successfully, but these errors were encountered:
Describe the problem
I currently have a situation where I want to invalidate page
data
while$page.state
is currently set to something indicating shallow routing to the same URL. I want to preserve that state upon invalidatingdata
, but doing so also resets$page.state
to an empty object.Describe the proposed solution
As a breaking change, we could decouple these, so that invalidating
data
keeps$page.state
untouched. It would then be the developer's responsibility to callreplaceState()
to reset$page.state
.Alternatives considered
Alternatively, we could add an option to
invalidate()
/invalidateAll()
to control whether$page.state
gets reset. This would be a way to introduce this in a non-breaking way, but it feels off somehow.Importance
would make my life easier
Additional Information
If we make this an option, and we don't worry about breaking changes, what would we make the default? I'm not sure.
If you're invalidating some data and you've used
pushState
/replaceState
to navigate to a different URL than the one you started on, then that new URL would be getting used to decide what new page to get the data from (I assume?), and so clearing$page.state
probably does make sense, so you get the proper, normal version of that page.On the other hand, if you're using
pushState
/replaceState
to represent a temporary thing that does not get its own URL, then invalidating the data and clearing$page.state
causes that state to be lost, as the URL isn't enough to reconstruct the app's current state.The text was updated successfully, but these errors were encountered: