faceyspacey/redux-first-router-link

Remove dependence on redux-first-router

Closed this issue · 0 comments

This is a great module on its own and there are definitely use cases to use alongside different redux routing solutions. There is currently a fairly light dependence on redux-first-router in the source code, here are my suggestions, I'm more than happy to help out with this:

  • Remove redirect: I believe this is to support feature parity with React-Router by allowing a redirect prop on the Link component. This seems unnecessary since we are just passing actions as the to prop in Link already. If one is using RFR, they could just do:
import { redirect } from 'redux-first-router'
import { foobar } from 'my-routes'
...
<Link to={redirect(foobar())}>...</Link>
...

instead of

import { foobar } from 'my-routes'
...
<Link to={foobar()} redirect={true}>...</Link>
...
  • Either move pathToAction and actionToPath to a shared module with RFR such as redux-first-router-utils or something AND/OR allow this to be configured. When using a separate routing core one has to basically reimplement this anyways (in my case I'm supporting query params) so it be nice to be able to configure this alongside or in the absence of RFR, or even use the functions without RFR. (more on this later)

  • Allow selectLocationState to be configured. This currently ties RFRL to whatever reducer key RFR uses to store the route map, so when using with RFR, I MUST have my routes in location.routesMap

  • Either move RoutesMap type to a shared module with RFR such as redux-first-router-utils or something OR just duplicate in RFRL.

  • To address the configuration I suggest something along the lines of RFRL exposing an init function to provide configuration. RFR would do this for you when starting up, but when using RFRL alone, you would be on the hook for it:

import { init } from 'redux-first-router-link'

// maybe even!
import { pathToAction } from 'redux-first-router-utils'

init({
  locationStateSelector: state => state.myLocation.myAwesomeRouteMap,
  actionToPath: <some_function>,
  pathToAction,
})

I know there are a few more items referenced in the tests, but those can be addressed in many ways.

Thoughts?

Dave