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

js: replace history state when address page goes to list-view #815

Closed
wants to merge 1 commit into from

Conversation

chappjc
Copy link
Member

@chappjc chappjc commented Nov 13, 2018

When the address page is loaded with no URL #anchor, the default
anchor $list-view is used in a new URL history state. This caused an
unnecessary step in the brower history and made it nearly impossible
to navigate back to say the /tx page because of the pushState. Instead
using replaceState resolves the issue.

Note: this is FOR DISCUSSION. I think it is likely we will need use turbolinks
instead of the history API directly.

When the address page is loaded with no URL #anchor, the default
anchor $list-view is used in a new URL history state. This caused an
unnecessary step in the brower history and made it nearly impossible
to navigate back to say the /tx page because of the pushState.  Instead
using replaceState resolves the issue.
@gozart1
Copy link
Member

gozart1 commented Nov 13, 2018

Seems like a fine fix for now.

I think we ought bring in a dedicated client side routing lib to more easily and standardly back all state that is not possible to represent via the server rendered html.

So basically, if it's before the "#" in the url it's in the domain of golang + turbolinks.

If it's after the "#", https://visionmedia.github.io/page.js/ with the query string plugin looks good to me instead of using the history api directly. That would give us a convenient api for routing and parsing named parameters in the query string after the #, which should be all we need to comprehensively represent our client side state.

@chappjc
Copy link
Member Author

chappjc commented Nov 13, 2018

I'm not sure what to do with this because with broken back and forward arrows, this is no good.

@gozart1
Copy link
Member

gozart1 commented Nov 13, 2018

Ah I see what you mean, we'll need to hook into the https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onpopstate event to make forward/back arrows work correctly

@gozart1
Copy link
Member

gozart1 commented Nov 13, 2018

So basically, decouple the rendering from the routing.

Whenever a user clicks a button or selects that chart type, that should update the history and then call a generic function (lets call it something likehandleHistoryChange) that decides to changeView or drawGraph based on the current history state.

Likewise, the onpopstate handler would simply handleHistoryChange as well.

@chappjc
Copy link
Member Author

chappjc commented Nov 13, 2018

I came across onpopstate while looking into it... I was afraid of this. Seems needlessly complicated. Can't we somehow use turbolinks.visit for this too?

@chappjc
Copy link
Member Author

chappjc commented Nov 14, 2018

A mitigation, not a solution, is to link to #list-view from the address links everywhere.

@chappjc
Copy link
Member Author

chappjc commented Dec 3, 2018

replaced by #845

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

Successfully merging this pull request may close these issues.

None yet

2 participants