-
Notifications
You must be signed in to change notification settings - Fork 66
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
Scroll Position Restoration #23
Comments
This is an interesting issue @eugenkiss. I will think about a way of implementing it. |
FYI, I've tried a specific approach in a branch of my project: https://github.com/eugenkiss/static-mobx-routing/tree/rewrite The idea is roughly as follows: First, the assumptions: Routes are part of a list (the history) that is (de)serialized and there is a pointer/index that points to the current route in the history. This pointer moves according to the user's history manipulation (e.g. pressing the back button decreases the by 1). Components can register themselves to save arbitrary state in the current route before the route is left. See https://github.com/eugenkiss/static-mobx-routing/blob/b4d844e13df06cd5cac6212e7a9b527ab311e3fa/src/app/history.ts#L8 ( So, the main idea is that the component itself is responsible for saving and restoring UI-specific state that it cares about (scroll position, hidden/opened UI elements, selections, etc.). This is similar to Android's approach and it intuitively makes sense to me. Plus, there is no need for rough heuristics as described in the above blog post. Caution: My current implementation is WIP and does not work for at least one use case yet. If you have any thoughts/ideas @kitze, please let me know. |
Restoring the scroll position in SPAs seems to be a difficult problem in general. Mainly, because data is loaded asynchronously again when you go back. See, e.g., https://brigade.engineering/maintaining-scroll-positions-in-all-browsers-a280d49bffca.
Do you have ideas how you would adjust mobx-router so that it can support scroll position restoration? Or some other transient UI-specific state (e.g., hidden/opened UI elements) that you don't want to encode as query parameters?
The text was updated successfully, but these errors were encountered: