NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
npm · #1611 most downloaded on npm
Declarative routing for React
Last release 9 days ago
15 Sep 2026
Ships on a steady schedule
a new release about every 2 weeks
Nearly every release is documented
notes for 60 of the last 60 stable releases
1 version withdrawn
withdrawn after publishing
13 years old
1186 releases · first in 2014
This pre-release brings the data abstractions from Remix to React Router. There will be more complete release notes for the v6.4 final release. Here a
This pre-release brings the data abstractions from Remix to React Router. There will be more complete release notes for the v6.4 final release. Here are a couple quick resources to take it for a spin:
We have a lot more documentation work to do around guides, examples, and use-cases, but the API reference documentation on the new beta site is already quite complete.
npm i react-router-dom@next
Enjoy!
Nothing published for this version
One column per quarter.
Added the v5 to v6 backwards compatibility package 💜 (https://github.com/remix-run/react-router/pull/8752). The official guide can be found in this di
Full Changelog: https://github.com/remix-run/react-router/compare/v6.2.2...v6.3.0
Date: 2022-03-31
Full Changelog: v6.2.2...v6.3.0
Fixed nested splat routes that begin with special URL-safe characters
Full Changelog: https://github.com/remix-run/react-router/compare/v6.2.1...v6.2.2
Date: 2022-02-28
Full Changelog: v6.2.1...v6.2.2
Nothing published for this version
This release updates the internal history dependency to 5.2.0.
This release updates the internal history dependency to 5.2.0.
Full Changelog: https://github.com/remix-run/react-router/compare/v6.2.0...v6.2.1
Date: 2021-12-17
history dependency to 5.2.0.Full Changelog: v6.2.0...v6.2.1
Fixed the RouteProps element type, which should be a ReactNode
RouteProps element type, which should be a ReactNode (#8473)useOutlet for top-level routes (#8483)Full Changelog: https://github.com/remix-run/react-router/compare/v6.1.1...v6.2.0
Date: 2021-12-17
RouteProps element type, which should be a ReactNode (#8473)useOutlet for top-level routes (#8483)Full Changelog: v6.1.1...v6.2.0
In v6.1.0 we inadvertently shipped a new, undocumented API that will likely introduce bugs (#7586). We have flagged HistoryRouter as unstable_HistoryR
In v6.1.0 we inadvertently shipped a new, undocumented API that will likely introduce bugs (#7586). We have flagged HistoryRouter as unstable_HistoryRouter, as this API will likely need to change before a new major release.
Full Changelog: https://github.com/remix-run/react-router/compare/v6.1.0...v6.1.1
Date: 2021-12-11
HistoryRouter as unstable_HistoryRouter, as this API will likely need to change before a new major release.Full Changelog: v6.1.0...v6.1.1
Fixed a bug that broke support for base64 encoded IDs on nested routes
<Outlet> can now receive a context prop. This value is passed to child routes and is accessible via the new useOutletContext hook. See the API docs for details. (#8461)<NavLink> can now receive a child function for access to its props. (#8164)useMatch and matchPath. For example, when you call useMatch("foo/:bar/:baz"), the path is parsed and the return type will be PathMatch<"bar" | "baz">. (#8030)Full Changelog: https://github.com/remix-run/react-router/compare/v6.0.1...v6.1.0
Date: 2021-12-10
<Outlet> can now receive a context prop. This value is passed to child routes and is accessible via the new useOutletContext hook. See the API docs for details. (#8461)<NavLink> can now receive a child function for access to its props. (#8164)useMatch and matchPath. For example, when you call useMatch("foo/:bar/:baz"), the path is parsed and the return type will be PathMatch<"bar" | "baz">. (#8030)Full Changelog: v6.0.2...v6.1.0
Added the reloadDocument prop to . This allows to function like a normal anchor tag by reloading the document after navigation while maintaining the r
reloadDocument prop to <Link>. This allows <Link> to function like a normal anchor tag by reloading the document after navigation while maintaining the relative to resolution.https://github.com/remix-run/react-router/compare/v6.0.1...v6.0.2
Date: 2021-11-09
reloadDocument prop to <Link>. This allows <Link> to function like a normal anchor tag by reloading the document after navigation while maintaining the relative to resolution (#8283)Full Changelog: v6.0.1...v6.0.2
Add invariant for using inside to help people make the change
<StaticRouter location> value (#8243)<Route> inside <Routes> to help people make the change (#8238)Date: 2021-11-05
<StaticRouter location> value (#8243)<Route> inside <Routes> to help people make the change (#8238)Full Changelog: v6.0.0...v6.0.1
Please go read our blog post for more information on all the great stuff in v6 including notes about how to upgrade from React Router v5 and Reach Rou
React Router v6 is here!
Please go read our blog post for more information on all the great stuff in v6 including notes about how to upgrade from React Router v5 and Reach Router.
Date: 2021-11-03
React Router v6 is here!
Please go read our blog post for more information on all the great stuff in v6 including notes about how to upgrade from React Router v5 and Reach Router.
Remember last week when we said
Remember last week when we said
We anticipate this will be the last beta release before v6 stable next week.
Yeah, about that … 😅
We found and squashed a few high-priority bugs that needed to be addressed first. But it's coming very soon, we promise! In the mean time, here's what you'll get from our eight-est and greatest beta release:
useHref that resulted in the incorrect resolved value in cases where a basename is used on the <Router /> component (See #8133 and #8142 for details).* path value) are now correctly ranked ahead of layout routes.We've added lots of goodies to our docs and examples, and there's a lot more yet to come. Take a look and see if you find something that makes your work a little easier! We think the lazy loading and custom query parsing examples are particularly cool! 🤓
The major change in this release could also be classified as a bugfix or a breaking change, depending on how you look at it. We essentialy altered the…
In this release we made a small but significant change to how <Link to=".."> works. This is going to help out a lot if you were trying to use links in a * route.
We have also backed out our blocking/prompt APIs for the stable v6 release. We will revisit this post 6.0 when we have a little more time to get it right.
The major change in this release could also be classified as a bugfix or a breaking change, depending on how you look at it. We essentialy altered the way <Link to=".."> works. See #8086 for the motivation behind this change.
You'll probably want to reread the section in the v5 => v6 migration guide about <Link to> values (it has been updated), but it basically boils down to this: any leading .. segment in a <Link to> value traverses "up" one route and builds upon that route's path instead of just removing one URL segment. This feature really completes the story of relative routes and links.
We could consider this a bugfix, since this is how it was always intended to work in the first place. Without it, you'd have a difficult time linking predictably in * routes because your <a href> would be different depending on the number of segments in the current URL.
The reason this could also be considered a breaking change is that .. now works slightly differently in <Link to> than it would in <a href>. When you have <a href=".."> it operates on the URL pathname, removing one segment of the current URL. However, since many routes really only match a single segment of the URL, there is often no difference between <Link to=".."> and <a href="..">.
useBlocker(), usePrompt(), and <Prompt> for now. We will revisit these post 6.0 when we have more time to get it right. But we don't want it to block (see what I did there) the release of all the other awesome stuff we've got in v6.We anticipate this will be the last beta release before v6 stable next week. Please give it a shot and let us know how it goes!
If you're thinking about upgrading to v6, I published a few notes this past week that may help you:
<Redirect> elements from any <Switch>es you may have in your v5 app and how you can get better SEO in the process if you're currently relying on client-side redirects.<Route> elements, which won't work in v6.Both of those posts contain steps you can take today in your v5 app without upgrading to v6.
We are also developing a backwards compat lib that should help some of you upgrade from v5 to v6. We'll post more about this when it's ready.
Development for v6 has switched from dev to the main branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
However, this makes it difficult to link to the parent route when you're in a splat route. See #8086. This will be a breaking change.
No big enhancements in this release, just squashing bugs and writing lots of tests! Also, we are hard at work on cranking out examples for v6. See the end of this post for an update on our roadmap between here and v6 stable.
We have begun creating some examples for v6 that we hope will help developers make effective use of all the new features we have. So far, we have examples for the following:
<Outlet> APIuseNavigate() hook, the <Navigate> element, and location.stateuseSearchParams() hook<StaticRouter> on the server and uses a <BrowserRouter> with ReactDOM.hydrate() on the clientEach example includes a button in the README that allows you to instantly launch a running instance on StackBlitz that you can play with. We hope you enjoy exploring!
<NavLink> match only whole URL segments instead of pieces. This means that <NavLink to="/home/users"> will still be active at /home/users, but not at /home/users2. See #7523path) never match unless one of their children do. See #8085<Routes>. This reverses a decision that we made in beta.5 to remove them. See #8073*) match only after a / in the URL. This means that <Route path="files*"> will always match as if it were <Route path="files/*">. The router will issue a warning if your route path ends with * but not /*We are very close to a stable release! The last big code changes we need to make are:
<Link to=".."> operates on the URL pathname. However, this makes it difficult to link to the parent route when you're in a splat route. See #8086. This will be a breaking change.useBlocker() and <Prompt> in our initial v6 release, with plans to revisit them and possibly add them back at some point in the future. I still need to write up something here that explains our rationale. This will also be a breaking change.<Routes location> prop will be in v6, but it isn't ideal for animation.Development for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
This week's release adds some much-needed polish to a few niche features of the router: splat routes (a route that uses a * path) and basenames. It al
This week's release adds some much-needed polish to a few niche features of the router: splat routes (a route that uses a * path) and basenames. It also adds a renderMatches API that completes the story for those of you who may have been using react-router-config in v4 and v5.
* in a child route path matches after a slash following its parent route path. This fixes some situations where the * was overly greedy (see #7972)<Link to="."> and useResolvedPath(".") values are fixed in splat routes. Previously these resolved relative to the parent route's path. They now resolve relative to the path of the route that rendered them.This release makes it easier to work with apps that have multiple entry points. Using the <Router basename> prop allows React Router to be easily deployed on only a portion of a larger site by using a portion of the URL pathname (the "basename") to transparently prefix all route paths and link navigations.
For example, you can deploy one React Router app at the /inbox URL prefix, and another one at the /admin prefix. These base URLs represent two different entry points into your app, each with its own bundles. The rest of your site, including the root / URL could be rendered by something other than React Router, for example by your server framework of choice.
In the bundle for each entry point, simply initialize React Router with the basename of that entry point.
<Router basename="/inbox">
// ...
</Router>
Then define your routes and link paths without using the /inbox URL prefix in any of them. The entire app will run relative to that prefix.
Another improvement in this release is the addition of the renderMatches API, which is the complement of matchRoutes. These APIs are both very low-level and should not normally be needed. But they are sometimes nice to use if you are doing your own data loading using the array of matches that you get back from matchRoutes.
matchRoutes and renderMatches are the equivalent of the react-router-config package we shipped in v4 and v5, just built directly into the router instead of in a separate package.
<Routes basename> has moved to <Router basename>. This prop is also available on all router variants (<BrowserRouter>, <HashRouter>, etc.).useLocation().pathname no longer includes the basename, if present.basename argument was removed from useRoutes. This reverts the signature to useRoutes(routes, location), same as it was previous to beta.4.<Routes> do not get the params from their parents. This helps a set of <Routes> to be more portable by decoupling it from the params of its parents and makes it easier to know which params will be returned from useParams(). If you were relying on this behavior previously, you'll need to pass along the params manually to the elements rendered by the descendant <Routes>. See this comment for an example of how this is to be done and for a potential workaround if you really need the old behavior.match.pathname in a splat route now includes the portion of the pathname matched by the *. This makes the * param behave much more like other dynamic :id-style params.<Link>s in splat routes is changed now because the entire pathname that was matched by that route is now different (see previous bullet). Instead of resolving relative to the portion of the pathname before the *, paths resolve relative to the full pathname that was matched by the route.Development for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
Last week we released a lot of nice little bug features, but we did get a little carried away and let a little bug slip through with relative path res
Last week we released a lot of nice little bug features, but we did get a little carried away and let a little bug slip through with relative path resolution. Our bad! That nasty lil' guy is squashed in this week's beta. 🐛
And there's more! Let's dive in…
Params type which is now generic, so you can add your own types if you know what to expect from functions that return query parameters. (#8019)// before
let { valid, invalid } = useParams(); // No problems here!
let match = useMatch("profile/:userId");
let userId = match?.params.user; // wrong param, but TS doesn't know that!
// after:
let { valid, invalid } = useParams<"valid" | "key">(); // Property 'invalid' does not exist on type 'Params<"valid" | "key">'
let match = useMatch<"userId">("profile/:userId");
let userId = match?.params.user; // Property 'user' does not exist on type 'Params<"userId">'
There was quite a bit of discussion in #7335 from people who are using constants to define their route paths. In this style, paths are often written as absolute paths from the root / URL. These constants are then able to be used both in <Route path> definitions as well as <Link to> values. It usually looks something like this:
const USERS_PATH = "/users";
const USERS_INDEX_PATH = `${USERS_PATH}/`;
const USER_PROFILE_PATH = `${USERS_PATH}/:id`;
function UsersRoutes() {
return (
<Routes>
<Route path={USERS_PATH} element={<UsersLayout />}>
<Route path={USERS_INDEX_PATH} element={<UsersIndex />} />
<Route path={USER_PROFILE_PATH} element={<UserProfile />} />
</Route>
</Routes>
);
}
This style of use is now fully supported in v6. This is great for people who write their apps like this, but it technically could cause some breakage if you were using absolute paths (that start with /) in nested routes in previous betas. To fix this, simply remove the / from the beginning of any route paths that are meant to be relative. React Router will throw an error if you are using absolute paths that don't match their parent route paths. Hopefully this should help you find them if you are upgrading.
If you were using <Route path="/"> to indicate an index route, you can now use the new <Route index> prop to accomplish the same thing. The index prop makes it easy to scan a route config to find the index route. It also provides a guarantee that nobody will ever add children to that route.
Here's the same route config as the one above, but rewritten with relative paths and the index prop:
function UsersRoutes() {
return (
<Routes>
<Route path="users" element={<UsersLayout />}>
<Route index element={<UsersIndex />} />
<Route path=":id" element={<UserProfile />} />
</Route>
</Routes>
);
}
A lot of our work on React Router is about doing the least surprising thing for our users. Allowing absolute paths in nested routes gets us a little closer to that goal!
Removed the ability for nested route paths to begin with a / and not contain the complete path of their parent routes. This was necessary in order to introduce support for absolute paths in nested routes, described in detail above
Removed the createRoutesFromArray utility function. You can now pass your routes directly to useRoutes or matchRoutes without passing it through createRoutesFromArray first
Removed the PartialRouteObject type. If you were importing and using this type before, use RouteObject instead, which has been updated to make all properties optional
The useRoutes API has changed slightly. Instead of passing a basename as the second argument, you should instead pass it as a named property in an object:
// Before
useRoutes([...routes], basename);
// After
useRoutes([...routes], { basename });
matchPath function now returns match.pattern instead of match.path, which is a little more descriptive about what it actually isDevelopment for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
Loads of goodies for you this week, as well as a few breaking changes for all of you eager beavers who are brave enough to use beta software in produc…
Loads of goodies for you this week, as well as a few breaking changes for all of you eager beavers who are brave enough to use beta software in production! 🦫
(seriously, thank you all for helping us tighten up our APIs and fix nasty bugs)
NavLink no longer supports the activeClassName or activeStyle props. Instead, we provide a more powerful API that allows you to pass functions to either the className or style props to conditionally apply values based on the link's active state. While a bit more verbose in some cases, this offers a nicer experience for folks who use utility class-based CSS. (#7194)// Before
<NavLink className="link" activeClassName="active-link" />
<NavLink style={{ color: "blue" }} activeStyle={{ color: "green" }} />
// After
<NavLink
className={({ isActive }) =>
`link ${
isActive
? "active-link"
: // Couldn't do this before!
"inactive-link"
}`
}
/>
<NavLink style={({ isActive }) => ({ color: isActive ? "green" : "blue" })} />
Note: You can always abstract over this feature in a custom
NavLinkif you prefer the old v5 API.
useRoutes API has changed slightly. Instead of passing a basename as the second argument, you should instead pass it as a named property in an object:// Before
useRoutes([...routes], basename);
// After
useRoutes([...routes], { basename });
basename prop on Routes is treated as case-insensitive (#7997)useNavigate previously used the incorrect pathname when called from parent routes when the URL matches one of its children. This fix also applies to useSearchParams (#7880)Routes and useRoutes now allow you to override the location, which may be useful when building some modal interfaces and route transition animations. We are working hard to update our docs to include examples for advanced patterns where this might be useful, but in the mean time this also brings Routes closer to feature parity with v5's Switch via the location prop. (#7117)useClickHandler and usePressHandler to make customizing Links a bit easier. (#7998)
Link, be sure to render an actual HTML anchor element, otherwise your app will likely be inaccessible without a significant amount of additional work which, I assure you, you don't want to do!Development for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
Thanks to @andrelandgraf, @dhulme, @fgatti675, @hugmanrique, @MeiKatz, @chaance and @mjackson for your contributions!
Fixed a bug that broke paths in nested routes
displayName back to <Link /> and <NavLink /> componentsnavigate function now prepends hash and search strings by default:navigate({ search: "?foo=1&bar=2" }); // this works as expected!
navigate({ search: "foo=1&bar=2" }); // this also works!
useParams now returns parameters from nested <Route />s when called in a parent <Route />Development for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
Thanks to @liho98, @wojtekmaj, @cravend, @chaance and @mjackson for your contributions!
Enjoy!
We're on the road to a stable v6 release!
We're on the road to a stable v6 release!
There are no new features in this release since beta.0, but a handful of squashed bugs, perf enhancements, and DX improvements for TypeScript users.
+ characters no longer get decoded into spaces, and that little * is just a little less greedy (e.g., app/* no longer matches apples/*).Link and navigate should properly respect the basename when using absolute paths.navigator into a separate context object, meaning your components that call useNavigate will probably render a little less often. Wowza, much perf!react-router-dom and react-router-native now re-exports all types exported from react-routerDevelopment for v6 is chugging along on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
Thanks to @brookslybrand, @bogdansoare, @chaance and @mjackson for your contributions!
Enjoy!
There are a few breaking changes from alpha.5:
Today we are very happy to release the first beta of React Router version 6!
No new features in this release since alpha.5, besides the fact that we are now using history v5 stable in various places behind the scenes.
There are a few breaking changes from alpha.5:
<Route preload> into the experimental release channeluseLocationPending into the experimental release channelreact-router a regular dependency of react-router-dom and react-router-nativehistory a peer dependencyuseResolvedLocation to useResolvedPath to be more inline with the naming in the history APIresolveLocation to resolvePath to be more inline with the naming in the history APItsc as input into the Rollup toolchain, so sourcemaps go all the way back to the original source instead of stopping at the tsc-generated filesDevelopment for v6 is happening on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history react-router-dom@next
Or, if you're on React Native:
$ yarn add history react-router-native@next
Now that we are in beta, you can expect fewer breaking changes (if any) between releases in the next channel. We are actively developing features targeted at supporting suspense for data loading in the experimental channel. The main thing left to do is documentation and guides (and fix bugs, ofc). If you can spare some time, we'd love to have some help :)
We are actively working on documentation. For now, if you're just interested in testing things out you may be interested in the getting started guide. If you're interested in upgrading an existing app, please check out the v5 to v6 migration guide. There is also a comprehensive API Reference.
Enjoy!
Added and route.preload (JSX and useRoutes) APIs. The preload function will be called when the route has matched and is about to render.
<Route preload> and route.preload (JSX and useRoutes) APIs. The preload function will be called when the route has matched and is about to render.<NavLink end> and <NavLink caseSensitive> to better control matching behavior of <NavLink>sWarning: This release breaks compatibility with 6.0.0-alpha.4
<Router history> prop and moved responsibility for setting up/tearing down the listener (history.listen) into the wrapper components (<BrowserRouter>, <HashRouter>, etc.). <Router> is now a controlled component that just sets up context for the rest of the app.generatePath so it never returns placeholders. Instead, it will throw if a needed placeholder is missing.useTransition hook. We will publish our own "experimental" channel very soon with this hook added back in, but it won't be added back to the "next" channel (or stable) until it goes stable in React core.basename functionality to the migration guideDevelopment for v6 is happening on the dev branch.
If you'd like to test it out, install from npm:
$ npm install react-router@next react-router-dom@next
Or, if you're on React Native:
$ yarn add react-router@next react-router-native@next
We are actively working on documentation. For now, if you're just interested in testing things out you may be interested in the getting started guide. If you're interested in upgrading an existing app, please check out the v5 to v6 migration guide.
Enjoy!
Lots of great stuff in this release, especially if you like Intellisense :)
Lots of great stuff in this release, especially if you like Intellisense :)
useInRouterContext hook for determining if you're in the context of a router or notuseLocationPending hook (experimental)matchPath function for manually matching paths to URL pathnamesNote: experimental features rely on an experimental release of React and will probably be moved into a separate "experimental" release channel in the near future.
Warning: This release breaks compatibility with 6.0.0-alpha.3
useSearchParams now returns [searchParams, setSearchParams] (similar to useState). setSearchParams is a wrapper for navigate that updates the query string on the current URL. See the updated guide on working with the query string.<StaticRouter context> API. We don't support navigation on the initial render in v6, so this API is unnecessary.useMatch takes a route path (instead of a link to value as it did previously). It should have always taken a route path; this was just a simple oversight.Development for v6 is happening on the dev branch.
If you'd like to test it out, install from npm:
$ npm install react-router@next react-router-dom@next
Or, if you're on React Native:
$ yarn add react-router@next react-router-native@next
We are actively working on documentation. For now, if you're just interested in testing things out you may be interested in the getting started guide. If you're interested in upgrading an existing app, please check out the v5 to v6 migration guide.
Enjoy!
Added a new useSearchParams hook (see f59ee5488bc343cf3c957b7e0cc395ef5eb572d2)
useSearchParams hook (see f59ee5488bc343cf3c957b7e0cc395ef5eb572d2)The useSearchParams hook returns a URLSearchParams object created from the current location.search string. This is a feature that people have wanted for a while, but we were always hesitant to ship a full-blown query parser with the router. Well, now that we have URLSearchParams widely available, we don't have to. I wrote up a small guide about how to use useSearchParams if you'd like to read more.
Warning: This release breaks compatibility with 6.0.0-alpha.2
Redirect (and redirectTo in useRoutes) was removed (see cbcd398276efaad31e5e994fdb2f80ca454eb859)React won't let us change the state in an ancestor component on the initial render w/out warning, so we had to remove the <Redirect> component, as well as the ability to do a navigate() on the initial render. You can still render a <Navigate>, but it won't actually update the page until the next render.
If you really need to redirect on the initial render, you can either a) do it on your server (probably best, so it can be cached at the HTTP level instead of doing it in every user's browser) or b) do it outside of React Router (e.g. using the history API directly).
Development for v6 is happening on the dev branch.
If you'd like to test it out, install from npm:
$ npm install react-router@next react-router-dom@next
Or, if you're on React Native:
$ yarn add react-router@next react-router-native@next
We are actively working on documentation. For now, if you're just interested in testing things out you may be interested in the getting started guide. If you're interested in upgrading an existing app, please check out the v5 to v6 migration guide.
Enjoy!
This release fixes a few bugs with the previous alpha, namely:
This release fixes a few bugs with the previous alpha, namely:
<Link>s on the server (see https://github.com/ReactTraining/react-router/pull/7126, thanks @danpantry)Also, we added a new doc about adding React Router to your web project whether you're using create-react-app, Webpack, Parcel, or just plain 'ol <script> tags. Thanks @chancestrickland!
Development for v6 is happening on the dev branch.
If you'd like to test it out, install from npm:
$ npm install react-router@next react-router-dom@next
Or, if you're on React Native:
$ yarn add react-router@next react-router-native@next
We are actively working on documentation. For now, if you're just interested in testing things out you may be interested in the getting started guide. If you're interested in upgrading an existing app, please check out the v5 to v6 migration guide.
Enjoy!
Moved history from peerDependencies to dependencies. This should make it easier for people to install and test.
Moved history from peerDependencies to dependencies. This should make it easier for people to install and test.
If you'd like to test it out, install from npm:
$ npm install react-router@next react-router-dom@next
Or, if you're on React Native:
$ yarn add react-router@next react-router-native@next
Please note that although there are several breaking changes we are still working on the migration path and will continue to publish improvements and…
First alpha release of the next major version of React Router, version 6. A few of the highlights are:
<Route>s<Route> ranking with a new <Routes> APInavigate APIuseRoutes + matchRoutes for using object-based routing APIDevelopment for v6 is happening on the dev branch.
If you'd like to test it out, install from npm:
$ npm install history@5 react-router@6 react-router-dom@6
Or, if you're on React Native:
$ yarn add history@5 react-router@6 react-router-native@6
We are actively working on documentation. For now, if you're just interested in testing things out you may be interested in the getting started guide. If you're interested in upgrading an existing app, please check out the v5 to v6 migration guide.
Please note that although there are several breaking changes we are still working on the migration path and will continue to publish improvements and helpers in v5 that should help you upgrade as smoothly as possible. We are not done with v5. Heck, we're still cutting releases of v3.
This release addresses several long-standing issues and pitfalls with previous releases. We are focused on providing a smooth upgrade path for both v4/5 users and v3 users who would like to make the jump to v6. We will be publishing more very soon.
Enjoy!
We removed the mini-create-react-context dependency, moving it into an internal module to eliminate peer dependency warnings for users on React 18 (#9
We removed the mini-create-react-context dependency, moving it into an internal module to eliminate peer dependency warnings for users on React 18 (#9382).
Full Changelog: https://github.com/remix-run/react-router/compare/v5.3.3...v5.3.4
This release fixes a bad version selector in react-router-native.
This release fixes a bad version selector in react-router-native.
Fix: make v5 Router compatible with v18 StrictMode by @jgoz in https://github.com/remix-run/react-router/pull/8831
This release adds missing LICENSE files to the published build.
This release adds missing LICENSE files to the published build.
This release fixes a bug with so that, when the to location is the same as the current, the history state entry is replaced instead of pushed to the s
This release fixes a bug with <Link> so that, when the to location is the same as the current, the history state entry is replaced instead of pushed to the stack. See https://github.com/remix-run/react-router/issues/5362 for details. 🥳
Thanks to @guidobouman for the PR and for everyone else who weighed in for the fix!
This release includes a notable performance boost by separating the "Router" context from the "History" context internally. We also allow every elemen
This release includes a notable performance boost by separating the "Router" context from the "History" context internally. We also allow every element type for Link's component prop and support a sensitive prop on NavLink for control over case sensitive matching.
Enjoy!
sensitive prop on NavLink (#7251 by @caseywebdev)component prop type check (#7276 by @ypyakymiv)mini-create-react-context (#7288 by @patricksmms)history to its own context (#7103 by @illuminist)Fix lingering error on React 15
Fix issue with useParams reading from null object
Add useParams, useLocation, useHistory, and useRouteMatch hooks
useParams, useLocation, useHistory, and useRouteMatch hooks (d6224d6a)forwardRef in <Link> (b5528ed6)<Link to> and <NavLink to> (#5331, #5368)<Link component> API (#5437)<Route children> elements when the <Route> does not match (96656595)Reduced component depth in withRouter() HOC.
Thanks to @StringEpsilon for putting this list together. Enjoy!
Removed deprecated lifecycle methods componentWillMount and componentWillReceiveProps
Please ensure you have upgraded both react-router and react-router-dom (react-router-native for RN users) to the exact same version. If different versions of those two packages are in your application, you will get errors when using <Link> and other react-router-dom-specific components. You can ensure you have the correct versions of both packages in your app using npm ls react-router react-router-dom.
withRouter() or a <Route/> instead.// Be careful, this won't work anymore!
import BrowserRouter from 'react-router-dom/BrowserRouter';
import { Route } from 'react-router-dom';
<BrowserRouter>
<Route />
</BrowserRouter>
Refactor as follows:
// These are both from the same build and use the same context object
// so there won't be a mismatch :)
import { BrowserRouter, Route } from 'react-router-dom';
<Route /> now supports an array of paths - #5889 (thanks @baronswindle)<Route path={["/BigApple", "/NYC", "NewYork"]} component={NewYork} />
<Route /> now supports multiple child nodes when using react >= 16.0.componentWillMount and componentWillReceiveProps<StrictMode/><Link /> not working properly with target="_self" - #6138 (thanks @ericyang89)eval in development to be compliant with unsafe-eval CSP - #6611babel-preset-envStop using eval in development to be compliant with unsafe-eval CSP (see #6611)
eval in development to be compliant with unsafe-eval CSP (see #6611)Fixed tree-shaking with Webpack (see #6464 and #6465)
createRef in <Link innerRef> (see #6567)throw an error when using 2 different builds (dev only, see b2c6fa0725b7ff1ed762064d633b26b6293e0140)Fixed import of react-is in the CommonJS build (see #6445)
import of react-is in the CommonJS build (see #6445)prop-types dependency for ESM build (see #6438)Fixed prop-type warning when using forwardRef (see #6417, thanks @frehner and @eXon)
<Route component> prop-type warning when using forwardRef (see #6417, thanks @frehner and @eXon)react-router-config package (see #6415, thanks @Anomen)Include required deprecation warning file for require('react-router/Route') statements (thanks @timdorr)
<Route path> (thanks @baronswindle)<Link rel="_self"> (thanks @ericyang89)require('react-router/Route') statements (thanks @timdorr)Enjoy! 😅
Fixed ESM entry point from 4.4.0-beta.2 🤦♂️
Getting closer to 4.4 final! We've received some great feedback during the past few weeks on the 4.4 beta. Please keep it coming :)
Getting closer to 4.4 final! We've received some great feedback during the past few weeks on the 4.4 beta. Please keep it coming :)
require('react-router/Route')) from any of our packages is no longer supported.<StrictMode>. In fact, we now wrap all our tests in <StrictMode>!<Router> is rendered server side (introduced in a previous 4.4 beta).Enjoy! 😅
This release fixes a few issues with the build in v4.4.0-beta.0 where the 4.4.0-beta.0 version was not specified correctly in the dependencies of reac
This release fixes a few issues with the build in v4.4.0-beta.0 where the 4.4.0-beta.0 version was not specified correctly in the dependencies of react-router-dom.
Also, please be careful which build you are using. Prior to this release, you could mix your import styles, i.e.:
// Be careful, this won't work anymore!
import BrowserRouter from 'react-router-dom/BrowserRouter';
import { Route } from 'react-router-dom';
<BrowserRouter>
<Route />
</BrowserRouter>
The problem here is that, although it may not be obvious the first import is actually using the CommonJS build while the 2nd import is (probably, depending on what your bundler is doing) using the ES modules build. Your bundler can probably handle the variation in module formats just fine, but when you go to run your code you'll see a warning like:
You should not render a <Route> outside a <Router>
Basically, what this means is that <Route> can't find the correct context object because each build has its own context object and the <Router> component was imported from a different build!
Instead, just import both components using the same method:
// These are both from the same build and use the same context object
// so there won't be a mismatch :)
import { BrowserRouter, Route } from 'react-router-dom';
I'm going to try and figure out a better way to detect if you're using 2 different builds so we can give you a better warning.
Enjoy! 😅
Removed all traces of the deprecated componentWillMount and componentWillReceiveProps
This is primarily a maintenance release that is fully backwards compatible with 4.3.1 while also improving compatibility with React 16 and preparing for the future.
The main features of this release are:
<Router> so you can have multiple children, provided you're using React 16componentWillMount and componentWillReceiveProps🚨 If you were accessing our private context API your code will break. If you need stuff on context, use a <Route> or withRouter instead. It's all the same stuff, and that's our public API 🚨
Other housekeeping that was done:
babel-preset-env + a custom list of proposal plugins we use instead of the deprecated babel-preset-es2015 + babel-preset-stage-1react-router-dom and you need some changes in react-router, you don't have to go and rebuild it to test things out. This should make the repo easier to work withAs always, you can try everything out using the next tag:
yarn add react-router@next
yarn add react-router-dom@next
yarn add react-router-config@next
We will be paying close attention to the feedback on this release and hope to release 4.4.0 final soon!
Enjoy 😅
Nothing published for this version
Nothing published for this version
Just a patch to fix an accidental move of warning from a normal dependency to a devDependency, which was causing issues with installation.
Just a patch to fix an accidental move of warning from a normal dependency to a devDependency, which was causing issues with installation.
One other thing to mention, while I have your attention, is the deprecation of react-router-redux. It's no longer maintained and has a number of funda…
The major new things of this release are Redirect with params (see #5209) and the new generatePath API. We also cleaned up the code with Prettier, so browsing through it should be more enjoyable.
One other thing to mention, while I have your attention, is the deprecation of react-router-redux. It's no longer maintained and has a number of fundamental problems (particularly around time travel). Integrating Redux and the DOM History API is challenging because they don't maintain the same semantics and the resulting integration is error prone. Getting to the router context will be easier in future versions of React Router, so the main motivations for needing it will be going away. So, while I would advise against trying to integrate the two, for those that still want this functionality can turn to libraries like @supasate's connected-react-router.
pretty option in generatePath (#6172 by @sibelius)<Link to="?foo=bar"> (#5489 by @pshrmn)generatePath (#5661 by @rybon)<Link> (#5792 by @selbekk)<StaticRouter> (#5722 by @pshrmn)Add sideEffects: false for webpack tree shaking (#6082 by @taylorc93)
Bump hoist-non-react-statics for React 16.3.
hoist-non-react-statics for React 16.3.generatePath in react-router-dom package.Redirect with parameters ([#5209] by @dlindenkreuz)
Mar 26, 2018
<Link to="?foo=bar"> (#5489 by @pshrmn)generatePath (#5661 by @rybon)<Link> (#5792 by @selbekk)<StaticRouter> (#5722 by @pshrmn)Re-run Redirect on props update ([#5162] by @alexilyaev)
Aug 23, 2017
Nothing published for this version
Fixes for the various PropTypes related issues.
Apr 12, 2017
Note: This work is still ongoing, as the React team still has some outstanding issues to figure out themselves. Keep an eye on this issue and the prop-types repo for updates as we all work through this craziness.
Add wrappedComponent to the component returned by withRouter
Apr 11, 2017
wrappedComponent to the component returned by withRouterwrappedComponentRef prop to the component returned by withRouterwithRouterReleased! No code changes from 4.0.0-beta.8
Revert to using context.router for everything since Relay uses context.route
Mar 8, 2017
context.router for everything since Relay uses context.routestaticContext route prop when rendering <Route>s inside a <StaticRouter>match object to <Route>s w/out a path. This also
includes components wrapped using withRouter<Route> pathsNavLink's default activeClassName prop to activeYour coding agent can read these notes before it upgrades. Set up the MCP server →