React Router v7 Prerelease

We just published our first pre-release of React Router v7

This marks a significant step toward providing the Incremental Path to React 19 for millions of applications using React Router, as well as several great improvements for Remix users.

Feel free to check out the docs and start getting your hands dirty right now. Just a quick reminder: this is a prerelease, we fully expect there to be bugs. If you run into any please open up a ticket with a reproduction so we can get it fixed.

Roadmap to React Router v7

We still have a lot of work to do before we feel comfortable publishing v7:

Fix any bugs in our new features and finalize the APIs
Finish the documentation
Make Remix v2 -> React Router v3 upgrade boring
Make React Router v6 -> React Router v7 upgrade boring
Make adopting the Vite plugin in React Router v7 boring

We’re officially entering the “boring” stage of the release process, which is good because we’re pretty committed to major upgrades being boring.

Even though this major upgrade should be boring, this new version is very exciting! That’s why we are eager to get this pre-release into your hands. We believe React Router v7 is at a good point to share, gather feedback, and start working on the nitty gritty details of making that upgrade path as smooth as possible (and it’s honestly already pretty smooth if you’ve been staying up to date on future flags).

What’s new?

Route Pre-Rendering

One of the most common requests for Remix has been to add support for SSG (Static Site Generation). Well, we finally caved and are giving you a super simple API to pre-render whatever pages you want.

Pre-rendering is a build-time operation that generates static HTML and client navigation data payloads for a list of URLs. This is useful for SEO and performance, especially for deployments without server rendering. When pre-rendering, the loader method is used to fetch data at build time.

// vite.config.ts import { reactRouter } from "@react-router/dev/vite"; import { defineConfig } from "vite"; export default defineConfig({ plugins: [ reactRouter({ prerender: ["/", "/about", "/contact"], }), ], });

You can also just pass prerender: true if you want to pre-render all static routes defined in your application (excluding any paths that contain dynamic or splat params):

Read our docs on the pre-render API ↗

routes.ts

Both Remix v1 and v2 came with a built-in file-based routing solution. After trying 2 different conventions (nested folder definitions and flat routing), we have learned that we can’t make everyone happy. Both conventions have developers who love and hate them, and the split is around personal preferences with neither uniquely benefitting the user experience.

Filenames are more limited compared to config-based routes since they have fewer characters to work with. They not only need to include the route path and any parameters—they also need to encode further route configuration (index/layout routes, opting out of nested layouts, escaping special characters, etc.), leading to increasingly elaborate naming conventions.

In addition to file conventions, we've always had config-based routes, because we didn’t want you to be stuck with our conventions if you or your team didn't like them. We've decided to double down on that approach by now always defining routes with a routes.ts config file and letting you and your team decide how to name your files.

// app/routes.ts import type { RouteConfig } from "@react-router/dev/routes"; import { route, index, layout } from "@react-router/dev/routes"; export const routes: RouteConfig = [ index("./home.tsx"), route("about", "./about.tsx"), layout("./auth/layout.tsx", [ route("login", "./auth/login.tsx"), route("register", "./auth/register.tsx"), ]), route("concerts", [ index("./concerts/home.tsx"), route(":city", "./concerts/city.tsx"), route("trending", "./concerts/trending.tsx"), ]), ];

And if you liked our file-based convention, or don’t want to worry about switching things up, you can just keep using it. routes.ts is designed to be a composable, backwards-compatible solution.

// app/routes.ts import { type RouteConfig } from "@react-router/dev/routes"; import { flatRoutes } from "@react-router/fs-routes"; export const routes: RouteConfig = flatRoutes();

Check out the documentation ↗

Improved Type Safety

React Router 7 is also going to come with some major improvements to type safety. We are adding support to automatically give you the types for your route params, server and client loaders and actions, and everything else your route module needs.

// route("blog/:slug", "./blog.tsx"); import type * as Route from "./+types.blog"; export async function loader({ params }: Route.LoaderArgs) { // ^? { slug: string } const blogData = await fetchBlogData(params.slug); return { title: blogData.title, // <- string content: blogData.content, // <- string readTime: blogData.readTime, // <- number }; } export default function BlogPost({ loaderData, // ^? { title: string, content: string, readTime: number } }: Route.ComponentProps) { return ( <> <Header title={loaderData.title} readTime={loaderData.readTime} /> <BlogContent content={loaderData.content} /> </> ); }

We’re still actively developing the API and improving the DX, but the underlying system provides fast and exhaustive types designed to improve your speed of development and help you avoid shipping a whole suite of bugs to production.

As we continue developing this feature, we plan to add support for typesafe links, search params, and all sorts of routing utilities.

Checkout the changelog ↗

New streaming format

If you’re familiar with our work on Single Fetch in Remix, this update will not come as a surprise to you.

In React Router v7, loaders and actions are supercharged to allow you to send down just about whatever you want, such as Date, Error, Promise, RegExp, and more.

export async function loader({ params }: Route.LoaderArgs) { const comments = fetchComments(params.slug); const blogData = await fetchBlogData(params.slug); return { content: blogData.content, // <- string published: blogData.date, // <- Date comments, // <- Promise<Comment[]> }; } export default function BlogPost({ loaderData, // ^? { content: string, published: Date, comments: Promise<Comment[]> } }: Route.ComponentProps) { return ( <> <Header published={loaderData.date} /> <BlogContent content={loaderData.content} /> <Suspense fallback={<CommentsSkeleton />}> <Await resolve={loaderData.comments}> {(comments) => <BlogComments comments={comments} />} </Await> </Suspense> </> ); }

Where’s the RSC?!

If you’ve made it this far, you’re probably wondering why we haven’t mentioned React Server Components.

We are still planning to support the RSC from loaders approach we’ve shared. This feature is dependent on two things:

React 19 (which is still a Release Candidate)
The Vite Environment API, which we anticipate being finished soon

Once these two pieces are stabilized, we will add our support for React Server Components. Since our RSC from loaders approach is not a breaking change, we will not delay the release of React Router v7 just to include it. If v7 is ready but RSC is not, then we’ll release v7 and RSC support will come later in a minor release.

Go check it out

Well, what are you waiting for? Start hacking 💿

Oh, and let us know what you think. You can find us on the Discord or you can simply reply to this email.

- The Remix Team