Allow customizing RoutingContext

[taion]

This is a little sketchy, but here goes -

I'd like to have access to the value of components from here. These are all the components (or multi-component objects) for each of the active routes.

The use case is that in react-router-relay, I need access to the component for a given route to properly proxy the queries for that route. I'm currently doing this: https://github.com/relay-tools/react-router-relay/blob/v0.5.0/src/RouteAggregator.js#L35, which clearly doesn't work even in sync case where components is specified instead of just component, but I don't see a good way to extend this to work with getComponent at all.

I can think of a few options:

• Just pass that components array to each route component
• Bringing back Allow overriding RoutingContext instead of createElement #1870
• Setting component or components on the route after the getComponent or getComponents call succeeds

None of those are great, though. This is really more of a "what should I do" question than anything else, I suppose.

[mjackson]

We give you the component for a route as the first argument to createElement. Is that not enough? Do you need to know the route at the same time?

[taion]

Well, you do give me the route via props on createElement, but it's not quite enough.

The main reason it's not quite enough is that I need to gather all the routes with their components at the top level. In createElement, I don't really have access to any sort of "context" object onto which I could e.g. store the a map of route to component. I need to eventually have all of those in one place to generate the combined queries for all the Router routes for Relay.

The other potential problem (I haven't thought through how I want to support this yet, though), is that when a route has multiple components, createElement doesn't get the key corresponding to the component, so I don't know which component on the route I'm rendering, which could be relevant if I want to assign different Relay queries to the respective components on a route.

[taion]

I'm thinking a bit about a possible way to do this. The main reason I closed #1870 is that it's not very composable, i.e. if you wanted to apply two different createRoutingContext functions, there was no obvious way to do so.

I wonder if a better solution here might be to introduce something like a concept of routing context middleware. I can explain this better with an example:

const ReactRouterRelayMiddleware = ({children, ...props}) => {
  const otherProps = {};
  return (
    <RootComponent {...props}>
      {React.cloneElement(children, otherProps)}
    </RootComponent>
  );
};

Unlike the createRoutingContext proposal, this API is explicitly composable, as in most cases users can use any number of these middlewares. These provide a way to interact with the routing context without hijacking it entirely.

While it wouldn't work for something like redux-router that wants to control the routing state entirely, this would allow plugins like react-router-relay (and potential future AsyncProps support?) to access additional routing-related properties, without expanding the surface area of props passed to each route component, and without compromising composability for users that want to use multiple plugins simultaneously.

[taion]

I'm gonna submit some sort of PoC for this when I get a chance. This isn't dead and maybe just a bit languishing, I've just been a bit busy.

[knowbody]

@taion can we close this issue and continue in #2036? or do you want to keep them separate?

[taion]

I don't think it's possible any more - since getComponent/&c. actually need to be dynamic, I really do need to explicitly get the set of components injected in, rather than using something memoization based.

I'll try to draft up a PR that shows what I'm thinking when I get a chance - maybe this weekend.

[taion]

The syntax I'm thinking about here is something like:

<Router
  history={history}
  routes={routes}
  middlewares={createMiddleware1({foo: 'bar'}), middleware2]}
</Router>

Effectively those middlewares would then wrap the RoutingContext component, and can e.g. wrap createElement in a composable way, or add custom top-level components (again in a composable way that doesn't clutter the list of routes), or access props like routes that really ought not be visible to route components anyway.

[srph]

Not sure if this is entirely related.

Anyway, my idea is to allow onEnter to accept an array of functions.

<Route onEnter={[isAuth, isAdmin, hasGoneToStep3]} />

[taion]

Not exactly - take a look at the PR.