-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update react-router monorepo to v6.23.1 #2062
Open
renovate
wants to merge
1
commit into
master
Choose a base branch
from
renovate/react-router-monorepo
base: master
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
7 times, most recently
from
April 1, 2023 22:33
d5330da
to
d738530
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.9.0
Update react-router monorepo to v6.10.0
Apr 1, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
2 times, most recently
from
May 1, 2023 21:29
7251bbd
to
1950ff4
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.10.0
Update react-router monorepo to v6.11.0
May 1, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
May 6, 2023 21:47
1950ff4
to
e1378f2
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.11.0
Update react-router monorepo to v6.11.1
May 6, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
2 times, most recently
from
May 20, 2023 18:00
76f2c02
to
38a4f5c
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.11.1
Update react-router monorepo to v6.11.2
May 20, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
May 24, 2023 02:04
38a4f5c
to
cad10a1
Compare
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
June 9, 2023 19:41
cad10a1
to
81eeba0
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.11.2
Update react-router monorepo to v6.12.0
Jun 9, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
June 14, 2023 12:28
81eeba0
to
7dc10f4
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.12.0
Update react-router monorepo to v6.12.1
Jun 14, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
June 17, 2023 16:34
7dc10f4
to
9c0a8ed
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.12.1
Update react-router monorepo to v6.13.0
Jun 17, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
June 26, 2023 22:17
9c0a8ed
to
f206b60
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.13.0
Update react-router monorepo to v6.14.0
Jun 26, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
July 3, 2023 22:51
f206b60
to
9881257
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.14.0
Update react-router monorepo to v6.14.1
Jul 3, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
July 20, 2023 22:45
9881257
to
4c84982
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.14.1
Update react-router monorepo to v6.14.2
Jul 20, 2023
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
August 13, 2023 16:14
4c84982
to
cc84c42
Compare
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
18 times, most recently
from
April 17, 2024 01:03
0e4154e
to
389b045
Compare
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
8 times, most recently
from
April 26, 2024 16:02
727b7bc
to
b5ff792
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.22.3
Update react-router monorepo to v6.23.0
Apr 26, 2024
renovate
bot
force-pushed
the
renovate/react-router-monorepo
branch
from
May 13, 2024 18:42
b5ff792
to
9291a4f
Compare
renovate
bot
changed the title
Update react-router monorepo to v6.23.0
Update react-router monorepo to v6.23.1
May 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
None yet
0 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
6.4.3
->6.23.1
6.4.3
->6.23.1
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
remix-run/react-router (react-router)
v6.23.1
Compare Source
Patch Changes
<Await>
(#11513)@remix-run/router@1.16.1
v6.23.0
Compare Source
Minor Changes
unstable_dataStrategy
configuration option (#11098)Patch Changes
@remix-run/router@1.16.0
v6.22.3
Compare Source
Patch Changes
@remix-run/router@1.15.3
v6.22.2
Compare Source
Patch Changes
@remix-run/router@1.15.2
v6.22.1
: v6.22.1Compare Source
See the changelog for release notes: https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v6221
v6.22.0
Compare Source
Patch Changes
@remix-run/router@1.15.0
v6.21.3
Compare Source
Patch Changes
unstable_
prefix fromBlocker
/BlockerFunction
types (#11187)v6.21.2
Compare Source
v6.21.1
Compare Source
Patch Changes
route.lazy
not working correctly on initial SPA load whenv7_partialHydration
is specified (#11121)@remix-run/router@1.14.1
v6.21.0
Compare Source
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:Any paths like
/dashboard
,/dashboard/team
,/dashboard/projects
will match theDashboard
route. The dashboard component itself can then render nested<Routes>
: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"."
: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:
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: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: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
@remix-run/router@1.14.0
v6.20.1
Compare Source
Patch Changes
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
v6.20.0
Compare Source
Minor Changes
PathParam
type from the public API (#10719)Patch Changes
resolveTo
in splat routes (#11045)getPathContributingMatches
UNSAFE_getPathContributingMatches
export from@remix-run/router
since we no longer need this in thereact-router
/react-router-dom
layers@remix-run/router@1.13.0
v6.19.0
Compare Source
Minor Changes
unstable_flushSync
option touseNavigate
/useSumbit
/fetcher.load
/fetcher.submit
to opt-out ofReact.startTransition
and intoReactDOM.flushSync
for state updates (#11005)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)"."
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
v6.18.0
Compare Source
Patch Changes
future
prop onBrowserRouter
,HashRouter
andMemoryRouter
so that it accepts aPartial<FutureConfig>
instead of requiring all flags to be included. (#10962)@remix-run/router@1.11.0
v6.17.0
Compare Source
Patch Changes
RouterProvider
future
prop type to be aPartial<FutureConfig>
so that not all flags must be specified (#10900)@remix-run/router@1.10.0
v6.16.0
Compare Source
Minor Changes
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
)useMatches
(now exported asUIMatch
) accepts generics formatch.data
andmatch.handle
- both of which were already set tounknown
@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)ShouldRevalidateFunctionArgs
interface (#10797)_isFetchActionRedirect
,_hasFetcherDoneAnything
) (#10715)Patch Changes
@remix-run/router@1.9.0
v6.15.0
Compare Source
Minor Changes
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
useRevalidator
is referentially stable across re-renders if revalidations are not actively occurring (#10707)@remix-run/router@1.8.0
v6.14.2
Compare Source
Patch Changes
@remix-run/router@1.7.2
v6.14.1
Compare Source
Patch Changes
unstable_useBlocker
when used with an unstable blocker function (#10652)@remix-run/router@1.7.1
v6.14.0
Compare Source
Patch Changes
basename
from locations provided tounstable_useBlocker
functions to matchuseLocation
(#10573)generatePath
when passed a numeric0
value parameter (#10612)unstable_useBlocker
key issues inStrictMode
(#10573)tsc --skipLibCheck:false
issues on React 17 (#10622)typescript
to 5.1 (#10581)@remix-run/router@1.7.0
v6.13.0
Compare Source
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
:If you wish to enable
React.startTransition
, pass the future flag to your component:Patch Changes
React.startTransition
minification bug in production mode (#10588)v6.12.1
Compare Source
Patch Changes
React.startTransition
to fix webpack + react 17 compilation error (#10569)v6.12.0
Compare Source
Minor Changes
React.startTransition
if it exists (#10438)Patch Changes
@remix-run/router@1.6.3
v6.11.2
Compare Source
Patch Changes
basename
duplication in descendant<Routes>
inside a<RouterProvider>
(#10492)@remix-run/router@1.6.2
v6.11.1
Compare Source
Patch Changes
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
v6.11.0
Compare Source
Patch Changes
<Routes>
whenRouterProvider
errors existed (#10374)Component
instead ofelement
on a route definition (#10287)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)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)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 onuseLocation()
. When usingBrowserRouter
, these hooks remain unstable across location changes because they still rely onuseLocation()
. (#10336)@remix-run/router@1.6.0
v6.10.0
Compare Source
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)future.v7_normalizeFormMethod === false
(default v6 behavior),useNavigation().formMethod
is lowercaseuseFetcher().formMethod
is lowercasefuture.v7_normalizeFormMethod === true
:useNavigation().formMethod
is uppercaseuseFetcher().formMethod
is uppercasePatch Changes
createRoutesFromElements
(#10193)@remix-run/router@1.5.0
v6.9.0
Compare Source
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
Example JSX Syntax
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.Then in your lazy route modules, export the properties you want defined for the route:
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
generatePath
incorrectly applying parameters in some cases (#10078)v6.8.2
Compare Source
Patch Changes
@remix-run/router@1.3.3
v6.8.1
Compare Source
Patch Changes
@remix-run/router@1.3.2
v6.8.0
Compare Source
Patch Changes
@remix-run/router@1.3.1
v6.7.0
Compare Source
Minor Changes
unstable_useBlocker
hook for blocking navigations within the app's location origin (#9709)Patch Changes
generatePath
when optional params are present (#9764)<Await>
to acceptReactNode
as children function return result (#9896)@remix-run/router@1.3.0
v6.6.2
Compare Source
Patch Changes
useId
consistency during SSR (#9805)v6.6.1
Compare Source
Patch Changes
@remix-run/router@1.2.1
v6.6.0
Compare Source
Patch Changes
useLoaderData
usage inerrorElement
(#9735)@remix-run/router@1.2.0
v6.5.0
Compare Source
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
Patch Changes
<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)@remix-run/router@1.1.0
v6.4.5
Compare Source
Patch Changes
@remix-run/router@1.0.5
v6.4.4
Compare Source
Patch Changes
@remix-run/router@1.0.4
remix-run/react-router (react-router-dom)
v6.23.1
Compare Source
Patch Changes
document
existence when checkingstartViewTransition
(#11544)react-router-dom/server
import back toreact-router-dom
instead ofindex.ts
(#11514)@remix-run/router@1.16.1
react-router@6.23.1
v6.23.0
Compare Source
Minor Changes
unstable_dataStrategy
configuration option (#11098)Patch Changes
@remix-run/router@1.16.0
react-router@6.23.0
v6.22.3
Compare Source
Patch Changes
@remix-run/router@1.15.3
react-router@6.22.3
v6.22.2
Compare Source
Patch Changes
@remix-run/router@1.15.2
react-router@6.22.2
v6.22.1
Compare Source
v6.22.0
Compare Source
Minor Changes
window__reactRouterVersion
tag for CWV Report detection (#11222)Patch Changes
@remix-run/router@1.15.0
react-router@6.22.0
v6.21.3
Compare Source
Patch Changes
NavLink
isPending
when abasename
is used (#11195)unstable_
prefix fromBlocker
/BlockerFunction
types (#11187)react-router@6.21.3
v6.21.2
Compare Source
v6.21.1
Compare Source
Patch Changes
react-router@6.21.1
@remix-run/router@1.14.1
v6.21.0
Compare Source
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:Any paths like
/dashboard
,/dashboard/team
,/dashboard/projects
will match theDashboard
route. The dashboard component itself can then render nested<Routes>
: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"."
: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:
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: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: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
@remix-run/router@1.14.0
react-router@6.21.0
v6.20.1
Compare Source
Patch Changes
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)react-router@6.20.1
@remix-run/router@1.13.1
v6.20.0
Compare Source
Minor Changes
PathParam
type from the public API (#10719)Patch Changes
react-router@6.20.0
@remix-run/router@1.13.0
v6.19.0
Compare Source
Minor Changes
unstable_flushSync
option touseNavigate
/useSumbit
/fetcher.load
/fetcher.submit
to opt-out ofReact.startTransition
and intoReactDOM.flushSync
for state updates (#11005)unstable_usePrompt
to accept aBlockerFunction
in addition to aboolean
(#10991)Patch Changes
key
in auseFetcher
that remains mounted wasn't getting picked up (#11009)useFormAction
which was incorrectly inheriting the?index
query param from child routeaction
submissions (#11025)NavLink
active
logic whento
location has a trailing slash (#10734)react-router@6.19.0
@remix-run/router@1.12.0
v6.18.0
Compare Source
Minor Changes
Add support for manual fetcher key specification via
useFetcher({ key: string })
so you can access the same fetcher instance from different components in your application without prop-drilling (RFC) (#10960)useFetchers
so that they can be looked up bykey
Add
navigate
/fetcherKey
params/props touseSumbit
/Form
to support kicking off a fetcher submission under the hood with an optionally user-specifiedkey
(#10960)useFetcher({ key })
to look it up elsewherePatch Changes
RouterProvider
that holds completed fetcher data, in preparation for the upcoming future flag that will change the fetcher persistence/cleanup behavior (#10961)future
prop onBrowserRouter
,HashRouter
andMemoryRouter
so that it accepts aPartial<FutureConfig>
instead of requiring all flags to be included. (#10962)@remix-run/router@1.11.0
react-router@6.18.0
v6.17.0
Compare Source
Minor Changes
Add experimental support for the View Transitions API via
document.startViewTransition
to enable CSS animated transitions on SPA navigations in your application. (#10916)The simplest approach to enabling a View Transition in your React Router app is via the new
<Link unstable_viewTransition>
prop. This will cause the navigation DOM update to be wrapped indocument.startViewTransition
which will enable transitions for the DOM update. Without any additional CSS styles, you'll get a basic cross-fade animation for your page.If you need to apply more fine-grained styles for your animations, you can leverage the
unstable_useViewTransitionState
hook which will tell you when a transition is in progress and you can use that to apply classes or styles:You can also use the
<NavLink unstable_viewTransition>
shorthand which will manage the hook usage for you and automatically add atransitioning
class to the<a>
during the transition:For an example usage of View Transitions with React Router, check out our fork of the Astro Records demo.
For more information on using the View Transitions API, please refer to the Smooth and simple transitions with the View Transitions API guide from the Google Chrome team.
Please note, that because the
ViewTransition
API is a DOM API, we now export a specificRouterProvider
fromreact-router-dom
with this functionality. If you are importingRouterProvider
fromreact-router
, then it will not support view transitions. (#10928Patch Changes
ScrollRestoration
whensessionStorage
is unavailable (#10848)@remix-run/router@1.10.0
react-router@6.17.0
v6.16.0
Compare Source
Minor Changes
@remix-run/router@1.9.0
react-router@6.16.0
Patch Changes
v6.15.0
Compare Source
Minor Changes
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
URLSearchParams
and theuseSearchParams
hook. (#10620)useFormAction()
for unspecified actions since it cannot be determined on the server and causes hydration issues (#10758)unstable_usePrompt
to avoid throwing an exception if the prompt is unblocked and a navigation is performed synchronously (#10687, #10718)@remix-run/router@1.8.0
react-router@6.15.0
v6.14.2
Compare Source
Patch Changes
<ScrollRestoration>
(#10682)Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR has been generated by Mend Renovate. View repository job log here.