Proposed simplified and breaking changes with React-Router V2 (Discussion)

[mjrussell]

This is related to and a continuation of #172. I spent some time this weekend getting redux-router up and running with react-router v2 and found myself rewriting logic almost verbatim from react-router into redux-router. I agree with the goals of redux-simple-router in that we should be leveraging react-router for the logic while ensuring that it can be used in a redux friendly way. However, I think based on the comments in #172 (and my own belief) there is a desire to continue this project because of some of the extra functionality it offers.

Therefore, I am proposing a possible middle ground style approach where we push as much logic into react-router and simplify this library while still maintaining some of the core features. This is only really possible with some of the new features made available in Version 2.x of React-Router which is currently in release candidate mode.

I've implemented a proof of concept here which has both the client and server examples up to date and working (the tests still need some updates though). The library contains about half the code of the original while maintaining the core features, although losing a few more advanced capabilities. I'd like to gauge wether or not these things are critical to the community.

Feature breakdown:

Maintains the following:

• dispatch actions which call the history API (i.e. push, pop, replace)
• updates to the router reducer result in calls to the history API
• full router state is present in the reducer (entire location object, query params, accessed anywhere with redux's connect)

Removes the following:

• dynamic route updates, i.e. replaceRoutes (becuase React-Router does not allow this...yet?)
• getRoutes ability which allowed the routes to be paramertized by the store

I think the getRoutes removal will be the most jarring at first. For example @erikras uses it in his well known example. However I think that the higher order wrapper method for authentication and authorization in routes as shown in @joshgeller 's example works quite well.

Other benefits

• Far less code, much easier to maintain and bugfix.
• Server-side rendering is almost identical to react-router
• Even more closely aligned with react-router API:
  • no need to copy over bug fixes
  • can refer users to react-router's docs
  • easier for users to switch between this library and redux-simple-router

Way forward

Would love to get thoughts from @Scarysize @acdlite @omnidan (and other contributors) as well as current users on this

[Scarysize]

"Far less code, much easier to maintain and bugfix" is music in my ears!

Seriously though, I think this might foster more contributions to the project by simplifying it just enough. It takes a lot of confidence to contribute to the code base in its current state; this might lower the bar.

[damassi]

I'm going to to take your POC for a spin right now

[mjrussell]

@damassi Awesome! Theres a small bug Im working through right now regarding multiple API calls to history (but it wont affect your test spin). Please let me know how you find it. If you have any issues put them here or ping me on Discord

[damassi]

Will do. The app I'm working on is fairly complex so I feel like I'll have a good idea of what's involved once I finish the switch.

[damassi]

Ok, I've run into a few snags that have forced me to reevaluate why exactly I'm using redux-router in the first place, which is simply to snatch location props from the state when really they're now being piped right through via the router directly into props. Looking over my code It would probably benefit to simplify things for the long run rather than rely on a cross-section of functionality that's already available in RR v2. If I had a bit more time I would be able to dig in and see what's up, but I've got.... a whole series of other major updates I need to do over the next week from Babel to redux-form. Oh Javascript!

[mjrussell]

😞 Sorry to hear that. One note is that those props are not being passed beyond the first level (i.e. the child routes) using React-Router.

The goal of this refactoring/new API was to bring the code much more in line to almost verbatim how React-Router works while adding the extra piece to allow for the store to hold the props (with little overhead) and to dispatch route changes via action creators. You might also look at redux-simple-router for a stable "lean" integration if you aren't using many of these features

[damassi]

I'm going to give that a look now and may return to this this evening once I have a better idea of the scope required. Thanks for taking the time to give this library a little attention.

[HriBB]

I tried https://github.com/mjrussell/redux-router/tree/rr-v2 and I managed to get client side working, but not without problems. I use router params in componentDidMount() to load the right data. First problem I had was that state params in my container were different than params from the react-router. Router params were empty on componentDidMount() and it broke down. I fixed this by using redux-router state params instead of router params. Could be a bug on my side.

Will do some more tests later, then on to the server side.

[mjrussell]

@HriBB the rr-v2 branch is a pretty radical approach to reshaping how to sync the store data (by using the render middleware of React-Router). It could have issues and Im definitely concerned you didn't get the routerParams on cDM. You might try the other branch I had which is a very modest upgrade at https://github.com/mjrussell/redux-router/tree/react-router-2.

That being said, it seems like the react-router-redux is moving in the right direction and will be much improved once they finished retooling the API. That definitely seems to the be "community-approved" way, but I know that redux-router will provide some benefits not found in react-router-redux.

If there is enough community support Im happy to try and continue with either path (the modest upgrades or more radical one) and help get a beta version out for those who want to continue with Redux-Router and get on React-Router 2. That being said I think that anyone considering that approach should at least look at react-router-redux at some point to make the best decision.

[gaearon]

Not sure if you have been following but you might be interested in reduxjs/redux#1362 and reactjs/react-router-redux#259. While it still doesn’t store the query parameters in the state, it might be interesting to compare approaches.