Include redux-router v1.0.0-beta3

[stevoland]

Edit: Update to initial middleware approach
Edit: Now fixes RequireLogin.onEnter hook. #242

#41

In this implementation we're back to the URL updating to the new route before the data fetching transition finishes. I kind of like this. It would also be easy to add a global spinner or something.

You can also now add status={404} or whatever to a route change the status code sent with the server render.

I'm sure something will be broken!

Breaking changes I can think of:

• fetchDatas signature is now fetchData(getState, dispatch, location, params)

Known issues

• Location bar changes before transition
• Reverting to original state throws an error as redux-devtools is using deserialised React elements sent from server. See Necessary to put complete routes in store? acdlite/redux-router#57

[quicksnap]

I'm disappointed with the behavior of pushState occurring before the transition is complete. There are legitimate use cases for asynchronously preventing navigation to a route.

It's still probably worthwhile to move to redux-router now and try and figure out a solution whenever we can.

[apapirovski]

I think any connect-ed components below the middleware component get the updated redux-router state regardless. Haven't tested this exact version but in my implementation that's what seems to happen. I think that adds some complexity in terms of reasoning about your app state and is probably unwanted.

This solution is IMHO ideal for simple react-router implementation, even if you have redux but not once you add redux-router. To me the the middleware component makes it very easy to reason about your app state, is unlikely to break the router (because it can do whatever it wants) and is unlikely to break the app (because again, it can do whatever it wants). Any solution that ties deeper into react-router (such as using history) is likely to need more maintenance in the long-term.

I think when you add redux-router into the mix, this might make more sense as middleware (and a new reducer) that captures the new router state, creates a new action along the lines of WILL_TRANSITION with the information and returns a promise that then nexts the original routerDidChange, when everything loads in.

I think that would even work on the server with some wrangling... ? I don't know. Going to try something like that later.

[stevoland]

@apapirovski Yes, that's a limitation of this approach. Great idea, might have a play around tomorrow.

[stevoland]

@apapirovski I've updated to an initial middleware based approach

[apapirovski]

@stevoland There's an important consideration with this implementation (that I haven't found a work-around for). You cannot use connect to get router state, otherwise the lower-down components will refresh before the router itself renders new component tree.

Given that everything is already coming down in 'props', I don't think this should be an issue if we're truly serious about keeping our state as far up the app as possible. That said, I think it's important for it to be clearly documented somewhere.

Also, for what it's worth, it's possible to make this work on the server, in an almost universal way. You just need a store to keep the promise in and then subscribe to that in your server.js, and only render when it's complete.

[quicksnap]

Hey @stevoland, don't know if the info is relevant, but check out #292 -- some things history.replaceState have improved and could make things easier.

Anything particular holding this up? Should we wait for redux-router to hit RC first?

[stevoland]

Not sure what's holding this up really. Just a general lack of interest maybe?

The issues that I have found are down to redux-router such as keeping React components in Redux state. Development seems to have slowed on that - I get the impression he's waiting for a stable react-router release first.

Maybe we should just keep this lying around. Would be good to get more people testing it out though.

[erikras]

Well, the Travis build is failing, for one. Something about react-router not being able to find qs.

[stevoland]

Odd, just happened after I rebased and only with npm 2.

[stevoland]

We should probably force npm@3 on Travis. We are on the bleeding edge after all 😄