react-router@4 compatibility

[ooflorent]

The current API of react-router-relay seems to be incompatible with react-router@4.
Is there any plan for supporting it?

[taion]

No plans. React Router v4 takes an approach to routing that's fundamentally incompatible with what I want to accomplish here w/r/t data fetching.

[ooflorent]

Thanks for the clarification. So, the goal is to stick with RR3? Drop RR in favor of Relay router?

[taion]

There will be something different coming.

[jameslk]

@taion I would love to know what that is. I depend on your library, as well as the isomorphic relay router library. Hopefully it won't involve a terrible amount of churn. It's a pain having to deal with that in React Router as it is. Are you planning on making an announcement in the short term?

[taion]

@jameslk

For the time being, please continue to use RRv2. That's what I'll be doing for the time being, as RRv2 largely satisfies my needs, and it's not like it's going to stop working just because there's a release out with a larger version number.

If you want to track what's happening, keep an eye on https://github.com/4Catalyzer/found/tree/initial-impl and https://github.com/4Catalyzer/farce. The latter looks roughly how I want it to look, I think, but the former is under active development – I haven't even figured out how all the API points should tie together yet.

found is going to look pretty similar to RRv2, but the insides will be a bit different and should make it easier to show loading indicators when using async getComponent. It won't support getChildRoutes though.

[sibelius]

@ooflorent @jameslk u can use this snippet: https://gist.github.com/janicduplessis/f513032eb37cdde5d050d9ce8cf0b92a

that will wrap any route component inside a Relay.Renderer, so u can easily use with React Router 4

[taion]

That's a quite bad idea, BTW – it will make all of your loads unavoidable waterfall.

Unfortunately the sort of component composition in RRv4 just isn't a good model for async data fetching with routing.

So don't do that unless you actively want to delivery poor UX.

[bsr203]

I recently migrated from react-router to http://grahammendick.github.io/navigation/
There are plenty of samples, including relay, hot reloading.

The migration was smooth, and the library is super tiny.

I also like to hear @taion 's view on the library as he is one of the most knowledgeable in react + relay + react-router. thanks in advance.

[AnderssonChristian]

@taion Any updates on the RRv4 support for Relay applications? Or is RRv3 still the recommended approach?

[taion]

Nothing from earlier in the thread has changed.

[brysgo]

@taion - I know this is a really old comment that I made here:

relayjs/relay-examples#31

But I'm resurfacing it because I want validation that I'm not doing something that is going to get me into trouble later.

Ah, I see. Yeah, my routes just end up looking like this:

<Route
  path={"/nested/:thingId/thing"}
  component={props => <Thing data={data} {...props} />}
/>

And that is how I orchestrate my fragment containers.

I have been using the above technique to use relay-modern with react-router@4 without nesting QueryRenerer's. Any feedback on the approach would be much appreciated. (For some extra context, the 'data' variable is relay fragment data.)

[taion]

The issue is more like – suppose you have multiple routes that need different data.

Presumably you're doing the data fetching in a parent component, but how does that parent component know what query it should run, and which data it should fetch?

Like it's fine if you only have a single possible route, but otherwise you need to determine all your data dependencies in the ultimate parent, and if there are multiple possible sets of child routes with different data dependencies, you somehow need to sort all of that out on the parent.

[brysgo]

I see, could that be solved with refetch containers somehow?

[brysgo]

Each component, just needs to know which of it's immediate children will be rendered. Then it would have to refetch with different fragments spread. I can see how it gets complicated.

[taion]

Plus you're refetching, and these are exactly the waterfalled requests that by presumption we don't want.

[brysgo]

So is found-relay your recommended solution?

[taion]

Correct.

It's roughly the same API as React Router Relay, but has better support around things like async components, showing loading indicators, and redirecting or hitting 404s based on Relay data.

[haleykoike]

@taion Thoughts on react-router-config? It gives RRv4 the ability to have static route configuration again.
https://github.com/ReactTraining/react-router/tree/master/packages/react-router-config

With react-router-config, would there be some consideration in making react-router-relay compatible with RRv4?

[taion]

It's okay-ish for some use cases, but ultimately it's not a great solution. It's feature-incomplete as a config-based router.

In essence you end up just dropping all the core routing functionality in React Router v4, and rebuilding in a sort of messy way the v3 API. You don't get any of the benefits of the dynamic component-based routing, but you also don't get the sort of full-fledged config-based routing API, because it's sort of awkward to build on top of that system.

In the end, all you really get is a weird sort of wrapper around path-to-regexp.

My recommendation remains to switch to Found and Found Relay.

[AlvinLaiPro]

Marked