Migration instructions from react-router@3

[mistadikay]

trafficstars

Hey, great project!

We use react-router@3 at the moment, but not really sure if migrating to @4 is going to happen any time soon, if ever. So, found looks like a great alternative as soon as some migration instructions from react-router will be available — I'm sure lots of people will appreciate that. Thanks

[taion]

Good idea. For now, the capsule summary is:

• getChildRoutes and getIndexRoute are gone; no replacement intended in the near future
• route components use Component as the property rather than component
• path matching now uses Path-to-RegExp, mostly matching the Express syntax; biggest change is that it's now foo/:optionalParam? instead of foo(/:optionalParam)
• top-level router setup looks a little different – see the examples; biggest change is that the route config is now static
• no explicit default/index routes; they're just routes without paths now
• getComponent doesn't take a callback for async any more; if you want it to be async, return a promise
• onEnter and onChange are gone; you can do the same thing in render now by throwing a RedirectException, but you have to also return the element (by default just <Component {...props} /> if both are resolved)
• onLeave is gone
• transition hooks work differently; it's router.addTransitionHook now, and they trigger on any navigation
• router middlewares have been replaced by a couple of more specialized APIs (resolveElement and render on the router)
• Found uses Redux and renders its own <Provider> by default; you'll need to enhance your store per the docs if you're using your own Redux store

[oyeanuj]

@taion Thanks for the summary here! For my own understanding, I'd love to know the better the motivation, and comparison (of philosophy, approach or pros/cons) of Found and RR(2/3) and RR4? It would really help make an informed choice for a bunch of us who are coming from RR and in midst of figuring out which library to move forward with.

As someone else said on a different thread, thanks for all your work on RR and putting this library out :)

[taion]

See https://medium.com/@taion/react-routing-and-data-fetching-ec519428135c.

[idolize]

@taion Why the removal of onEnter and onLeave? I can see how the introduction of getData and render reduces the need for such explicit hooks, but I can still imagine some use cases for them (i.e. triggering an action to reset some redux state when the user leaves a given route).

[taion]

There are, but my thought there was that those cases were likely to be rare, and more context-specific – getData and render ought instead to be idempotent. This is specifically to avoid issues like https://github.com/ReactTraining/react-router/issues/3220.

Note that Found already does dispatch Redux actions, so if there's something you need to handle there, just listen to the actions!

[brettjashford]

@taion what would you recommend for an app that uses RR2 w/ react-router-relay middleware? the app does not have nested routes but must cache relay data between routes.

we've upgraded most of our app to relay modern but are stuck at the router and would prefer to make few changes at the router level if at all possible.

thanks in advance!

[taion]

If you're not using nested routes, then the choice of router framework doesn't make much of a difference. You wouldn't have even really needed react-router-relay.

That said, the route configuration API is in Found Relay is very similar to that of react-router-relay; compare react-router-relay to Found Relay. It's a pretty straightforward translation.

You do get one additional benefit if you use code splitting, though, in that Found Relay (unlike react-router-relay) can, when using Relay Modern, fetch data plus the split-out code component at the same time, and show loading feedback while doing so.

Relay Modern makes data caching an application-level concern, though. The most common recommendation is to use request-level caching – see discussions on e.g. the Relay repo for more details.