-
Notifications
You must be signed in to change notification settings - Fork 4
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
Persisting/restoring data between navigation #5
Comments
What kind of logic do you think it should be implemented? Isn't what you want just a $path subscription? let state = {}
path.subscribe(x=>{
state[path] = saveState()
}) ... or just a popstate event handler? addEventListener('popstate', (event: PopStateEvent) => {
saveFormState()
// ... or restoreFormState()
}); For the specific tabs situation and other small state changes, you can use hash method as shown in the demo. Personally, if form state has changed, I'm more for denying user navigation until they decide if they want to save or discard changes. Otherwise, user keeps navigating,do not realize changes are pending, and ands up forgetting about them. I'd say most applications follow this guidelines, too. I hope you do not mean Elegua should infer all parameters of a page's state by itself and restore them. That would be way off it's scope. |
Maybe PR or, better yet, REPL with an eample would help to explain myself. I'll see what I can do. Side note - would be nice to be able to listen/react to Also it seems you are missing listener for |
Ok, I'll be waiting.
But you can, nothing blocks you from doing that: document.addEventListener('popstate', (event: PopStateEvent) => {
//...
});
Indeed, thanks for pointing it! I've just released v.2.21 with support for it. |
Would this be considered as "out of scope"? #6 It's incredibly simple state persisting/restoring |
Ops, forgot to answer this issue. Thanks for the PR, but I'm declining it this since it's so easy to implement through stores, and it's a very particular use case. I'm not getting this into the core. Btw, there was no need to be offended over the "out of scope" thing. |
Right now this SPA router components lose their state when going backwards in history which makes it behave differently than most browsers, where going backwards shows page's last state, eg. with filled form fields, different opened tabs, changed element positions or states, the page scroll position, etc (theres a lot to consider!)
Currently we have to implement this logic ourself - creating history store, with derived stores per page/component/path, track path/url changes, then manage the page state/history by cloning, pushing and restoring the states from this history store.
It would be nice if this library provided it's own build store/logic that does that that we can use.
The text was updated successfully, but these errors were encountered: