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

Scroll Position Restoration #23

Open
eugenkiss opened this issue Jan 22, 2017 · 2 comments
Open

Scroll Position Restoration #23

eugenkiss opened this issue Jan 22, 2017 · 2 comments

Comments

@eugenkiss
Copy link

eugenkiss commented Jan 22, 2017

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?

@kitze
Copy link
Owner

kitze commented Mar 15, 2017

This is an interesting issue @eugenkiss. I will think about a way of implementing it.

@eugenkiss
Copy link
Author

eugenkiss commented Mar 16, 2017

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 (uiStates) and https://github.com/eugenkiss/static-mobx-routing/blob/b4d844e13df06cd5cac6212e7a9b527ab311e3fa/src/app/comps/post.tsx#L51 (saveUiListener and autorunRestoreUiState). Note that simply deserializing in componentDidMount without autorun does not suffice as the component can stay mounted while its data completely changes (e.g. go from one post to another).

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants