Minor Changes
New Fetcher APIs
Per this RFC, we've introduced some new APIs that give you more granular control over your fetcher behaviors. (#10960)
- You may now specify your own fetcher identifier via
useFetcher({ key: string })
, which allows you to access the same fetcher instance from different components in your application without prop-drilling - Fetcher keys are now exposed on the fetchers returned from
useFetchers
so that they can be looked up bykey
Form
anduseSumbit
now support optionalnavigate
/fetcherKey
props/params to allow kicking off a fetcher submission under the hood with an optionally user-specifiedkey
<Form method="post" navigate={false} fetcherKey="my-key">
submit(data, { method: "post", navigate: false, fetcherKey: "my-key" })
- Invoking a fetcher in this way is ephemeral and stateless
- If you need to access the state of one of these fetchers, you will need to leverage
useFetchers()
oruseFetcher({ key })
to look it up elsewhere
Persistence Future Flag (future.v7_fetcherPersist
)
Per the same RFC as above, we've introduced a new future.v7_fetcherPersist
flag that allows you to opt-into the new fetcher persistence/cleanup behavior. Instead of being immediately cleaned up on unmount, fetchers will persist until they return to an idle
state. This makes pending/optimistic UI much easier in scenarios where the originating fetcher needs to unmount. (#10962)
- This is sort of a long-standing bug fix as the
useFetchers()
API was always supposed to only reflect in-flight fetcher information for pending/optimistic UI -- it was not intended to reflect fetcher data or hang onto fetchers after they returned to anidle
state - Keep an eye out for the following specific behavioral changes when opting into this flag and check your app for compatibility:
- Fetchers that complete while still mounted will no longer appear in
useFetchers()
after completion - they served no purpose in there since you can access the data viauseFetcher().data
- Fetchers that previously unmounted while in-flight will not be immediately aborted and will instead be cleaned up once they return to an
idle
state- They will remain exposed via
useFetchers
while in-flight so you can still access pending/optimistic data after unmount - If a fetcher is no longer mounted when it completes, then it's result will not be post processed - e.g., redirects will not be followed and errors will not bubble up in the UI
- However, if a fetcher was re-mounted elsewhere in the tree using the same
key
, then it's result will be processed, even if the originating fetcher was unmounted
- They will remain exposed via
- Fetchers that complete while still mounted will no longer appear in
Other Minor Changes
- Add support for optional path segments in
matchPath
(#10768)
Patch Changes
- Fix the
future
prop onBrowserRouter
,HashRouter
andMemoryRouter
so that it accepts aPartial<FutureConfig>
instead of requiring all flags to be included (#10962) - Fix
router.getFetcher
/router.deleteFetcher
type definitions which incorrectly specifiedkey
as an optional parameter (#10960)
Full Changelog: 6.17.0...6.18.0