v2.2.0
brophdawg11
released this
31 Oct 16:00
·
1203 commits
to main
since this release
Minor Changes
Vite!
Remix 2.2.0
adds unstable support for Vite for Node-based apps! See our announcement blog post and the Future > Vite page in the Remix docs for more details. (#7590)
You can try it out today with two new (unstable) templates:
# minimal server
npx create-remix@latest --template remix-run/remix/templates/unstable-vite
# custom server (Express example)
npx create-remix@latest --template remix-run/remix/templates/unstable-vite-express
New APIs in @remix-run/dev
unstable_vitePlugin
: The new Remix Vite pluginunstable_createViteServer
: Creates a Vite server in middleware mode for interop with custom serversunstable_loadViteServerBuild
: Allows your custom server to delegate SSR requests to Vite during development
Changed APIs
createRequestHandler
: Now also allows thebuild
argument to be a function that will be used to dynamically load new builds for each request during development
Other Runtimes
- Deno support is untested, but should work through Deno's Node/
npm
interop - CloudFlare support is not yet available
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.v3_fetcherPersist
)
Per the same RFC as above, we've introduced a new future.v3_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
Patch Changes
@remix-run/express
: Allow the Express adapter to work behind a proxy when usingapp.enable('trust proxy')
(#7323)- Previously, this used
req.get('host')
to construct the RemixRequest
, but that does not respectX-Forwarded-Host
- This now uses
req.hostname
which will respectX-Forwarded-Host
- Previously, this used
@remix-run/react
: Fix warning that could be inadvertently logged when using route files with nodefault
export (#7745)create-remix
: Support local tarballs with a.tgz
extension which allows direct support forpnpm pack
tarballs (#7649)create-remix
: Default the Remix app version to the version ofcreate-remix
being used (#7670)- This most notably enables easier usage of tags, e.g.
npm create remix@nightly
- This most notably enables easier usage of tags, e.g.
Updated Dependencies
Changes by Package
create-remix
@remix-run/architect
@remix-run/cloudflare
@remix-run/cloudflare-pages
@remix-run/cloudflare-workers
@remix-run/css-bundle
@remix-run/deno
@remix-run/dev
@remix-run/eslint-config
@remix-run/express
@remix-run/node
@remix-run/react
@remix-run/serve
@remix-run/server-runtime
@remix-run/testing
Full Changelog: 2.1.0...2.2.0