[BUGFIX beta] Preserve current history state on app boot

[courajs]

RFC #186 introduced per-history-entry unique ids to the HistoryLocation.

But currently on app boot, a new uuid is always generated. This means that when refreshing the page, the same history entry is given a new uuid.

[courajs]

ping @stefanpenner

[stefanpenner]

@bcardarella mind taking a look, is this still in-spirit with the history state stuff you added?

[bcardarella]

@courajs can you detail the use case? RFC #186 was intended to bring in the behavior originally build into ember-router-scroll https://github.com/dollarshaveclub/ember-router-scroll/blob/master/addon/locations/router-scroll.js

for the purposes of preserving scroll position between page transitions. If I hit a transition to a URL that is outside the Ember app then backbutton I am presented with the previous scroll position. From a behavior perspective it appears the history state is preserved and app boot doesn't interfere with it.

Can you give me an idea on how I would reproduce this outside of the unit test that you wrote? Perhaps I am overlooking an edge case.

[bcardarella]

If there is a bug with this feature it would be great to get it fixed before 2.14 which I believe ships with the RFC #186 feature. That would be due June 5th.

[stefanpenner]

Oh I see. This is to survive full hard page reloads? I think we explicitly decide not to support that due to complexities which I have now forgotten. Maybe @bcardarella remembers?

[bcardarella]

If this is meant to support a hard refresh then I suspect we do want to support that use case. The goal was to create the behavior of a server-rendered page and its scroll state preservation.

With hard refresh as a use case you can see how an ember app with the router scroll addon behaves differently than other server rendered pages. We should strive to make the experience identical.

[courajs]

Yep, this is to support a hard refresh. I'm keeping a table in sessionStorage from uuid -> some other state, similar to scroll. Without this, after a hard reload, previous and future entries still work with the table, but the current one doesn't match up. This would help preserve page scroll when you refresh as well.

[courajs]

I looked through the RFC and original implementation and didn't see any mention of this - I think it was just an oversight.

[bcardarella]

I think it was just an oversight

confirm

[bcardarella]

@stefanpenner I'm 👍 on this change

[ef4]

I reviewed this with @courajs and I'm going to merge it unless anybody has objections that haven't already been voiced in this thread.

[rwjblue]

@ef4 - Probably worth a rebase to make sure the new more strict linting rules and whatnot are not going to make master fail...