Skip to content

Releases: remix-run/remix

v1.8.0

01 Dec 14:47
@chaance chaance
[email protected]
8679b2c
Compare
Choose a tag to compare
v1.8.0

What's Changed

Lots of goodies to dig in this week, so let's get right to it 💪

React-Routering Remix

We released React Router 6.4 a few weeks back. This update introduced many of Remix's data APIs and moved all of the core routing logic to a framework-agnostic @remix-run/router package. As a result, we needed to rebuild the Remix implementation to take advantage of these changes.

1.8.0 includes the first big step in that process, and Remix now performs all server-side data fetches and mutations through the new framework agnostic router. This is an implementation detail and doesn't change much for you today, but completing this work will open the door for Remix to support other frameworks in the future. 🤯

Our guy @brophdawg11 published React-Routering Remix to dive into the details, so we encourage you to check it out to get a better glimpse of things to come!

A more robust meta API

Each Remix route can export a meta function that will render <meta> elements in the head of the route's document. The existing meta API was designed to simplify some of the inconsistencies of various meta tag attributes, but in turn it made some meta tags more difficult—if not impossible—to use correctly.

We also automatically merged all meta tags in nested route trees. While this is desirable in many cases, it's not a decision we should make for you in the cases where a leaf route's meta should omit its parent's tags.

As a result, we are rolling out a new, lower-level API for meta. Now you will return an array of objects that map directly to the <meta> tag's attributes, exactly as we do for links. You also get access to the route matches with meta and data available so you can decide how you want to handle merging meta tags.

export function meta({ data, matches }) {
  // Want to snag some meta from a matched route? No problem!
  let rootModule = matches.find((match) => match.route.id === "root");

  // Only want to merge its og: tags? Easy breezy!
  let rootOgTags = rootModule.meta.filter((meta) =>
    meta.property?.startsWith("og:")
  );

  // Merge what you want, where you want. No more magic!
  return [
    ...rootOgTags,
    { title: "All Downhill from Here" },
    { property: "og:type", content: "music.song" },
    { property: "music:musician", content: "https://www.newfoundglory.com/" },
    { property: "music:duration", content: 192 },
    {
      property: "music:album",
      content: "https://open.spotify.com/album/1Igrcji3zf5aC61saylDE1",
    },
  ];
}

While this is a new API, the change is completely opt-in via the new future option in remix.config.js and it will become the default behavior in version 2.0. No breaking changes for you, but a clear and early upgrade path should you choose to take it! To opt in, add the following to your Remix config file:

module.exports = {
  future: {
    v2_meta: true,
  },
};

For more details on how we got here, check out the original RFC.

Making thrown Response objects less ambiguous

Previously there was some ambiguity around "thrown Responses go to the CatchBoundary". The CatchBoundary exists to give the user a place to handle non-happy path code flows such that they can throw Response instances from their own code and handle them in a CatchBoundary. However, there are a handful of framework-internal errors that make sense to have a non-500 status code, and the fact that these were being thrown as Response instances was causing them to go into the CatchBoundary, even though they were not thrown by the user.

With this change, anything thrown by the framework itself (Error or Response) will go to the ErrorBoundary, and any user-thrown Response instance will go to the CatchBoundary. There is one exception to this rule, which is that framework-detected 404 responses will continue to go to the CatchBoundary since users should have one single location to handle 404 displays.

The primary affected use cases are scenarios such as:

  • HTTP OPTIONS requests (405 Unsupported Method )
  • GET requests to routes without loaders (400 Bad Request)
  • POST requests to routes without actions (405 Method Not Allowed)
  • Missing route id in _data parameters (403 Forbidden)
  • Non-matching route id included in _data parameters (403 Forbidden)

For more information on this change, check out the PR in which it was introduced.

Other Changes

  • Add support for importing .wasm files (#3299)
  • Update @remix-run/web-fetch. This addresses two bugs: (#4644)
    • It fixes a memory leak caused by unregistered listeners
    • It adds support for custom "credentials" values (Remix does nothing with these at the moment, but they pass through for the consumer of the request to access if needed)
  • Ensure route modules are loaded even in failure cases
    • This addresses a long standing issue where you would end up in your root catch boundary if a form transition to another route threw. This no longer occurs, and you end up in the contextual boundary you'd expect. (#4611)

Changes by package

New Contributors

Full Changelog: v1.7.6...v1.8.0

Contributors

brophdawg11 and benwis
Loading

v1.7.6

17 Nov 19:34
@chaance chaance
[email protected]
c967d16
Compare
Choose a tag to compare
v1.7.6

What Changed

Patch Changes

  • Fixed a regression in the browser build for browsers that don't support the nullish coalescing operator (#4561)

Changes by package

New Contributors

Full Changelog: v1.7.5...v1.7.6

Contributors

wangbinyq, luisrivas, and 2 other contributors
Loading

v1.7.5

03 Nov 17:22
@chaance chaance
[email protected]
3233775
Compare
Choose a tag to compare
v1.7.5

What Changed

Patch Changes

  • Make sure namespaced Open Graph and fb:app_id meta data renders the correct attributes on <meta> tags (#4445)
  • Add the missing event parameter type to useBeforeUnload (#1723)

Changes by package

Full Changelog: v1.7.4...v1.7.5

Loading

v1.7.4

27 Oct 19:21
@chaance chaance
[email protected]
3dc7a19
Compare
Choose a tag to compare
v1.7.4

What Changed

Patch Changes

  • You can now infer the type of the .data property of fetchers from your action and loader functions. This works similarly to our type inference of useLoaderData by providing the type of the action or loader function at the useFetcher call site.

    export async function loader(args: LoaderArgs) {
  return json({
    user: {
      name: "Chance",
      twitter: "@chancethedev",
      age: 36,
    },
  });
}

function SomeComponent() {
  let fetcher = useFetcher<typeof loader>();
  if (fetcher.data) {
    let userName = fetcher.data.user.name; // string
    let userAge = fetcher.data.user.age; // number
  }
}

  • Fixed a bug in <Form> that prevented the correct method from being called with non-POST submissions

Changes by package

New Contributors

Full Changelog: v1.7.3...v1.7.4

Contributors

michaelhelvey and maxschwarzmueller
Loading

v1.7.3

20 Oct 17:23
@chaance chaance
[email protected]
55dad37
Compare
Choose a tag to compare
v1.7.3

What Changed

Patch Changes

  • <Form /> now respects the formMethod attribute set on the submitter element (#4053)

    <Form>
  <button type="submit">GET request</button>
  <button type="submit" formMethod="post">
    POST request
  </button>
</Form>

  • Assets referenced in CSS files are now hashed and copied to the assetsBuildDirectory (#4130).

    Before this change, a CSS declaration like background: url('./relative-path/image.png') that references the file ./relative-path/image.png will not copy that file to the build directory. This can be a problem if you use a custom build directory, or when dealing with third-party stylesheets in node_modules that reference their own relative files.

  • We updated the @remix-run/web-fetch dependency for @remix-run/node (#4277). This fixes issues with {Request | Response}.clone() throwing when body is null. This update also adds additional Node.js-specific types to fetch() to support the use of agent from http and https.

  • Added support for setting moduleResolution to node, node16 or nodenext in tsconfig.json (#4034)

  • Added resources imported only by resource routes to assetsBuildDirectory (#3841)

Changes by package

New Contributors

Full Changelog: v1.7.2...v1.7.3

Contributors

freeman, markdalgleish, and 7 other contributors
Loading

v1.7.2

21 Sep 21:25
@chaance chaance
[email protected]
0aa1f0e
Compare
Choose a tag to compare
v1.7.2

What's Changed

Bug Fixes

  • Preserve ?index for fetcher get submissions to index routes (#4238)
  • Fix dependency conflicts with type-fest (87642b71b)
  • Update ESLint and plugin dependencies (e4ec81c77)
  • Flush Node streams to address issues with libraries like compression that rely on chunk flushing (#4235)

Changes by package

Full Changelog: v1.7.1...v1.7.2

Loading

v1.7.1

16 Sep 16:10
@chaance chaance
[email protected]
88f6720
Compare
Choose a tag to compare
v1.7.1

What's Changed

Bug fixes 🐛

  • Ensured that requests are properly aborted on closing of a Response instead of Request in all Node adapters (#3626)
  • Locked the dependency on react-router-dom to version 6.3.0 instead of using a semver range (#4203), as installing [email protected] will cause compatibility issues
  • Fixed a bug with GET form submissions to ensure they replace the current search params, which tracks with the browser's behavior (#4046)

Changes by package

New Contributors

Full Changelog: v1.7.0...v1.7.1

Contributors

jrf0110, Deanmv, and 9 other contributors
Loading

v1.7.0

25 Aug 19:09
@chaance chaance
[email protected]
7bc01c1
Compare
Choose a tag to compare
v1.7.0

What's Changed

✨ Features

  • We removed our compiler's React shim in favor of esbuild's new automatic JSX transformation.

    There are no code changes required on your end, but by using the new transform we can prevent duplicate React imports from appearing in your build.

    The automatic JSX transform was introduced in React 17, and it allows you to write your JSX code without ever needing to import React. This means that compilers need to map JSX to React.createElement for you.

    Because esbuild previously didn't support this feature, we implemented a "shim" for the import to get the same affect. This unfortunately has caused problems with some external libraries, resulting in React being declared multiple times. (#2987)

    You still need to import modules from React that you use directly in your code (useState, useEffect, etc.). But if your component only needs the React import for JSX, you can safely omit it without worrying about duplicate imports.

  • The MetaFunction type can now infer data and parentsData types from route loaders.

    For example, if this meta function is exported from app/routes/sales/customers/$customerId:

    const meta: MetaFunction<
  typeof loader, // this will infer our type for `data`
  {
    root: RootLoader; // exported from the root route
    "routes/sales": SalesLoader; // exported from the sales route
    "routes/sales/customers": CustomersLoader; // exported from the sales/customers route
  }
> = ({ data, parentsData }) => {
  ///
};

    The meta function can be strongly typed by exposing each parent route's loader type:

    // app/root.tsx
const loader = () => {
  return json({ hello: "world" } as const);
};
export type Loader = typeof loader;

// app/routes/sales.tsx
const loader = () => {
  return json({ salesCount: 1074 });
};
export type Loader = typeof loader;

// app/routes/sales/customers.tsx
const loader = () => {
  return json({ customerCount: 74 });
};
export type Loader = typeof loader;

// app/routes/sales/customers/$customersId.tsx
import type { Loader as RootLoader } from "~/root";
import type { Loader as SalesLoader } from "~/routes/sales";
import type { Loader as CustomersLoader } from "~/routes/sales/customers";

const loader = () => {
  return json({ name: "Customer name" });
};

const meta: MetaFunction<
  typeof loader,
  {
    root: RootLoader;
    "routes/sales": SalesLoader;
    "routes/sales/customers": CustomersLoader;
  }
> = ({ data, parentsData }) => {
  const { name } = data;
  //      ^? string
  const { customerCount } = parentsData["routes/sales/customers"];
  //      ^? number
  const { salesCount } = parentsData["routes/sales"];
  //      ^? number
  const { hello } = parentsData["root"];
  //      ^? "world"
};

  • Each runtime package now exports a new type: SerializeFrom. This is used to infer the JSON-serialized return type of loaders and actions.

    type MyLoaderData = SerializeFrom<typeof loader>;
type MyActionData = SerializeFrom<typeof action>;

Changes by package

New Contributors

Full Changelog: v1.6.8...v1.7.0

Contributors

n8agrin, philandstuff, and 7 other contributors
Loading

v1.6.8

12 Aug 15:38
@chaance chaance
[email protected]
1a194e5
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.
Compare
Choose a tag to compare
v1.6.8

What's Changed

💅 Enhancements

  • You can now use .mjs or .cjs file extensions for remix.config (#3675)
  • We added support for importing .sql files as text content (#3190)
  • We made some optimizations in our compiler to make MDX builds deterministic (and a little faster!) (#3966)
  • Your load context is now type safe! The AppLoadContext type is now an an interface mapping string to unknown (#1876). This allows you to extend it via module augmentation: 
    declare module "@remix-run/server-runtime" {
  interface AppLoadContext {
    // add custom properties here!
  }
}
  • We added a subscribe method to the transition manager, which allows subscribing and unsubscribing for React 18 strict mode compliance (#3964)

🐛 Bug fixes

  • Previously, if an action was omitted from <Form> or useFormAction, the action value would default to ".". This is incorrect, as "." should resolve based on the current path, but an empty action resolves relative to the current URL (including the search and hash values). We've fixed this to differentiate between the two, meaning that the resolved action will preserve the full URL. (#3697)
  • Fixed a few types to work more seamlessly with changes in @types/react@18 (#3917)

Changes by package

New Contributors

Full Changelog: v1.6.7...v1.6.8

Contributors

DanielFGray, nrako, and julio-lemos
Loading

v1.6.7

30 Jul 16:31
@chaance chaance
[email protected]
5a6978f
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.
Compare
Choose a tag to compare
v1.6.7

What's Changed

  • Patched a syntax error in @remix-run/dev to ensure create-remix runs smoothly on Node 14

  • Fix inferred types for useLoaderData and useActionData to preserve null value types in @remix-run/react.

    Previously, null types were being replaced by never due to our usage of NonNullable in UndefinedOptionals. Properties that aren't unions with undefined are now kept as-is, while properties that do include undefined are still made optional, but only remove undefined from the property type whereas NonNullable also removed null types.

Changes by package

Full Changelog: v1.6.6...v1.6.7

Loading