"branch" (or "routes") in beta4

[taion]

It looks like the array of currently active routes is no longer passed down to route components. This makes things a bit tricky for the Relay integration, because I was previously using branch (now routes on RoutingContext) for two reasons:

1. Our API is just to replace createElement and to add extra prop(erties) to routes. However, to build the aggregated query, we need to pull together all the child queries at top level before any of the children render. I don't properly have access to any state I can use for this in createElement. Previously, I'd just been reading branch at top-level and doing everything there: https://github.com/relay-tools/react-router-relay/blob/v0.4.2/src/RouteAggregator.js#L28-L58
2. For each child component, I consider the relevant set of route parameters to be the ones for that route and all parents. I use these to construct the relevant queries for each of those routes (since they may well need access to params from parent routes, but should not have access to params from their children): https://github.com/relay-tools/react-router-relay/blob/v0.4.2/src/getParamsForRoute.js#L7-L12

Strictly speaking, I can hack my way around this: https://github.com/relay-tools/react-router-relay/pull/28/files. However, would it be possible to expose branch to components again? (1) is a bit specific to Relay-style data fetching, but (2) might be useful more broadly.

I don't think I can the listen hook on history or set onUpdate on Router, because I need to observe the new branch synchronously with re-rendering the router.

[taion]

On second thought, this may not be so bad. Per relay-tools/react-router-relay#12 (comment), I also need to get ahold of the actual components used, and the current approach I'm taking doesn't work with async components.

What do you think the right way to handle this integration is? I wonder if RoutingContext could actually be a better integration point than createElement. It'd allow me to eliminate a lot of the code I'm currently using to put my RootComponent at the top level.

/cc @ryanflorence @mjackson

[rrarunan]

@taion In a similar situation, but RoutingContext seems like a nice integration point for our fluxible implementation as well. At this point, its not exposed in index.js .. probably for a known reason. But, this test file server rendering test does show how it could be used. I'm wondering if this is the right way to go as well.

[taion]

Yeah - the more I think about this, the happier I'd be if my point of integration were RoutingContext or something equivalent rather than createElement. I'm jumping through a bunch of hoops to create a top-level container, and those would all go away if I could just inject something like RoutingContext, and I'd get access to the current branch for free.

[taion]

Oh, I misread what you said - I mean to actually be able to specify my own e.g. RelayRoutingContext component to Router, rather than using RoutingContext myself.

[rrarunan]

Yes, I actually used the Router component which internally uses the RoutingContext in both server and client for rendering the Router now. And, all's good.

[mjackson]

We started calling branch => routes in beta4.

[taion]

@mjackson That's not the difference though - the difference is that it's no longer exposed to the route components.

[juhaelee]

@mjackson @ryanflorence should this issue be reopened? It doesn't appear to be resolved

[taion]

Right - to clarify, the issue is not that it's been renamed. The issue is that this is no longer passed to components.

What's the right approach here? It looks like Router is pretty minimal; is it better just to implement my own if I want to control the routing context entirely?

[faergeek]

For now you can fix it like this:

function(Component, props) {
  return <Component {...props} branch={this.routes} />;
}

And use props instead of context.

[taion]

Wow, that is extremely sneaky.

[ryanflorence]

uh, yeah, I'm not seeing routes, it should be there, working on it now.