React Router v8 #14468
Replies: 7 comments 31 replies
-
|
🤔 Drop CJS builds and go ESM only Node.js 20.19+, 22.12+ supports require(esm) without a flag, which means we can drop our CJS builds. We will need to specify the proper minimum node version. A few resources I found helpful in considering if now is the right time |
Beta Was this translation helpful? Give feedback.
-
|
ESM-only. Burry CJS 6 feet under! |
Beta Was this translation helpful? Give feedback.
-
|
🤔 Subresource Integrity (SRI) #14244 @jacob-ebey has expressed the desire to consult with experts on SRI to make sure this API is fully ready to mark as stable. We plan to ask internally at Shopify, but are of course open to the wider OSS community to weigh in. |
Beta Was this translation helpful? Give feedback.
-
|
🤔 This is a feature we shipped back in Remix v2 (guide). There are some subtle bugs this flag can introduce for certain projects, so we didn't feel comfortable stabilizing it as it was, and carried it into React Router v7, since it is useful and fixes annoying an developer experience for many users. The solution to stabilizing this flag is to have separate module graphs without requiring transforms to run. This would require doing away with single file route modules, which is a far bigger change then we're comfortable requiring of our users. However, according to @pcattori this should be solved by Vite rolldown since the current bugs are caused by In the event that |
Beta Was this translation helpful? Give feedback.
-
|
I would say that as soon as Rolldown is considered stable by the Vite team, this unstable feature flag could be removed in a minor or patch release, since it's unstable it doesn't need a major release and AFAIK it's only a matter of removing the flag from the |
Beta Was this translation helpful? Give feedback.
-
|
Based on this, it seems Rolldown is imminent: rolldown/rolldown#153 I don't see anything wrong with keeping it unstable and then dropping it when Rolldown full bundle mode becomes the default in Vite, assuming that fixes everything. |
Beta Was this translation helpful? Give feedback.
-
|
@sergiodxa that's a great point, definitely doesn't need a major version to remove it since it's Major versions feel like a nice clean slate for dropping stuff like this, but I definitely wouldn't want this to be a reason to hold up v8. I'm good with this being one we just keep tabs on and make a judgement call once we're close to v8 being ready (unless others have any strong opinion)
Haha yeah, @alexanderson1993, definitely need to make sure that statement true 🤞 |
Beta Was this translation helpful? Give feedback.
-
|
🤔 Drop Node 20 support
Technically we don't need to drop Node 20. For dropping CJS builds we can require Node 20.19+. Would we still want to go ahead and bump the minimum Node version to 22.12? |
Beta Was this translation helpful? Give feedback.
-
Yep, this is why I said "non-maintained Node.js version", as long as Node.js maintain that version it should be supported, once it reaches EOL it should not be supported "officially" anymore, and by officially I meant that it may still work but in case of an issue the solution should be to first upgrade Node. |
Beta Was this translation helpful? Give feedback.
-
|
Matching the Node Release Schedule for Node versions seems like a reasonable choice. It also seems like Node v20 will EOL mid 2026 in case that impacts the decision. |
Beta Was this translation helpful? Give feedback.
-
I think to all your points, I'm probably a little overeager in this suggestion, and the best thing for consistency with our approach in the docs and walking in lock-step with Node.js' schedule is to just drop support for Node 20 when it reaches OEL @brophdawg11 and @jacob-ebey would love y'all's opinion too, as I believe this came out of a discussion you two were primarily having about dropping CJS. |
Beta Was this translation helpful? Give feedback.
-
|
I think we should drop node 20 :) I agree with our stance of supporting "Active and Maintenance LTS" - with a minor caveat. Our verbiage in the docs is important because it allows us to make a "breaking" change by dropping support for an EOL Node version in a minor RR release and not requiring a new semver major RR release. That said, I think everyone would agree it would be better to drop a Node version in a RR major release. I thought we used to have a sentence or two in the docs but at the least I know we specifically discussed internally that if it made sense for us, we would prefer to drop a version a bit before EOL if it aligned with a planned major release of ours. So if we're thinking RRv8 is early 2026, and Node 20 is EOL April 2026, then I don't think there's much benefit to keeping 20.19 supported in 8.0 just to drop 20 entirely in a "breaking but not really because it's EOL and our docs give us this permission" change in an 8.x minor release a month or two later. In fact, we already did this with React Router v7 in November 2024 where we dropped support for Node 18, which didn't go EOL until April 2025. |
Beta Was this translation helpful? Give feedback.
-
If this is our preference I think it makes sense to put this in the docs then. I think that reasoning makes sense, and good reminder about the Node 18 drop in v7. I do think a quick followup of a minor that drops Node 20 would look a little weird. |
Beta Was this translation helpful? Give feedback.
-
|
🤔 Remove matches in ComponentProps This is from a conversation @pcattori and I had. This worked, unless you used an arrow function for your component function MyRoute({ matches }: Route.ComponentProps) {
// ^ type-safe matches! 🎉
}
const MyRoute = ({ matches }: Route.ComponentProps) => {
// ^ infinite type recursion! 💣
}This makes @pcattori has an alternative approach to type-safe matches leveraging the |
Beta Was this translation helpful? Give feedback.
-
|
I mean taking away something developers love just for slightly more "purity" in our API is definitely something we need to consider |
Beta Was this translation helpful? Give feedback.
-
|
Maybe people should just not use arrow functions for things that should be function declarations? 😝 https://kcd.im/fns |
Beta Was this translation helpful? Give feedback.
-
|
@kentcdodds The JS community loves arrow functions! |
Beta Was this translation helpful? Give feedback.
-
|
I wish I could use a pre-exiting type for a function declaration though. I like having typed parameters and return values. I wish TypeScript supported that better. Ideally you could add function declaration properties that way too. |
Beta Was this translation helpful? Give feedback.
-
|
@kentcdodds we can't even get people to try |
Beta Was this translation helpful? Give feedback.
-
|
🤔 Stabilize RSC (data and framework mode) #11566 IMO it would be really ideal if RSC is stabilized going into v8, especially if it's addition will allow us to deprecate/simplify any other APIs in the future (I'm not entirely sure it will, but I know it's a possibility). I assume RSC support going into v8 will be just as opt-in as it is today, and not require any breaking changes. I would love to know if
|
Beta Was this translation helpful? Give feedback.
-
I assume so, without introducing breaking changes to the existing plugin. I could definitely be wrong. I think @markdalgleish is the best one to weigh in on this (or @jacob-ebey ofc, I just know Mark has been working a lot on RSC for framework mode) |
Beta Was this translation helpful? Give feedback.
-
|
@brookslybrand I'd love to see RSC! I'm not sure how useful it's going to be in Remix! People don't like them at all I'm scared! I don't get the point of pointers if Server Components exist! |
Beta Was this translation helpful? Give feedback.
-
|
yeah I think time is the main thing that would prevent us from stabilizing. Both because we have some potentially non-trivial things we need to tackle (spa mode, prerendering, etc.) for RSC Framework Mode to be "complete". Plus, we ideally want to get a solid set of alpha testers playing with it before we would feel comfortable stabilizing IMO, because it will still be opt-in in v8, I don't mind if we keep the |
Beta Was this translation helpful? Give feedback.
-
|
@louiss0 no need to be scared. I'm not sure all your concerns, but feel free to checkout how we're introducing RSC in React Router |
Beta Was this translation helpful? Give feedback.
-
If we're talking more than adding 2-4 additional weeks to the v8 timeline, I think I completely agree Thanks for pointing out that it is really a lot more than just "code completion", it's alpha testing and finding all the unknown unknowns. RSC is likely a feature that will need to bake as unstable for a while to ensure that we consider it stable when it truly is stable. |
Beta Was this translation helpful? Give feedback.
-
|
🤔 Consolidate Router State Access #13073 This would allow us in v8 to start deprecating some hooks if we feel that was worth doing to trim down the API. However, even if we ship this hook in v7, given the timeline I would not feel comfortable immediately removing other hooks as it would just create unnecessary churn for developers and feed into the impression that we're always breaking things just to make people mad. @pcattori do you have any input on if this should be part of the v8 roadmap? |
Beta Was this translation helpful? Give feedback.
-
|
Would be useful if the deprecation warning suggested the alternative, e.g. /**
* @deprecated Use `useRoute(routeId)?.loaderData` instead
*/
function useRouteLoaderData(routeId: string) { ... }So it's possible to leave the current hook but also see right there the new way. |
Beta Was this translation helpful? Give feedback.
-
|
@sergiodxa yeah great idea. Whatever the timeline is, I just want to make sure developers have a good amount of time to notice the deprecation and make changes before they feel forced to by the major version dropping it So yeah, I think adding the new hook in a minor for v8 is perfectly reasonable if the team doesn't feel they have the appetite to try to tackle it before v8 |
Beta Was this translation helpful? Give feedback.
-
|
There's 2 aspects to this - I agree that nothing existing should be dropped in v8 - we can add deprecation warnings in an eventual v8 minor and drop them in a v9. |
Beta Was this translation helpful? Give feedback.
-
|
This specific discussion is for I think that's a lovely timeline if you feel good working toward it! It's definitely a personal preference, but to me
just seems like a nicer story than
|
Beta Was this translation helpful? Give feedback.
-
|
Yea like @brophdawg11 mentioned, |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
React Router v7 was released almost a year ago (2024-11-21). We're at a good point to start considering what we want to include/remove in v8, which will help us build out any remaining roadmap and estimate a timeline.
There are a few principles from our Design Goals worth mentioning here as we plan for our next major version:
We have released a lot and have a few future flags already stabilized or can be soon. This is a good spot to take stock of future flags we have in progress, what deprecations we've introduced or still need, and draw a line in the sand for any future breaking changes we're considering.
Note
Threads will be created for anything proposed that needs to be discussed further. This top level summary will be kept up to date with all decisions that have been made.
Please open a thread (if one does not exist) if you have questions or comments on anything below, or if you have another feature, deprecation, or change you would like to be considered.
unstable_)Future Flags
v8_middleware🗺️ Middleware #12695getLoadContext/AppLoadContexthave the potential to be the most disruptive breaking changes in v8. We have a very feasible solution for custom servers usinggetLoadContextand should highlight this approach again in our upgrade guide.unstable_optimizeDepsDeprecations
datain types (in preference ofloaderData) feat(react-router): addloaderDataand deprecatedatawhere possible #14047require(esm)without a flag, which means we can drop our CJS builds.matchesinComponentPropsNice to Haves
These are non-breaking changes features that are marked as unstable or have not been started. Given that they are features, they can be added in future minor versions. However, for the sake of simplicity, shipping major versions with little to no dangling
unstable_features makes for a clean story and clear starting point for both end users and contributors.RouterProvideronErrorprop RouterProvider onError #12958useRouteConsolidate route data access with new type-safe hook:useRoute#14418fetcher.resetAdd fetcher.reset() API #14207instrumentationObservability #14376Rejected Changes
ViewTransitioncomponentViewTranstionis a canary feature at the time of this proposal. Even if it is released by the time v8 comes out, we would be forced to make React 19.3(?) the minimum required React version very shortly after it coming out. Currently we have no intention of dropping React 18 support, so this is out of the question for React Router v8. We should continue to consider the possibility of removing our APIs in favor of React's built-in support in the long term, but more research will be required to determine the impactBeta Was this translation helpful? Give feedback.
All reactions