Skip to content

v2.2.0

Choose a tag to compare

View all tags
@brophdawg11 brophdawg11 released this 31 Oct 16:00
· 3757 commits to main since this release
remix@2.2.0
85caf9b
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Verified
Learn about vigilant mode.

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 plugin
  • unstable_createViteServer: Creates a Vite server in middleware mode for interop with custom servers
  • unstable_loadViteServerBuild: Allows your custom server to delegate SSR requests to Vite during development

Changed APIs

  • createRequestHandler: Now also allows the build 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 by key
  • Form and useSumbit now support optional navigate/fetcherKey props/params to allow kicking off a fetcher submission under the hood with an optionally user-specified key
    • <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() or useFetcher({ 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 an idle 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 via useFetcher().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

Patch Changes

  • @remix-run/express: Allow the Express adapter to work behind a proxy when using app.enable('trust proxy') (#7323)
    • Previously, this used req.get('host') to construct the Remix Request, but that does not respect X-Forwarded-Host
    • This now uses req.hostname which will respect X-Forwarded-Host
  • @remix-run/react: Fix warning that could be inadvertently logged when using route files with no default export (#7745)
  • create-remix: Support local tarballs with a .tgz extension which allows direct support for pnpm pack tarballs (#7649)
  • create-remix: Default the Remix app version to the version of create-remix being used (#7670)
    • This most notably enables easier usage of tags, e.g. npm create remix@nightly

Updated Dependencies

Changes by Package

Full Changelog: 2.1.0...2.2.0

Assets 2
Loading