What is react-router?
The react-router npm package is a declarative routing library for React, allowing you to add navigation functionality to your React applications. It enables you to handle URL routing, match routes to your React components, and manage navigation state in a single-page application (SPA) environment.
What are react-router's main functionalities?
Basic Routing
This code demonstrates how to set up basic routing in a React application using react-router. It includes navigation links and route components that render different components based on the URL path.
import { BrowserRouter as Router, Route, Link } from 'react-router-dom';
function App() {
return (
<Router>
<div>
<nav>
<ul>
<li>
<Link to='/'>Home</Link>
</li>
<li>
<Link to='/about'>About</Link>
</li>
</ul>
</nav>
<Route exact path='/' component={Home} />
<Route path='/about' component={About} />
</div>
</Router>
);
}
function Home() {
return <h2>Home</h2>;
}
function About() {
return <h2>About</h2>;
}
Dynamic Routing
This code snippet shows how to implement dynamic routing with path parameters. The User component will render with the appropriate user ID based on the URL.
import { BrowserRouter as Router, Route, Link } from 'react-router-dom';
function App() {
return (
<Router>
<div>
<ul>
<li>
<Link to='/users/1'>User 1</Link>
</li>
<li>
<Link to='/users/2'>User 2</Link>
</li>
</ul>
<Route path='/users/:id' component={User} />
</div>
</Router>
);
}
function User({ match }) {
return <h2>User ID: {match.params.id}</h2>;
}
Nested Routing
Nested routing allows you to create routes within routes. This example shows a Layout component with a nested Dashboard route.
import { BrowserRouter as Router, Route, Link, Switch } from 'react-router-dom';
function App() {
return (
<Router>
<Route path='/' component={Layout} />
</Router>
);
}
function Layout({ match }) {
return (
<div>
<nav>
<Link to={`${match.url}dashboard`}>Dashboard</Link>
</nav>
<Switch>
<Route path={`${match.path}dashboard`} component={Dashboard} />
</Switch>
</div>
);
}
function Dashboard() {
return <h2>Dashboard</h2>;
}
Protected Routes
Protected routes are used to restrict access to certain parts of your application. This example shows a route that renders a component only if the user is authenticated, otherwise it redirects to a login page.
import { BrowserRouter as Router, Route, Redirect } from 'react-router-dom';
function App() {
return (
<Router>
<Route path='/protected' render={() => (
isAuthenticated() ? (
<ProtectedComponent />
) : (
<Redirect to='/login' />
)
)} />
</Router>
);
}
function isAuthenticated() {
// Authentication logic here
return true;
}
function ProtectedComponent() {
return <h2>Protected</h2>;
}
Other packages similar to react-router
vue-router
Vue-router is the official router for Vue.js. It provides similar functionalities for Vue applications as react-router does for React applications, including nested routes, dynamic segments, and navigation guards. However, it is designed to work seamlessly with Vue's reactivity system.
reach-router
Reach Router is another routing library for React, which aims to be more accessible and simpler to use than react-router. It has a smaller API surface area and focuses on accessibility by managing focus after route transitions. However, as of my knowledge cutoff in 2023, Reach Router has been officially merged with React Router, and its features have been integrated into React Router v6.
React Router
The react-router
package is the heart of React Router and provides all
the core functionality for both
react-router-dom
and
react-router-native
.
If you're using React Router, you should never import
anything directly from
the react-router
package, but you should have everything you need in either
react-router-dom
or react-router-native
. Both of those packages re-export
everything from react-router
.
If you'd like to extend React Router and you know what you're doing, you should
add react-router
as a peer dependency, not a regular dependency in your
package.
v6.27.0
Date: 2024-10-11
What's Changed
Stabilized APIs
This release stabilizes a handful of "unstable" APIs in preparation for the pending React Router v7 release (see these posts for more info):
unstable_dataStrategy
→ dataStrategy
(createBrowserRouter
and friends) (Docs)unstable_patchRoutesOnNavigation
→ patchRoutesOnNavigation
(createBrowserRouter
and friends) (Docs)unstable_flushSync
→ flushSync
(useSubmit
, fetcher.load
, fetcher.submit
) (Docs)unstable_viewTransition
→ viewTransition
(<Link>
, <Form>
, useNavigate
, useSubmit
) (Docs)
Minor Changes
- Stabilize the
unstable_flushSync
option for navigations and fetchers (#11989) - Stabilize the
unstable_viewTransition
option for navigations and the corresponding unstable_useViewTransitionState
hook (#11989) - Stabilize
unstable_dataStrategy
(#11974) - Stabilize
unstable_patchRoutesOnNavigation
(#11973)
- Add new
PatchRoutesOnNavigationFunctionArgs
type for convenience (#11967)
Patch Changes
- Fix bug when submitting to the current contextual route (parent route with an index child) when an
?index
param already exists from a prior submission (#12003) - Fix
useFormAction
bug - when removing ?index
param it would not keep other non-Remix index
params (#12003) - Fix bug with fetchers not persisting
preventScrollReset
through redirects during concurrent fetches (#11999) - Avoid unnecessary
console.error
on fetcher abort due to back-to-back revalidation calls (#12050) - Fix bugs with
partialHydration
when hydrating with errors (#12070) - Remove internal cache to fix issues with interrupted
patchRoutesOnNavigation
calls (#12055)
- ⚠️ This may be a breaking change if you were relying on this behavior in the
unstable_
API - We used to cache in-progress calls to
patchRoutesOnNavigation
internally so that multiple navigations with the same start/end would only execute the function once and use the same promise - However, this approach was at odds with
patch
short circuiting if a navigation was interrupted (and the request.signal
aborted) since the first invocation's patch
would no-op - This cache also made some assumptions as to what a valid cache key might be - and is oblivious to any other application-state changes that may have occurred
- So, the cache has been removed because in most cases, repeated calls to something like
import()
for async routes will already be cached automatically - and if not it's easy enough for users to implement this cache in userland
- Remove internal
discoveredRoutes
FIFO queue from unstable_patchRoutesOnNavigation
(#11977)
- ⚠️ This may be a breaking change if you were relying on this behavior in the
unstable_
API - This was originally implemented as an optimization but it proved to be a bit too limiting
- If you need this optimization you can implement your own cache inside
patchRoutesOnNavigation
- Fix types for
RouteObject
within PatchRoutesOnNavigationFunction
's patch
method so it doesn't expect agnostic route objects passed to patch
(#11967) - Expose errors thrown from
patchRoutesOnNavigation
directly to useRouteError
instead of wrapping them in a 400 ErrorResponse
instance (#12111)
Full Changelog: v6.26.2...v6.27.0