[fixed] Window scrolling

[mjackson]

The router now remembers the last window scroll position at various
paths and automatically scrolls the window to match after transitions
complete unless preserveScrollPosition=true is used.

This commit also introduces a flux-style architecture to the high-level
transitionTo/replaceWith/goBack methods.

Fixes #189
Fixes #186

[ryanflorence]

\o/

I was just thinking last night that we needed to finish this feature.

[ryanflorence]

AND bringing in a dispatcher/actions. this is fantastic

[ryanflorence]

Interesting implementation.

In a server-rendered app you only return to scroll positions if you use the back button, but it appears that if I navigate with links from a -> b -> a my position will be returned. Maybe this is better?

[mjackson]

In the few quick tests that I did in Chrome it maintained the scroll position regardless of whether I was using the back/forward buttons or links. Makes for a super simple and predictable implementation.

[ryanflorence]

Yeah, I think its a novel approach, but you've been pretty adamant about
trying to mimick old, boring, server-rendered app behavior.

On Fri, Aug 29, 2014 at 8:22 AM, Michael Jackson notifications@github.com
wrote:

In the few quick tests that I did in Chrome it maintained the scroll
position regardless of whether I was using the back/forward buttons or
links. Makes for a super simple and predictable implementation.

—
Reply to this email directly or view it on GitHub
#249 (comment).

[mjackson]

My initial implementation of this feature used a ScrollStore to store the window's scroll positions and used the dispatcher to know when to record the scroll position (immediately before we change the location). However, I found that I had a circular dependency between ScrollStore and PathStore. PathStore needed to waitFor([ ScrollStore.dispatchToken ]) before it actually changed the location object, and ScrollStore needed to use PathStore.getCurrentPath to know what the path was.

So that was the motivation for including the dispatcher in the first place.

[mjackson]

you've been pretty adamant about trying to mimick old, boring, server-rendered app behavior

I just think it makes the most sense as the default since that's what everyone knows already. Mounting a <Route> isn't like mounting other components. They are entry points. Pages.

[ryanflorence]

I'm still a little unsure about clicking a link and getting the scroll position back.

[mjackson]

Well, let's just see how this feels. I agree there will probably be some fine tuning we still need to do.

[sophiebits]

(require('flux') now!)

[mjackson]

:D Awesome!

[sophiebits]

This also sounds a little odd to me but I'm willing to try it.

[ryanflorence]

@spicyj I keep wondering what is the difference between clicking a link to users/1 and clicking back to users/1?

The only answer I have is "server-rendered apps won't preserve scroll position."

Doesn't seem like a good enough reason to not preserve scroll position.

[bobeagan]

Clicking a link and going to the last scroll position of that page doesn't make sense to me.

[mjackson]

yeah, me neither. should be pretty easy to make the change tho. just need to observe the source of the action. if it was a click, don't do the scroll thing. if it was popstate, do it.