React Router v7 did something no prior version did: it merged Remix, Meta’s own full-stack React framework, directly back into React Router itself. What used to be a client-side routing library for single-page apps is now, as of this merger, a genuine full-stack framework with server-side rendering, loaders, actions, middleware, and built-in session management — and it now ships in three distinct modes, which is the detail every developer building a multi-page React app in 2026 actually needs to understand before writing a single route.
Why the merger happened
React Router and Remix had been converging for years before the formal merger — Remix was built on top of React Router’s routing engine, and the two libraries had grown similar enough in capability that maintaining them as separate projects no longer made sense. The result in v7 is one library, `react-router`, that spans the full range from a lightweight client-side router to a complete server-rendering framework, depending entirely on which of its three modes a project chooses.
The three modes, and how to pick one
- Declarative mode is the closest to classic React Router: basic URL-to-component matching, navigation, and active-link states, using familiar APIs like `<Link>`, `useNavigate`, and `useLocation`. It’s the right starting point for a simple client-side app that doesn’t need centralized data loading.
- Data mode moves route configuration outside of React rendering and adds real data-loading and mutation APIs — `loader`, `action`, `useFetcher` — while still running entirely in the browser unless a project sets up server rendering separately. It’s a middle ground for teams that want structured data fetching without committing to a full framework.
- Framework mode is the full-stack option, and the one the React Router team explicitly recommends as the starting point for new applications. React Router controls the build, the server, and the routing together; loaders and actions run server-side with access to request headers, cookies, and real server sessions, and this is the mode that most closely resembles what Remix offered on its own.
Critically, the features across these three modes are additive — moving from Declarative to Data to Framework mode adds capability at the cost of giving up some architectural control, so the choice is really about how much the project wants React Router itself to manage versus how much control the team wants to retain.
Loaders and actions: the core data model
The data-fetching model at the heart of Data and Framework mode is deliberately simple: loaders and actions are plain async functions that return data, with no separate decision tree about fetch caching strategies, server versus client components, or middleware interference to reason through before writing a request. A `loader` function fetches the data a route needs before it renders; an `action` function handles form submissions and mutations. In Framework mode specifically, these run on the server by default, which means authentication checks and permission verification happen before any protected data is ever sent to the browser — a meaningfully different security posture than a client-side-only router, where a protected route is really just a redirect a user’s browser DevTools can bypass.
Building a multi-page app in Framework mode
Framework mode uses a Remix-style file structure under an `app/` directory: a `routes/` folder where each file becomes one route, `entry.client.tsx` for hydration and client-side navigation, and `entry.server.tsx` for the server rendering entry point. Nested routes map naturally to nested URL segments and nested UI — a `dashboard.tsx` route can have a `dashboard.profile.tsx` child route that renders inside it, sharing the parent’s loaded data without re-fetching it. This file-based structure is what lets a multi-page app stay organized as the number of routes grows, instead of a single monolithic router configuration file.
How it compares to Next.js
For teams evaluating full-stack React options in 2026, React Router v7 in Framework mode is a genuine alternative to Next.js, not just a routing library that happens to also do SSR. Its main advantage is simplicity in the data model — loaders and actions avoid the layered decisions Next.js’s App Router requires around server versus client components and fetch caching strategy. Next.js still wins on ecosystem size and tooling investment, particularly for teams already fluent in it or committed to Vercel’s platform. Teams migrating from Remix have a largely mechanical rename path to v7’s framework mode; teams already on React Router v6 have an incremental path to framework mode without a full rewrite.
The takeaway
React Router in 2026 isn’t the same tool most developers learned it as a few years ago. The Remix merger turned it into a genuine three-tier system, from lightweight client routing up to a full-stack framework, and the right starting point depends entirely on how much a project needs from the server. For a new multi-page React app, framework mode is the officially recommended default — understanding why it’s structured as loaders, actions, and a file-based route tree is the real prerequisite before writing the first route.