Clarifying the goals of this project

[gaearon]

I think I’m getting a little confused by the goals and the scope of this project. I’d appreciate @jlongster weighing in on this.

I see a few things it does right now:

• (1) Provides state.routing for other middleware, components, and action creators to read. I believe this is problematic: it doesn’t match the rendered route because of the potential for async transitions in between. This is the reason we warn people not to use state.routing in mapStateToProps() which I believe is confusing, and even if they don’t use it in components, they still might use it in action creators and expect it to correspond to the router’s current state. So I’m not sure whether this is a good feature to keep.
• (2) Provides an actions-first interface to side effects of history. While this may be convenient, I think the reason people want this is not because actions are the best interface for causing routing changes, but rather because people don’t want to deal with context or pass history around. Many people are also feeling pressured to express everything with Redux primitives (actions) even if the problem at hand is not expressed with them well. Consider that history.pushState() is not much different from fetch() (it’s a side effect) but nobody expects us to provide “fetch action creators”. The real problem here seems to be the perceived difficulty of passing history around or importing it, rather than the need for history updates to be actions.
• (3) Allows replaying the history changes from DevTools or another action replay mechanism. This is where it gets interesting. It seems to me that the ability to persist routing state together with everything else and re-render the app based on current state rather than what the browser thinks was the original point of this library. This feature seems to explain the need for action creators: you want navigations to be in the log so they can potentially be replayed. However such functionality would only be useful in dev (or otherwise special) environment.

As we evolve (or not evolve) this library, I want to better understand which of these points are actually important to the author, and which are just a byproduct of current user habits and their desire to express everything “the Redux way”.

Essentially, I want to understand what value react-router-redux brings over react-router + history in production mode other than the familiar mental model (“just dispatch actions”), the ability to reach out into state.routing (which can be dangerous and may not reflect the UI but can be convenient for apps without async transitions), and not having to think about how to access history without passing it around.

In no way am I trying to diminish the work being done here. I just want to figure out for myself whether presistence/time-travely part of this library could be a separate dev-only project, and whether what would be left is not essentially a feature request for better documentation and less ceremony when accessing history from action creators and other middleware.

Thank you!

[timdorr]

For a number of reasons (bundle size, code complexity), I've always thought it would be interesting to isolate the Dev Tools integration into its own thing somehow. Not having to worry about it really simplifies the functions used for production. Unfortunately, it's necessary for the current setup to couple the two things, but a split would probably simplify a lot of the confusion.

[gaearon]

What I’m trying to understand is what exactly is the benefit of the rest of the project other than patching usability holes with making history accessible without explicitly threading it?

[inyono]

We (@ory-am) are basically only using the action creators and the DevTools. Most of the time, we use react-router features directly.

Consider that history.pushState() is not much different from fetch() (it’s a side effect) but nobody expects us to provide “fetch action creators”.

In fact, we do exactly that. We handle side effects with redux-saga and have action creators that initiate the sagas (and those dispatch some actions themselves).

[mathieudutour]

Dispatching an action instead of using directly history.pushState() is really important. The action will go through the chain of middlewares, meaning (for example) automatic analytics, etc.

[k2052]

At least in my use case it was simply a matter of "knowing where to put things". The second point Provides an actions-first interface to side effects of history was the biggest one for me. Having history manipulation as actions gave me a clear place to put things that manipulated history and a clear way to do it. Dispatching an action to change history was a clear mental model I already understood.

[gaearon]

Dispatching an action instead of using directly history.pushState() is really important. The action will go through the chain of middlewares, meaning (for example) automatic analytics, etc.

Doesn’t this achieve the same goal?

history.listen(location => store.dispatch({ type: 'NAVIGATE', location }))

[taion]

Let's denote those points as (1), (2), (3).

(2) is actually just its own little thing – I'm quite happy with what we have via #141 from my perspective, though you're correct in that this is not strictly tied to the rest of the package.

(1) and (3) are where it gets interesting and messy.

I think something like my proposal in #248 (comment) would get us to (3), but it's still a bit of a hack, and it's not perfect.

I think the first-best solution to (3) is actually to solve (1), by having Redux drive the router, in which case (3) naturally falls out just by virtue of Redux being Redux. While the router state itself is not serializable, we can digest it into just the location, and use match() to deserialize.

This is much more like redux-router, though, but I think a "simple" version of redux-router might be a viable approach. It would clean up (3) a lot.

[gaearon]

What have we learned from Redux Router? What parts of it were complicated, why, and has this changed?

[taion]

cc @mjrussell, @acdlite on the Redux Router question

I don't want to sidetrack this too much, but I think the way this API wants to look is that <Router> is just like <NavigationContainer> from https://github.com/ericvicenti/navigation-rfc, in that it can be subbed out.

I think we can solve the serializability-for-persistence issue with a custom persistState, but I don't know what the other issues that redux-router faced were.

[gaearon]

Got it. Thanks for the information. I’d say let’s not get too far in this thread with implementation thoughts, and rather figure out the focus better. What do we want to solve with this library and why.

[timdorr]

I would say simplicity is a feature, not a requirement of the project, so if we have to get more complex, that is fine. Maybe not redux-router levels of complex, but not redux levels of simple 😉

[gaearon]

The problem is that without a clearly defined pain we’re solving, it’s hard to focus.
I think this tweet exchange caught me off guard:

(James) Setting up redux/react-redux/react-router/history/react-router-redux/redux-history-routing-react-router-simple/what-is-happeninggggggg

(Me) Don’t set up react-router-redux until you need it. You can start with just history, or history + RR

(James) when would I need it?

This is when I realized many people might be installing this project and setting up all this stuff without actually needing it.

For example, from the same exchange:

(Florent) if you want to access history and don't have access to history prop.

But this is incorrect because you can do

import { browserHistory } from 'react-router'

and call browserHistory.push() just fine!

Similarly, from the exchange in this thread:

Dispatching an action instead of using directly history.pushState() is really important. The action will go through the chain of middlewares, meaning (for example) automatic analytics, etc.

But again, it is a matter of

import { browserHistory } from 'react-router'
browserHistory.subscribe(location => store.dispatch({ type: 'NAVIGATE', location }))

when creating a store if you want it.

So this is why I want to get a better understanding of what the goals of this project are. Because if it’s persistence and DevTools-friendliness, perhaps it’s easier to achieve in other ways, without providing state.routing, action creators, etc.

[taion]

I think that's a point that's worth making either way – in general you're not going to need anything to use React Router with Redux, at least when starting out.

Certainly I've never felt the need to put router stuff in any of my Flux stores or actions.

[timdorr]

import { browserHistory } from 'react-router'

Actually, up until 2.0.0-rc1 (a month ago), you could not. And you still cannot without running non-final packages. You can certainly create your own singleton, but I don't think most people know to do that. Hence, the popularity of this library lies in the limitations of React Router 1.0.