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.
🐛 Bugfixes
- A
*
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) - Resolution of
<Link to=".">
anduseResolvedPath(".")
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.
✨ Enhancements
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.
💔 Breaking Changes
<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.- The
basename
argument was removed fromuseRoutes
. This reverts the signature touseRoutes(routes, location)
, same as it was previous to beta.4. - Descendant
<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 fromuseParams()
. 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.- Resolution of relative
<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.
💻 Installing
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