No integration with params

[duro]

What is preventing this library from providing insight into params and providing the ability to update them with the push and replace actions? No support for route params is the one thing holding me back from trying to adopt this library.

[kimjoar]

I enjoy the simplicity of this choice. I don't have to go hunting for the difference between react-router and this lib — instead I rely on location and history from react-router. Here's an example from my search component where I want to keep the path, but only change the q param:

search(q) {
  const { location, history, pushPath } = this.props;
  const newPath = history.createPath(location.pathname, { ...location.query, q });
  pushPath(newPath);
}

[duro]

What if I want to do this from another action creator in a store and don't have access to props?

[kimjoar]

Maybe @jlongster and others has got some ideas here, but in my mind there's a couple of different options:

• Inject both deps

  const { location, history, someActionCreator } = this.props;
  someActionCreator(location, history);

• https://github.com/rackt/react-router/blob/master/docs/guides/advanced/NavigatingOutsideOfComponents.md and inject location

• Use redux-router which rely on middleware to handle this

Currently history has no way of getting the current location, so location must be passed to the action creator somehow. One potential option for redux-simple-router would be to put the current location in the store (instead of the path and state), but I'm not sure how that would work. E.g. if pushPath should keep the same api as today, it needs access to history in order to call history.createLocation, but currently only syncReduxAndRouter has access to it. If we want to give pushPath access to history we can't keep the code as stateless as it is, so we'll have to create an instance of redux-simple-router on which you can get pushPath. (Without using the history methods I think we can easily end up in a place where we try to re-implement how it handles location etc).

The library is just about a 100 lines of code, so it would be awesome if you played around with it and found a way to make it work (that's basically what I've been doing myself with the lib to make it work for my use cases).

[download13]

The solution I've found is to not use react-router at all and keep routing confined to components.

Instead of doing all routing at the top level via Router and Route each component (usually the top App one) is responsible for routing of all it's child components. For example, inside the top level App component, I might render:

{renderRoutes(props.path, {
    '/': IndexView,
    '/create': CreateView,
    '/item/:id': ItemView,
    'item/:id/edit': EditView
})}

All that's needed to do routing is the current path which can be passed into the top level component from your redux store. renderRoutes then checks the path against the patterns and renders the appropriate component (IndexView, CreateView, etc). renderRoutes also derives a params object from the path and the selected route pattern, then passes that params object to the child component.

Of course any links that stay within your site will need onClick handlers that dispatch the updatePath (soon pushPath or replacePath) action instead of just navigating to the destination the way the browser does by default.

Here's a gist of the renderRoutes function if you want to look at it.

[jlongster]

I think the above responses have answered it pretty well. The goal of this library is to be as simple as possible and encourage using react-router directly. The more we try to abstract it away, the more we take on for maintaining and documenting. If you look at the code it's already quite complex to make sure both are in sync just for URLs. You can use redux-router if you want more tight integration, but if you compare the different codebases you'll see how much more complex things get.