31 KiB
react-router
6.26.2
Patch Changes
- Updated dependencies:
@remix-run/router@1.19.2
6.26.1
Patch Changes
- Rename
unstable_patchRoutesOnMiss
tounstable_patchRoutesOnNavigation
to match new behavior (#11888) - Updated dependencies:
@remix-run/router@1.19.1
6.26.0
Minor Changes
- Add a new
replace(url, init?)
alternative toredirect(url, init?)
that performs ahistory.replaceState
instead of ahistory.pushState
on client-side navigation redirects (#11811)
Patch Changes
- Fix initial hydration behavior when using
future.v7_partialHydration
along withunstable_patchRoutesOnMiss
(#11838)- During initial hydration,
router.state.matches
will now include any partial matches so that we can render ancestorHydrateFallback
components
- During initial hydration,
- Updated dependencies:
@remix-run/router@1.19.0
6.25.1
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.
6.25.0
Minor Changes
- Stabilize
future.unstable_skipActionErrorRevalidation
asfuture.v7_skipActionErrorRevalidation
(#11769)- When this flag is enabled, actions will not automatically trigger a revalidation if they return/throw a
Response
with a4xx
/5xx
status code - You may still opt-into revalidation via
shouldRevalidate
- This also changes
shouldRevalidate
'sunstable_actionStatus
parameter toactionStatus
- When this flag is enabled, actions will not automatically trigger a revalidation if they return/throw a
Patch Changes
- Fix regression and properly decode paths inside
useMatch
so matches/params reflect decoded params (#11789) - Updated dependencies:
@remix-run/router@1.18.0
6.24.1
Patch Changes
- When using
future.v7_relativeSplatPath
, properly resolve relative paths in splat routes that are children of pathless routes (#11633) - Updated dependencies:
@remix-run/router@1.17.1
6.24.0
Minor Changes
- Add support for Lazy Route Discovery (a.k.a. Fog of War) (#11626)
- RFC: https://github.com/remix-run/react-router/discussions/11113
unstable_patchRoutesOnMiss
docs: https://reactrouter.com/en/main/routers/create-browser-router
Patch Changes
- Updated dependencies:
@remix-run/router@1.17.0
6.23.1
Patch Changes
- allow undefined to be resolved with
<Await>
(#11513) - Updated dependencies:
@remix-run/router@1.16.1
6.23.0
Minor Changes
- Add a new
unstable_dataStrategy
configuration option (#11098)- This option allows Data Router applications to take control over the approach for executing route loaders and actions
- The default implementation is today's behavior, to fetch all loaders in parallel, but this option allows users to implement more advanced data flows including Remix single-fetch, middleware/context APIs, automatic loader caching, and more
Patch Changes
- Updated dependencies:
@remix-run/router@1.16.0
6.22.3
Patch Changes
- Updated dependencies:
@remix-run/router@1.15.3
6.22.2
Patch Changes
- Updated dependencies:
@remix-run/router@1.15.2
6.22.1
Patch Changes
- Fix encoding/decoding issues with pre-encoded dynamic parameter values (#11199)
- Updated dependencies:
@remix-run/router@1.15.1
6.22.0
Patch Changes
- Updated dependencies:
@remix-run/router@1.15.0
6.21.3
Patch Changes
- Remove leftover
unstable_
prefix fromBlocker
/BlockerFunction
types (#11187)
6.21.2
Patch Changes
- Updated dependencies:
@remix-run/router@1.14.2
6.21.1
Patch Changes
- Fix bug with
route.lazy
not working correctly on initial SPA load whenv7_partialHydration
is specified (#11121) - Updated dependencies:
@remix-run/router@1.14.1
6.21.0
Minor Changes
-
Add a new
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:<BrowserRouter> <Routes> <Route path="/" element={<Home />} /> <Route path="dashboard/*" element={<Dashboard />} /> </Routes> </BrowserRouter>
Any paths like
/dashboard
,/dashboard/team
,/dashboard/projects
will match theDashboard
route. The dashboard component itself can then render nested<Routes>
:function Dashboard() { return ( <div> <h2>Dashboard</h2> <nav> <Link to="/">Dashboard Home</Link> <Link to="team">Team</Link> <Link to="projects">Projects</Link> </nav> <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"."
:// If we are on URL /dashboard/team, and we want to link to /dashboard/team: function DashboardTeam() { // ❌ This is broken and results in <a href="/dashboard"> return <Link to=".">A broken link to the Current URL</Link>; // ✅ 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:
<BrowserRouter> <Routes> <Route path="dashboard"> <Route path="*" element={<Dashboard />} /> </Route> </Routes> </BrowserRouter>
Now, a
<Link to=".">
and a<Link to="..">
inside theDashboard
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 routeaction
if you the user doesn't specify a form action: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:<BrowserRouter> <Routes> <Route path="dashboard"> <Route index path="*" element={<Dashboard />} /> </Route> </Routes> </BrowserRouter> function Dashboard() { return ( <div> <h2>Dashboard</h2> <nav> <Link to="..">Dashboard Home</Link> <Link to="../team">Team</Link> <Link to="../projects">Projects</Link> </nav> <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".
Patch Changes
- Properly handle falsy error values in ErrorBoundary's (#11071)
- Updated dependencies:
@remix-run/router@1.14.0
6.20.1
Patch Changes
- Revert the
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) - Updated dependencies:
@remix-run/router@1.13.1
6.20.0
Minor Changes
- Export the
PathParam
type from the public API (#10719)
Patch Changes
- Fix bug with
resolveTo
in splat routes (#11045)- This is a follow up to #10983 to handle the few other code paths using
getPathContributingMatches
- This removes the
UNSAFE_getPathContributingMatches
export from@remix-run/router
since we no longer need this in thereact-router
/react-router-dom
layers
- This is a follow up to #10983 to handle the few other code paths using
- Updated dependencies:
@remix-run/router@1.13.0
6.19.0
Minor Changes
- Add
unstable_flushSync
option touseNavigate
/useSumbit
/fetcher.load
/fetcher.submit
to opt-out ofReact.startTransition
and intoReactDOM.flushSync
for state updates (#11005) - Remove the
unstable_
prefix from theuseBlocker
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 fromunstable_usePrompt
due to differences in how browsers handlewindow.confirm
that prevent React Router from guaranteeing consistent/correct behavior. (#10991)
Patch Changes
-
Fix
useActionData
so it returns proper contextual action data and not any action data in the tree (#11023) -
Fix bug in
useResolvedPath
that would causeuseResolvedPath(".")
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.
- ⚠️ This fixes a quite long-standing bug specifically for
-
Updated dependencies:
@remix-run/router@1.12.0
6.18.0
Patch Changes
- Fix the
future
prop onBrowserRouter
,HashRouter
andMemoryRouter
so that it accepts aPartial<FutureConfig>
instead of requiring all flags to be included. (#10962) - Updated dependencies:
@remix-run/router@1.11.0
6.17.0
Patch Changes
- Fix
RouterProvider
future
prop type to be aPartial<FutureConfig>
so that not all flags must be specified (#10900) - Updated dependencies:
@remix-run/router@1.10.0
6.16.0
Minor Changes
- In order to move towards stricter TypeScript support in the future, we're aiming to replace current usages of
any
withunknown
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 toany
in React Router and are overridden withunknown
in Remix. In React Router v7 we plan to move these tounknown
as a breaking change. (#10843)Location
now accepts a generic for thelocation.state
valueActionFunctionArgs
/ActionFunction
/LoaderFunctionArgs
/LoaderFunction
now accept a generic for thecontext
parameter (only used in SSR usages viacreateStaticHandler
)- The return type of
useMatches
(now exported asUIMatch
) accepts generics formatch.data
andmatch.handle
- both of which were already set tounknown
- Move the
@private
class exportErrorResponse
to anUNSAFE_ErrorResponseImpl
export since it is an implementation detail and there should be no construction ofErrorResponse
instances in userland. This frees us up to export atype ErrorResponse
which correlates to an instance of the class viaInstanceType
. Userland code should only ever be usingErrorResponse
as a type and should be type-narrowing viaisRouteErrorResponse
. (#10811) - Export
ShouldRevalidateFunctionArgs
interface (#10797) - Removed private/internal APIs only required for the Remix v1 backwards compatibility layer and no longer needed in Remix v2 (
_isFetchActionRedirect
,_hasFetcherDoneAnything
) (#10715)
Patch Changes
- Updated dependencies:
@remix-run/router@1.9.0
6.15.0
Minor Changes
- Add's a new
redirectDocument()
function which allows users to specify that a redirect from aloader
/action
should trigger a document reload (viawindow.location
) instead of attempting to navigate to the redirected location via React Router (#10705)
Patch Changes
- Ensure
useRevalidator
is referentially stable across re-renders if revalidations are not actively occurring (#10707) - Updated dependencies:
@remix-run/router@1.8.0
6.14.2
Patch Changes
- Updated dependencies:
@remix-run/router@1.7.2
6.14.1
Patch Changes
- Fix loop in
unstable_useBlocker
when used with an unstable blocker function (#10652) - Fix issues with reused blockers on subsequent navigations (#10656)
- Updated dependencies:
@remix-run/router@1.7.1
6.14.0
Patch Changes
- Strip
basename
from locations provided tounstable_useBlocker
functions to matchuseLocation
(#10573) - Fix
generatePath
when passed a numeric0
value parameter (#10612) - Fix
unstable_useBlocker
key issues inStrictMode
(#10573) - Fix
tsc --skipLibCheck:false
issues on React 17 (#10622) - Upgrade
typescript
to 5.1 (#10581) - Updated dependencies:
@remix-run/router@1.7.0
6.13.0
Minor Changes
-
Move
React.startTransition
usage behind a future flag to avoid issues with existing incompatibleSuspense
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 ofstartTransition
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 auseMemo
. (#10596)Existing behavior will no longer include
React.startTransition
:<BrowserRouter> <Routes>{/*...*/}</Routes> </BrowserRouter> <RouterProvider router={router} />
If you wish to enable
React.startTransition
, pass the future flag to your component:<BrowserRouter future={{ v7_startTransition: true }}> <Routes>{/*...*/}</Routes> </BrowserRouter> <RouterProvider router={router} future={{ v7_startTransition: true }}/>
Patch Changes
- Work around webpack/terser
React.startTransition
minification bug in production mode (#10588)
6.12.1
!WARNING] Please use version `6.13.0` or later instead of `6.12.1`. This version suffers from a `webpack`/`terser` minification issue resulting in invalid minified code in your resulting production bundles which can cause issues in your application. See [#10579](https://github.com/remix-run/react-router/issues/10579) for more details.
Patch Changes
- Adjust feature detection of
React.startTransition
to fix webpack + react 17 compilation error (#10569)
6.12.0
Minor Changes
- Wrap internal router state updates with
React.startTransition
if it exists (#10438)
Patch Changes
- Updated dependencies:
@remix-run/router@1.6.3
6.11.2
Patch Changes
- Fix
basename
duplication in descendant<Routes>
inside a<RouterProvider>
(#10492) - Updated dependencies:
@remix-run/router@1.6.2
6.11.1
Patch Changes
- Fix usage of
Component
API within descendant<Routes>
(#10434) - Fix bug when calling
useNavigate
from<Routes>
inside a<RouterProvider>
(#10432) - Fix usage of
<Navigate>
in strict mode when using a data router (#10435) - Updated dependencies:
@remix-run/router@1.6.1
6.11.0
Patch Changes
- Log loader/action errors to the console in dev for easier stack trace evaluation (#10286)
- Fix bug preventing rendering of descendant
<Routes>
whenRouterProvider
errors existed (#10374) - Fix inadvertent re-renders when using
Component
instead ofelement
on a route definition (#10287) - Fix detection of
useNavigate
in the render cycle by setting theactiveRef
in a layout effect, allowing thenavigate
function to be passed to child components and called in auseEffect
there. (#10394) - Switched from
useSyncExternalStore
touseState
for internal@remix-run/router
router state syncing in<RouterProvider>
. We found some subtle bugs where router state updates got propagated before other normaluseState
updates, which could lead to footguns inuseEffect
calls. (#10377, #10409) - Allow
useRevalidator()
to resolve a loader-driven error boundary scenario (#10369) - Avoid unnecessary unsubscribe/resubscribes on router state changes (#10409)
- When using a
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 onuseLocation()
. When usingBrowserRouter
, these hooks remain unstable across location changes because they still rely onuseLocation()
. (#10336) - Updated dependencies:
@remix-run/router@1.6.0
6.10.0
Minor Changes
-
Added support for Future Flags in React Router. The first flag being introduced is
future.v7_normalizeFormMethod
which will normalize the exposeduseNavigation()/useFetcher()
formMethod
fields as uppercase HTTP methods to align with thefetch()
behavior. (#10207)- When
future.v7_normalizeFormMethod === false
(default v6 behavior),useNavigation().formMethod
is lowercaseuseFetcher().formMethod
is lowercase
- When
future.v7_normalizeFormMethod === true
:useNavigation().formMethod
is uppercaseuseFetcher().formMethod
is uppercase
- When
Patch Changes
- Fix route ID generation when using Fragments in
createRoutesFromElements
(#10193) - Updated dependencies:
@remix-run/router@1.5.0
6.9.0
Minor Changes
-
React Router now supports an alternative way to define your route
element
anderrorElement
fields as React Components instead of React Elements. You can instead pass a React Component to the newComponent
andErrorBoundary
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 doComponent
/ErrorBoundary
will "win". (#10045)Example JSON Syntax
// Both of these work the same: const elementRoutes = [{ path: '/', element: <Home />, errorElement: <HomeError />, }] const componentRoutes = [{ path: '/', Component: Home, ErrorBoundary: HomeError, }] function Home() { ... } function HomeError() { ... }
Example JSX Syntax
// Both of these work the same: const elementRoutes = createRoutesFromElements( <Route path='/' element={<Home />} errorElement={<HomeError /> } /> ); const componentRoutes = createRoutesFromElements( <Route path='/' Component={Home} ErrorBoundary={HomeError} /> ); function Home() { ... } function HomeError() { ... }
-
Introducing Lazy Route Modules! (#10045)
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
orsubmitting
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.// 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:
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) ? ( <h1> {error.status} {error.statusText} </h1> ) : ( <h1>{error.message || error}</h1> ); }
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.
-
Updated dependencies:
@remix-run/router@1.4.0
Patch Changes
- Fix
generatePath
incorrectly applying parameters in some cases (#10078) - Improve memoization for context providers to avoid unnecessary re-renders (#9983)
6.8.2
Patch Changes
- Updated dependencies:
@remix-run/router@1.3.3
6.8.1
Patch Changes
- Remove inaccurate console warning for POP navigations and update active blocker logic (#10030)
- Updated dependencies:
@remix-run/router@1.3.2
6.8.0
Patch Changes
- Updated dependencies:
@remix-run/router@1.3.1
6.7.0
Minor Changes
- Add
unstable_useBlocker
hook for blocking navigations within the app's location origin (#9709)
Patch Changes
- Fix
generatePath
when optional params are present (#9764) - Update
<Await>
to acceptReactNode
as children function return result (#9896) - Updated dependencies:
@remix-run/router@1.3.0
6.6.2
Patch Changes
- Ensure
useId
consistency during SSR (#9805)
6.6.1
Patch Changes
- Updated dependencies:
@remix-run/router@1.2.1
6.6.0
Patch Changes
- Prevent
useLoaderData
usage inerrorElement
(#9735) - Updated dependencies:
@remix-run/router@1.2.0
6.5.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
Minor Changes
- Allows optional routes and optional static segments (#9650)
Patch Changes
- Stop incorrectly matching on partial named parameters, i.e.
<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 theuseParams
call site: (#9506)
// Old behavior at URL /prefix-123
<Route path="prefix-:id" element={<Comp /> }>
function Comp() {
let params = useParams(); // { id: '123' }
let id = params.id; // "123"
...
}
// New behavior at URL /prefix-123
<Route path=":id" element={<Comp /> }>
function Comp() {
let params = useParams(); // { id: 'prefix-123' }
let id = params.id.replace(/^prefix-/, ''); // "123"
...
}
- Updated dependencies:
@remix-run/router@1.1.0
6.4.5
Patch Changes
- Updated dependencies:
@remix-run/router@1.0.5
6.4.4
Patch Changes
- Updated dependencies:
@remix-run/router@1.0.4
6.4.3
Patch Changes
useRoutes
should be able to returnnull
when passinglocationArg
(#9485)- fix
initialEntries
type increateMemoryRouter
(#9498) - Updated dependencies:
@remix-run/router@1.0.3
6.4.2
Patch Changes
- Fix
IndexRouteObject
andNonIndexRouteObject
types to makehasErrorElement
optional (#9394) - Enhance console error messages for invalid usage of data router hooks (#9311)
- If an index route has children, it will result in a runtime error. We have strengthened our
RouteObject
/RouteProps
types to surface the error in TypeScript. (#9366) - Updated dependencies:
@remix-run/router@1.0.2
6.4.1
Patch Changes
- Preserve state from
initialEntries
(#9288) - Updated dependencies:
@remix-run/router@1.0.1
6.4.0
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
- Create your router with
createMemoryRouter
- Render your router with
<RouterProvider>
- Load data with a Route
loader
and mutate with a Routeaction
- Handle errors with Route
errorElement
- Defer non-critical data with
defer
andAwait
Bug Fixes
- Path resolution is now trailing slash agnostic (#8861)
useLocation
returns the scoped location inside a<Routes location>
component (#9094)
Updated Dependencies
@remix-run/router@1.0.0