Set declarative options by route

[acjay]

As far as I can tell, the API doesn't yet support a simple way to have routing parameters set by the route configuration. For example, I might have a wiki, which could have an meta routes for each page:

  <Route path="/" component={WikiComponent}>
    <Route path=":page" options={ { mode: 'read' } }>
      <Route path="edit" options={ { mode: 'edit' } } />
      <Route path="talk" options={ { mode: 'talk' } } />
  </Route>

Let's say I designed the app so that the root component is the same, but throughout the app, different components will modify their behavior based on this mode property. Also, I want to render universally, so I want to be able to access the mode property via match, because perhaps I want to prefetch some data based on mode. Is there a way to do this? The idea of reparsing the URL elsewhere to infer the mode smells, if the route config should be the source of truth.

[taion]

The route object is on this.props.route on the route component. In your case, it'd be e.g. this.props.route.options.

BTW, @dblock pointed me at your redux-react-controller repo on the NYCTech Slack – you should take a look at discussions regarding the future of context, specifically from e.g. #2646 (comment); I believe the pattern that you use is at meaningful risk of breaking in future React releases.

[acjay]

Ah, great! I'm not sure if I missed something when scanning the docs (and I just rescanned them again), but did not realize this was the case. The structure renderProps doesn't appear to be explained at all, other than as something you need to pass intact to RouterContext.

In case someone else does a similar thing, I'm using this like:

// routes:

<Route path="/" component={WikiComponent}>
  <Route path=":page" mode="read" } }>
    <Route path="edit" mode="edit" />
    <Route path="talk" mode="talk'" />
</Route>

// in `match`:
function routeProp(routeObjects, propName) {
  return routeObjects.reduce((last, route) => route[propName] || last);
}

match({ routes, location: req.url }, (routeError, redirectLocation, renderProps) => {
  //...
  const mode = routeProp(renderProps.routes, 'mode');
  //...
}

[taion]

You're right – we probably need a more advanced "server rendering" guide that covers use cases beyond "feed renderProps as an opaque object into <RouterContext>".

[acjay]

Re: redux-react-controller, thanks for the info.

"React 15 is only going to allow components to export only one object to "context" (we only want one anyway)

seems particularly applicable. Sounds like a good change, to prevent context from being one big swamp. Not too concerned though, I'd already been considering refactoring using recompose's withContext to bridge from context to props. Obviously, that decorator will be at risk too, but with the change, client code won't really need to be able to worry, and I'll work around the plumbing changes in the library.