What are the reason to keep using Connected-React-Router?

[stephyswe]

React-Router handle history, so why would we want CRR anymore?

[aviral-clarifai]

@stephyswe this might be opinionated; but we really don't need to keep router state in redux anymore. I'm still using this package because I work on a huge app made for years; however, it is borderline bad practice to have redux aware of routes. It's better to just have one source of truth and use hooks like useLocation, useParams etc; and these hooks can call redux actions with the current pathname etc; if at all your thunks/sagas/reducers need to be aware of the current route.

[rodrigofariow]

Hi everyone,

I would love to hear the maintainers' opinions on this one!

Although I still agree with the concepts provided on ACKNOWLEDGE.md (specially The idea of uni-directional flow (history -> store -> router -> components)) I feel that from time to time developers need to be reminded that specific libraries are worth using. This might be one of those cases.

I should also mention that react-router folks recommend not to keep your routes in your Redux store at all which is always something relevant to be aware.

Note that personally I feel like it's worth using. However, going forward I'm still not sure if "coupling" my apps with this library is the way to go and if it may cause problems with new versions of react-router or not.

Thank you for your time! ;)

Cheers!

[Alecell]

This package is on my boilerplate and I was asking myself still make sense to use it, at least wasn't only me that asks it.

[yalopov]

I use it heavily with redux-saga, being able to control router history behaviour dispatching redux actions allows me to trigger navigation events from a saga.

That makes it so easy to write a complex control flow from a single place.

[idfunctor]

@yalopov We don't need redux to be aware of the route just for sagas to be able to route. It's very simple to get the route/change the route from a saga without having to couple the store with it.

import { createBrowserHistory } from 'history';
export const history = createBrowserHistory();

You can just use Router from react-router-dom instead of BrowserRouter. Just pass the above instantiated history instance to the Router like so:

<Router history={history}>...</Router>

This history export has everything you need, including the location and actions like push and goBack.

IMO, It's just unnecessary design to have redux to have a duplicate source of truth when you can have this global history object. I usually keep my own routerUtils file using this history object aliased with webpack so that I can just do import { location, push } from 'routerUtils'; and use them in sagas.

[idfunctor]

https://reactrouter.com/web/guides/deep-redux-integration

[salvoravida]

Hi guys, the main problem of this package is that it handles syncronization via React Component Lyfecicles. this is the biggest mistake of this package, that have so over 100 issue, because of it.

You could easily have 100% one source of truth without any SYNC with this package

https://github.com/salvoravida/redux-first-history

[brauliodiez]

I think one of the valid main points to stick to this package is Redux Dev Tool goodies, e.g. if a given user experiences an issue he can send his action log and a developer can now step by step follow which navigation flow did he follow, is this something we can do without using this library? (Have support for time travel debugging for route changes in the Redux devtools.)

On the other hand I think that nowdays, in most of the cases you don't need to go for a 100% pure redux approach

[Sashkan]

Is it not possible to use both ? connected-react-router along with react-router-dom hooks ?

I'm supposed to migrate a huge library with 200+ components:

• using react-router-dom requires wrapping the app in BrowserRouter
• Unfortunately, this conflicts with the ConnectedRouter provided by your library
• I have little need for the redux-devtool use case mentioned here