Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

How to handle two different route sets with result of async data request on load with Redux-connected found?

See original GitHub issue

Issue Description

I converted my app from react-router v2 to found and it’s been great. However, I hacked on a feature a while back and haven’t figured out how to sensibly bring that over to found:

For most users, I want to use one set of routes. For a specific type of users, I want to use a much smaller set of routes. With react-router v2, I could just fetch the user (Redux-based) and then branch on what routes to render.

With a Redux-connected found, I’m not seeing a good way to do this. I see these options:

don’t create the store so don’t use my redux actions/store for the initial user fetch but instead fetch data, then create everything (and can pass fetched data into initial redux store state to avoid duplicate fetch)
use the happy path for most users but for the special-case users, update the Redux enhance createMatchEnhancer with the smaller route set (sounds potentially buggy)

I’m going to go with the first approach for now to unblock myself but I sense I’m missing something obvious so thus this issue.

Issue Analytics

State:
Created 6 years ago
Comments:7 (4 by maintainers)

Top GitHub Comments

1reaction

taioncommented, Oct 1, 2017

Okay, fair enough. #98 will land before async routes by a long shot, anyway, though the work is perhaps not so different.

The problem with async routes (dynamic routes in general) is that, since the route objects aren’t serializable, we only store the route indices in the Redux store rather than the actual matched routes, which means that we need to traverse through the route config again to figure out the actual routes at render time.

So for the medium term it’s going to look more like an explicit route reload, rather than dynamically loading new routes on-the-fly, because it’s tricky to avoid breaking Redux tooling otherwise.

0reactions

cymencommented, Oct 1, 2017

The funny thing is I actually had to wait anyway on the async request so it hasn’t caused a regression in app loading. I refactored so my store is created after I do the async request (and I pass in the data from the async request to as initial state to redux).

This works for now and is easy to reason about and makes sense.

Thank you very much for going over the options with me. I do think async routes would open up some really interesting possibilities but I also get it would be a lot of complexity/change/etc. So this is great for now.

I’ll close this issue.