react-router
@remix-run/router@1.19.2
unstable_patchRoutesOnMiss
to unstable_patchRoutesOnNavigation
to match new behavior (#11888)@remix-run/router@1.19.1
replace(url, init?)
alternative to redirect(url, init?)
that performs a history.replaceState
instead of a history.pushState
on client-side navigation redirects (#11811)future.v7_partialHydration
along with unstable_patchRoutesOnMiss
(#11838)router.state.matches
will now include any partial matches so that we can render ancestor HydrateFallback
components@remix-run/router@1.19.0
No significant changes to this package were made in this release. See the repo CHANGELOG.md
for an overview of all changes in v6.25.1.
future.unstable_skipActionErrorRevalidation
as future.v7_skipActionErrorRevalidation
(#11769)Response
with a 4xx
/5xx
status codeshouldRevalidate
shouldRevalidate
's unstable_actionStatus
parameter to actionStatus
useMatch
so matches/params reflect decoded params (#11789)@remix-run/router@1.18.0
future.v7_relativeSplatPath
, properly resolve relative paths in splat routes that are children of pathless routes (#11633)@remix-run/router@1.17.1
unstable_patchRoutesOnMiss
docs: https://reactrouter.com/en/main/routers/create-browser-router@remix-run/router@1.17.0
<Await>
(#11513)@remix-run/router@1.16.1
unstable_dataStrategy
configuration option (#11098)@remix-run/router@1.16.0
@remix-run/router@1.15.3
@remix-run/router@1.15.2
@remix-run/router@1.15.1
@remix-run/router@1.15.0
unstable_
prefix from Blocker
/BlockerFunction
types (#11187)@remix-run/router@1.14.2
route.lazy
not working correctly on initial SPA load when v7_partialHydration
is specified (#11121)@remix-run/router@1.14.1
future.v7_relativeSplatPath
flag to implement a breaking bug fix to relative routing when inside a splat route. (#11087)This fix was originally added in #10983 and was later reverted in #11078 because it was determined that a large number of existing applications were relying on the buggy behavior (see #11052)
The Bug
The buggy behavior is that without this flag, the default behavior when resolving relative paths is to ignore any splat (*
) portion of the current route path.
The Background
This decision was originally made thinking that it would make the concept of nested different sections of your apps in <Routes>
easier if relative routing would replace the current splat:
jsx
<BrowserRouter>
<Routes>
<Route path="/" element={<Home />} />
<Route path="dashboard/*" element={<Dashboard />} />
</Routes>
</BrowserRouter>
Any paths like /dashboard
, /dashboard/team
, /dashboard/projects
will match the Dashboard
route. The dashboard component itself can then render nested <Routes>
:
```jsx function Dashboard() { return (
<Routes>
<Route path="/" element={<DashboardHome />} />
<Route path="team" element={<DashboardTeam />} />
<Route path="projects" element={<DashboardProjects />} />
</Routes>
</div>
);
} ```
Now, all links and route paths are relative to the router above them. This makes code splitting and compartmentalizing your app really easy. You could render the Dashboard
as its own independent app, or embed it into your large app without making any changes to it.
The Problem
The problem is that this concept of ignoring part of a path breaks a lot of other assumptions in React Router - namely that "."
always means the current location pathname for that route. When we ignore the splat portion, we start getting invalid paths when using "."
:
```jsx // If we are on URL /dashboard/team, and we want to link to /dashboard/team: function DashboardTeam() { // ❌ This is broken and results in return A broken link to the Current URL;
// ✅ This is fixed but super unintuitive since we're already at /dashboard/team!
return <Link to="./team">A broken link to the Current URL</Link>;
} ```
We've also introduced an issue that we can no longer move our DashboardTeam
component around our route hierarchy easily - since it behaves differently if we're underneath a non-splat route, such as /dashboard/:widget
. Now, our "."
links will, properly point to ourself inclusive of the dynamic param value so behavior will break from it's corresponding usage in a /dashboard/*
route.
Even worse, consider a nested splat route configuration:
jsx
<BrowserRouter>
<Routes>
<Route path="dashboard">
<Route path="*" element={<Dashboard />} />
</Route>
</Routes>
</BrowserRouter>
Now, a <Link to=".">
and a <Link to="..">
inside the Dashboard
component go to the same place! That is definitely not correct!
Another common issue arose in Data Routers (and Remix) where any <Form>
should post to it's own route action
if you the user doesn't specify a form action:
jsx
let router = createBrowserRouter({
path: "/dashboard",
children: [
{
path: "*",
action: dashboardAction,
Component() {
// ❌ This form is broken! It throws a 405 error when it submits because
// it tries to submit to /dashboard (without the splat value) and the parent
// `/dashboard` route doesn't have an action
return <Form method="post">...</Form>;
},
},
],
});
This is just a compounded issue from the above because the default location for a Form
to submit to is itself ("."
) - and if we ignore the splat portion, that now resolves to the parent route.
The Solution
If you are leveraging this behavior, it's recommended to enable the future flag, move your splat to it's own route, and leverage ../
for any links to "sibling" pages:
```jsx
function Dashboard() { return (
<Routes>
<Route path="/" element={<DashboardHome />} />
<Route path="team" element={<DashboardTeam />} />
<Route path="projects" element={<DashboardProjects />} />
</Router>
</div>
);
} ```
This way, .
means "the full current pathname for my route" in all cases (including static, dynamic, and splat routes) and ..
always means "my parents pathname".
@remix-run/router@1.14.0
useResolvedPath
fix for splat routes due to a large number of applications that were relying on the buggy behavior (see https://github.com/remix-run/react-router/issues/11052#issuecomment-1836589329). We plan to re-introduce this fix behind a future flag in the next minor version. (#11078)@remix-run/router@1.13.1
PathParam
type from the public API (#10719)resolveTo
in splat routes (#11045)getPathContributingMatches
UNSAFE_getPathContributingMatches
export from @remix-run/router
since we no longer need this in the react-router
/react-router-dom
layers@remix-run/router@1.13.0
unstable_flushSync
option to useNavigate
/useSumbit
/fetcher.load
/fetcher.submit
to opt-out of React.startTransition
and into ReactDOM.flushSync
for state updates (#11005)unstable_
prefix from the useBlocker
hook as it's been in use for enough time that we are confident in the API. We do not plan to remove the prefix from unstable_usePrompt
due to differences in how browsers handle window.confirm
that prevent React Router from guaranteeing consistent/correct behavior. (#10991)Fix useActionData
so it returns proper contextual action data and not any action data in the tree (#11023)
Fix bug in useResolvedPath
that would cause useResolvedPath(".")
in a splat route to lose the splat portion of the URL path. (#10983)
⚠️ This fixes a quite long-standing bug specifically for "."
paths inside a splat route which incorrectly dropped the splat portion of the URL. If you are relative routing via "."
inside a splat route in your application you should double check that your logic is not relying on this buggy behavior and update accordingly.
Updated dependencies:
@remix-run/router@1.12.0
future
prop on BrowserRouter
, HashRouter
and MemoryRouter
so that it accepts a Partial<FutureConfig>
instead of requiring all flags to be included. (#10962)@remix-run/router@1.11.0
RouterProvider
future
prop type to be a Partial<FutureConfig>
so that not all flags must be specified (#10900)@remix-run/router@1.10.0
any
with unknown
on exposed typings for user-provided data. To do this in Remix v2 without introducing breaking changes in React Router v6, we have added generics to a number of shared types. These continue to default to any
in React Router and are overridden with unknown
in Remix. In React Router v7 we plan to move these to unknown
as a breaking change. (#10843)Location
now accepts a generic for the location.state
valueActionFunctionArgs
/ActionFunction
/LoaderFunctionArgs
/LoaderFunction
now accept a generic for the context
parameter (only used in SSR usages via createStaticHandler
)useMatches
(now exported as UIMatch
) accepts generics for match.data
and match.handle
- both of which were already set to unknown
@private
class export ErrorResponse
to an UNSAFE_ErrorResponseImpl
export since it is an implementation detail and there should be no construction of ErrorResponse
instances in userland. This frees us up to export a type ErrorResponse
which correlates to an instance of the class via InstanceType
. Userland code should only ever be using ErrorResponse
as a type and should be type-narrowing via isRouteErrorResponse
. (#10811)ShouldRevalidateFunctionArgs
interface (#10797)_isFetchActionRedirect
, _hasFetcherDoneAnything
) (#10715)@remix-run/router@1.9.0
redirectDocument()
function which allows users to specify that a redirect from a loader
/action
should trigger a document reload (via window.location
) instead of attempting to navigate to the redirected location via React Router (#10705)useRevalidator
is referentially stable across re-renders if revalidations are not actively occurring (#10707)@remix-run/router@1.8.0
@remix-run/router@1.7.2
unstable_useBlocker
when used with an unstable blocker function (#10652)@remix-run/router@1.7.1
basename
from locations provided to unstable_useBlocker
functions to match useLocation
(#10573)generatePath
when passed a numeric 0
value parameter (#10612)unstable_useBlocker
key issues in StrictMode
(#10573)tsc --skipLibCheck:false
issues on React 17 (#10622)typescript
to 5.1 (#10581)@remix-run/router@1.7.0
React.startTransition
usage behind a future flag to avoid issues with existing incompatible Suspense
usages. We recommend folks adopting this flag to be better compatible with React concurrent mode, but if you run into issues you can continue without the use of startTransition
until v7. Issues usually boils down to creating net-new promises during the render cycle, so if you run into issues you should either lift your promise creation out of the render cycle or put it behind a useMemo
. (#10596)Existing behavior will no longer include React.startTransition
:
```jsx
If you wish to enable React.startTransition
, pass the future flag to your component:
```jsx
React.startTransition
minification bug in production mode (#10588)[!WARNING] Please use version
6.13.0
or later instead of6.12.1
. This version suffers from awebpack
/terser
minification issue resulting in invalid minified code in your resulting production bundles which can cause issues in your application. See #10579 for more details.
React.startTransition
to fix webpack + react 17 compilation error (#10569)React.startTransition
if it exists (#10438)@remix-run/router@1.6.3
basename
duplication in descendant <Routes>
inside a <RouterProvider>
(#10492)@remix-run/router@1.6.2
Component
API within descendant <Routes>
(#10434)useNavigate
from <Routes>
inside a <RouterProvider>
(#10432)<Navigate>
in strict mode when using a data router (#10435)@remix-run/router@1.6.1
<Routes>
when RouterProvider
errors existed (#10374)Component
instead of element
on a route definition (#10287)useNavigate
in the render cycle by setting the activeRef
in a layout effect, allowing the navigate
function to be passed to child components and called in a useEffect
there. (#10394)useSyncExternalStore
to useState
for internal @remix-run/router
router state syncing in <RouterProvider>
. We found some subtle bugs where router state updates got propagated before other normal useState
updates, which could lead to footguns in useEffect
calls. (#10377, #10409)useRevalidator()
to resolve a loader-driven error boundary scenario (#10369)RouterProvider
, useNavigate
/useSubmit
/fetcher.submit
are now stable across location changes, since we can handle relative routing via the @remix-run/router
instance and get rid of our dependence on useLocation()
. When using BrowserRouter
, these hooks remain unstable across location changes because they still rely on useLocation()
. (#10336)@remix-run/router@1.6.0
Added support for Future Flags in React Router. The first flag being introduced is future.v7_normalizeFormMethod
which will normalize the exposed useNavigation()/useFetcher()
formMethod
fields as uppercase HTTP methods to align with the fetch()
behavior. (#10207)
When future.v7_normalizeFormMethod === false
(default v6 behavior),
useNavigation().formMethod
is lowercaseuseFetcher().formMethod
is lowercasefuture.v7_normalizeFormMethod === true
:useNavigation().formMethod
is uppercaseuseFetcher().formMethod
is uppercasecreateRoutesFromElements
(#10193)@remix-run/router@1.5.0
element
and errorElement
fields as React Components instead of React Elements. You can instead pass a React Component to the new Component
and ErrorBoundary
fields if you choose. There is no functional difference between the two, so use whichever approach you prefer 😀. You shouldn't be defining both, but if you do Component
/ErrorBoundary
will "win". (#10045)Example JSON Syntax
```jsx
// Both of these work the same:
const elementRoutes = [{
path: '/',
element:
const componentRoutes = [{ path: '/', Component: Home, ErrorBoundary: HomeError, }]
function Home() { ... } function HomeError() { ... } ```
Example JSX Syntax
```jsx
// Both of these work the same:
const elementRoutes = createRoutesFromElements(
const componentRoutes = createRoutesFromElements(
function Home() { ... } function HomeError() { ... } ```
In order to keep your application bundles small and support code-splitting of your routes, we've introduced a new lazy()
route property. This is an async function that resolves the non-route-matching portions of your route definition (loader
, action
, element
/Component
, errorElement
/ErrorBoundary
, shouldRevalidate
, handle
).
Lazy routes are resolved on initial load and during the loading
or submitting
phase of a navigation or fetcher call. You cannot lazily define route-matching properties (path
, index
, children
) since we only execute your lazy route functions after we've matched known routes.
Your lazy
functions will typically return the result of a dynamic import.
jsx
// In this example, we assume most folks land on the homepage so we include that
// in our critical-path bundle, but then we lazily load modules for /a and /b so
// they don't load until the user navigates to those routes
let routes = createRoutesFromElements(
<Route path="/" element={<Layout />}>
<Route index element={<Home />} />
<Route path="a" lazy={() => import("./a")} />
<Route path="b" lazy={() => import("./b")} />
</Route>
);
Then in your lazy route modules, export the properties you want defined for the route:
```jsx export async function loader({ request }) { let data = await fetchData(request); return json(data); }
// Export a Component
directly instead of needing to create a React Element from it
export function Component() {
let data = useLoaderData();
return (
<>
<h1>You made it!</h1>
<p>{data}</p>
);
}
// Export an ErrorBoundary
directly instead of needing to create a React Element from it
export function ErrorBoundary() {
let error = useRouteError();
return isRouteErrorResponse(error) ? (
An example of this in action can be found in the examples/lazy-loading-router-provider
directory of the repository.
🙌 Huge thanks to @rossipedia for the Initial Proposal and POC Implementation.
@remix-run/router@1.4.0
generatePath
incorrectly applying parameters in some cases (#10078)@remix-run/router@1.3.3
@remix-run/router@1.3.2
@remix-run/router@1.3.1
unstable_useBlocker
hook for blocking navigations within the app's location origin (#9709)generatePath
when optional params are present (#9764)<Await>
to accept ReactNode
as children function return result (#9896)@remix-run/router@1.3.0
useId
consistency during SSR (#9805)@remix-run/router@1.2.1
useLoaderData
usage in errorElement
(#9735)@remix-run/router@1.2.0
This release introduces support for Optional Route Segments. Now, adding a ?
to the end of any path segment will make that entire segment optional. This works for both static segments and dynamic parameters.
Optional Params Examples
<Route path=":lang?/about>
will match:/:lang/about
/about
<Route path="/multistep/:widget1?/widget2?/widget3?">
will match:/multistep
/multistep/:widget1
/multistep/:widget1/:widget2
/multistep/:widget1/:widget2/:widget3
Optional Static Segment Example
<Route path="/home?">
will match:/
/home
<Route path="/fr?/about">
will match:/about
/fr/about
<Route path="prefix-:param">
, to align with how splat parameters work. If you were previously relying on this behavior then it's recommended to extract the static portion of the path at the useParams
call site: (#9506)```jsx
// Old behavior at URL /prefix-123
function Comp() { let params = useParams(); // { id: '123' } let id = params.id; // "123" ... }
// New behavior at URL /prefix-123
function Comp() { let params = useParams(); // { id: 'prefix-123' } let id = params.id.replace(/^prefix-/, ''); // "123" ... } ```
@remix-run/router@1.1.0
@remix-run/router@1.0.5
@remix-run/router@1.0.4
useRoutes
should be able to return null
when passing locationArg
(#9485)initialEntries
type in createMemoryRouter
(#9498)@remix-run/router@1.0.3
IndexRouteObject
and NonIndexRouteObject
types to make hasErrorElement
optional (#9394)RouteObject
/RouteProps
types to surface the error in TypeScript. (#9366)@remix-run/router@1.0.2
initialEntries
(#9288)@remix-run/router@1.0.1
Whoa this is a big one! 6.4.0
brings all the data loading and mutation APIs over from Remix. Here's a quick high level overview, but it's recommended you go check out the docs, especially the feature overview and the tutorial.
New APIs
createMemoryRouter
<RouterProvider>
loader
and mutate with a Route action
errorElement
defer
and Await
Bug Fixes
useLocation
returns the scoped location inside a <Routes location>
component (#9094)Updated Dependencies
@remix-run/router@1.0.0