My team and I are developing an app with react, redux, and react router. Our app has rather plicated routing requirements, but nothing crazy: adding default query parameters to the URL on navigation, multiple routes mapping to the same view, rerouting on certain routes based on application state, and recovering previous states to name a few. A big problem I have had is the fact that I can't atomically route and update state. Routing must happen before or after the state update which leads to intermediate states where either the routing is plete and not the state update or visa versa. For example, navigating to a particular view should load some content and update the load status to loading in state. Also, some ponents trigger redux actions on mount so the routing events lead directly to redux actions so it is sort of like dispatching multiple redux actions. This causes a lot of bugs and a jarring browsing experience in some cases. I read this article and it seemed to provide the answer to my problems. According to the article using react router and redux results in two sources of truth. Updating them separately leads to these issues. I love the idea of having just a single state as the source of truth and all events going through the same channel.

However, it seems that react router is the overwhelmingly dominant browsing solution for react + redux apps. react-router has 28,355 stars on github to redux-first-routing's 76. This double source of truth issue seems like a mon one. Why has redux first routing not seen wider adoption? How do people solve this problem with react router? Why is react router worth the inconvenience of connecting your ponents to both the router and redux state?

My team and I are developing an app with react, redux, and react router. Our app has rather plicated routing requirements, but nothing crazy: adding default query parameters to the URL on navigation, multiple routes mapping to the same view, rerouting on certain routes based on application state, and recovering previous states to name a few. A big problem I have had is the fact that I can't atomically route and update state. Routing must happen before or after the state update which leads to intermediate states where either the routing is plete and not the state update or visa versa. For example, navigating to a particular view should load some content and update the load status to loading in state. Also, some ponents trigger redux actions on mount so the routing events lead directly to redux actions so it is sort of like dispatching multiple redux actions. This causes a lot of bugs and a jarring browsing experience in some cases. I read this article and it seemed to provide the answer to my problems. According to the article using react router and redux results in two sources of truth. Updating them separately leads to these issues. I love the idea of having just a single state as the source of truth and all events going through the same channel.

However, it seems that react router is the overwhelmingly dominant browsing solution for react + redux apps. react-router has 28,355 stars on github to redux-first-routing's 76. This double source of truth issue seems like a mon one. Why has redux first routing not seen wider adoption? How do people solve this problem with react router? Why is react router worth the inconvenience of connecting your ponents to both the router and redux state?

• javascript
• reactjs
• redux
• react-redux

• 1 I'm not familiar with that redux-first-routing library, but the answer to your question of how people monly solve this problem is with react-router-redux – Hamms Commented Feb 20, 2018 at 21:15
• 4 react-router-redux is what got us into this mess in the first place. react-router-redux populates the routing slice of state but this population also happens in response to the URL change and the update doesn't happen until after react router already handles the change. This creates even more intermediate states. In their documentation they say not to depend on this slice of state and that it is only for time traveling. – user5505266 Commented Feb 20, 2018 at 21:23
• can you give us a specific example of something you're trying to do in the current system that you can't? – Hamms Commented Feb 20, 2018 at 21:55
• 4 Take a deep breath, try to ignore the stars and give RFR a go. – Mark Simon Commented Feb 21, 2018 at 22:36

1 Answer 1

I'm currently doing research with the very same purpose as you, and from what I could find out, according to this the concept of redux-first routing has been around for a while.

Although the numbers are not parable to react-router, there is another library called redux-first-router which seems to currently be the de facto library for this (specially when pared with redux-first-routing.

At least according to https://medium./about-codecademy/react-router-to-redux-first-router-2fea05c4c2b7 this is what Codecademy uses.

I have implemented the tutorial from redux-first-routing that you can find here but in the end, there is no router actually there and you will have to setup one of the patible agnostic routers (read here).

At this moment I'm not yet decided if I will keep the part I implemented already, having to install one of these agnostic routers, or if I will just do as Codecademy and go with redux-first-router which at this moment is what I am tempted to do (at least to try it).

Definitely, the best article I read is the one from Codecademy and also their example is the simplest to understand how this works. You can directly find it at https://codesandbox.io/s/m76zjj924j .

EDIT:

I ended up going with redux-first-router and it worked amazingly for the requirements. I was able to directly get info from the route, including querystrings which was more than enough to be able to implement deep-linking based on the state.