Remix Route Modules in React Router #9826
Replies: 7 comments 8 replies
-
So it turns out this can be fairly easily implemented in user space, using the same approach as Screen.Recording.2023-01-06.at.12.33.10.AM.movAlthough, I think it would be super useful to have a utility like this provided by default from React Router itself. Due to the lazy loading of |
Beta Was this translation helpful? Give feedback.
-
I wonder something, if the loader is imported together with the component (same module), wouldn’t that mean the data can’t be fetched until the component loads? |
Beta Was this translation helpful? Give feedback.
-
I think this would be an interesting opportunity to experiment with some improvements to Remix's route conventions. I described a few ideas to the team last year https://gist.github.com/jamiebuilds/028f00ee258708d6fdf5419436c9baa9 |
Beta Was this translation helpful? Give feedback.
-
Proof of Concept implementation here: #9830 |
Beta Was this translation helpful? Give feedback.
-
Hey folks! This is released in |
Beta Was this translation helpful? Give feedback.
-
Hey! I was just reading the Something I started using in my code (before I knew about this proposal) is a So,
So instead of:
you can do:
The one neat thing is, you can preload children routes in certain scenarios:
and you can define all your lazy routes with So I will sometimes preload routes in parent loader:
example from some code i'm working on: |
Beta Was this translation helpful? Give feedback.
-
I'm going to close this out since this was implemented in |
Beta Was this translation helpful? Give feedback.
-
In keeping with the trend of cross-polination between React Router and Remix, I propose that the Remix Route Module convention be brought over to React Router as a full-blown feature.
What does it look like?
instead of this:
What if you could do this...
... and have React Router call any
loader
oraction
export you had defined in that module, and also wrap your default export inReact.lazy()
for you?What problem does it solve?
A couple
Import bloat - Any decently large application is going to have a lot of routes, which leads to a huge chunk of imports at the top of the route module. Sure you can mitigate this with code folding, but it doesn't help with things like viewing the routes on Github, etc. (for example: Docker Hub currently has 240+
React.lazy()
imports in one of the route definition files, and it's nowhere near the largest RR app I've encountered).Fewer names - You wouldn't have to do things like:
import Team, { loader as teamLoader } from '...';
or evenimport Team, { teamLoader } from '...';
, and it also keeps the loader/action firmly with the code that invokes them, and leaves the route definition module to care about one thing: Your route structure.Code splitting - React Router isn't in the business of code splitting, but virtually every bundler knows to split at the dynamic
import()
call and will do the Right Thing.Lazy loading - With this pattern, an engineer wouldn't have to figure out how to lazy load the component's loader or action handler. That lazy loading would essentially come for free, as React Router would dynamically import the module when navigating to that route. The code to render the route, as well as the loader/action, gets imported Just-In-Time.
How would it work?
I imagine the implementation would look something like:
What do you think? In my opinion, this would drastically cut down on the amount of boilerplate necessary for configuring routes in most cases, while still allowing for fine-grained control without changing any existing features.
(It would also have the added benefit of making it super easy to transition from a full client-side RR6 app to Remix!)
Beta Was this translation helpful? Give feedback.
All reactions