Remix Package

This package provides all the components, hooks, and Web Fetch API objects and helpers.

Components and Hooks

<Meta>, <Links>, <Scripts>

These components are to be used once inside of your root route (root.tsx). They include everything Remix figured out or built in order for your page to render properly.

  1. import React from "react";
  2. import { Meta, Links, Scripts, Outlet } from "remix";
  4. export default function App() {
  5.   return (
  6.     <html lang="en">
  7.       <head>
  8.         <meta charSet="utf-8" />
  9.         <Meta />
  10.         <Links />
  11.       </head>
  12.       <body>
  13.         <Outlet />
  14.         <Scripts />
  15.       </body>
  16.     </html>
  17.   );
  18. }

You can pass extra props to <Scripts/> like <Scripts crossOrigin> for hosting your static assets on a different server than your app, or <Script nonce={nonce}/> for certain content security policies.

<Link>

This component renders an anchor tag and is the primary way the user will navigate around your website. Anywhere you would have used <a href="..."> you should now use <Link to="..."/> to get all the performance benefits of client-side routing in Remix.

It wraps React Router’s Link with some extra behavior around resource prefetching.

  1. import { Link } from "remix";
  3. export default function GlobalNav() {
  4.   return (
  5.     <nav>
  6.       <Link to="/dashboard">Dashboard</Link>{" "}
  7.       <Link to="/account">Account</Link>{" "}
  8.       <Link to="/support">Dashboard</Link>
  9.     </nav>
  10.   );
  11. }

In our effort to remove all loading states from your UI, Link can automatically prefetch all the resources the next page needs: JavaScript modules, stylesheets, and data. This prop controls if and when that happens.

  1. <Link /> // defaults to "none"
  2. <Link prefetch="none" />
  3. <Link prefetch="intent" />
  4. <Link prefetch="render" />
  • “none” - Default behavior. This will prevent any prefetching from happening. This is recommended when linking to pages that require a user session that the browser won’t be able to prefetch anyway.
  • “intent” - Recommended if you want to prefetch. Fetches when when Remix thinks the user intends to visit the link. Right now the behavior is simple: if they hover or focus the link it will prefetch the resources. In the future we hope to make this event smarter. Links with large click areas/padding get a bit of a head start.
  • “render” - Fetches when the link is rendered.

You may need to use the :last-of-type selector instead of :last-child when styling child elements inside of your links

Remix uses the browser’s cache for prefetching with HTML <link rel="prefetch"/> tags, which provides a lot subtle benefits (like respecting HTTP cache headers, doing the work in browser idle time, using a different thread than your app, etc.) but the implementation might mess with your CSS since the link tags are rendered inside of your anchor tag. This means a *:last-child {} style selectors won’t work. You’ll need to change them to a *:last-of-type {} and you should be good. We will eventually get rid of this limitation.

<NavLink>

A <NavLink> is a special kind of <Link> that knows whether or not it is “active”. This is useful when building a navigation menu, such as a breadcrumb or a set of tabs where you’d like to show which of them is currently selected. It also provides useful context for assistive technology like screen readers.

<Form>

The <Form> component is a declarative way to perform data mutations: creating, updating, and deleting data. While it might be a mindshift to think about these tasks as “navigation”, it’s how the web has handled mutations since before JavaScript was created!

  1. import { Form } from "remix";
  3. function NewEvent() {
  4.   return (
  5.     <Form method="post" action="/events">
  6.       <input type="text" name="title" />
  7.       <input type="text" name="description" />
  8.     </Form>
  9.   );
  10. }
  • Whether JavaScript is on the page or not, your data interactions created with <Form> and action will work.
  • After a <Form> submission, all of the loaders on the page will be reloaded. This ensures that any updates to your data are reflected in the UI.
  • <Form> automatically serializes your form’s values (identically to the browser when not using JavaScript)
  • You can build “optimistic UI” and pending indicators with useTransition

<Form action>

Most of the time you can omit this prop. Forms without an action prop (<Form method="post">) will automatically post to the same route within which they are rendered. This makes colocating your component, your data reads, and your data writes a snap.

If you need to post to a different route, then add an action prop:

  1. <Form action="/projects/new" method="post" />

When a POST is made to a URL, multiple routes in your route hierarchy will match the URL. Unlike a GET to loaders, where all of them are called to build the UI, only one action is called. The route called will be the deepest matching route, unless the deepest matching route is an “index route”. In this case, it will post to the parent route of the index route (because they share the same URL).

If you want to post to an index route use ?index in the action: <Form action="/accounts?index" method="post" />

action urlroute action
/accounts?indexroutes/accounts/index.js
/accountsroutes/accounts.js

<Form method>

This determines the HTTP verb to be used: get, post, put, patch, delete. The default is “get”.

  1. <Form method="post" />

Native <form> only supports get and post, so if you want your form to work with JavaScript on or off the page you’ll need to stick with those two.

Without JavaScript, Remix will turn non-get requests into “post”, but you’ll still need to instruct your server with a hidden input like <input type="hidden" name="_method" value="delete" />. If you always include JavaScript, you don’t need to worry about this.

We generally recommend sticking with “get” and “post” because the other verbs are not supported by HTML

<Form encType>

Defaults to application/x-www-urlencoded, which is also the only supported value right now.

<Form replace>

  1. <Form replace />

Instructs the form to replace the current entry in the history stack, instead of pushing the new entry. If you expect a form to be submitted multiple times you may not want the user to have to click “back” for every submission to get to the previous page.

This has no effect without JavaScript on the page.

<Form reloadDocument>

If true, it will submit the form with the browser instead of JavaScript, even if JavaScript is on the page.

  1. <Form reloadDocument />

This is recommended over <form>

When the action prop is omitted, <Form> and <form> will sometimes call different actions depending on what the current URL is.

  • <form> uses the current URL as the default which can lead to surprising results: forms inside parent routes will post to the child action if you’re at the child’s URL and the parents action when you’re at the parent’s URL. This means as the user navigates, the form’s behavior changes.
  • <Form> will always post to the route’s action, independent of the URL. A form in a parent route will always post to the parent, even if you’re at the child’s URL.

See also:

<ScrollRestoration>

This component will emulate the browser’s scroll restoration on location changes. Hopefully you never notice this component at all!

It must be the last element on the page, right before the <Scripts/> tag:

  1. <html>
  2.   <body>
  3.     {/* ... */}
  4.     <ScrollRestoration />
  5.     <Scripts />
  6.   </body>
  7. </html>

In order to avoid (usually) the client-side routing “scroll flash” on refresh or clicking back into the app from a different domain, this component attempts to restore scroll before React hydration. If you render the script anywhere other than the bottom of the document the window will not be tall enough to restore to the correct position.

useLoaderData

This hook returns the JSON parsed data from your route loader function.

  1. import React from "react";
  2. import { useLoaderData } from "remix";
  4. export function loader() {
  5.   return fakeDb.invoices.findAll();
  6. }
  8. export default function Invoices() {
  9.   const invoices = useLoaderData();
  10.   // ...
  11. }

useActionData

This hook returns the JSON parsed data from your route action. It returns undefined if there hasn’t been a submission at the current location yet.

  1. import React from "react";
  2. import { useActionData } from "remix";
  4. export async function action({ request }) {
  5.   const body = await request.formData();
  6.   const name = body.get("visitorsName");
  7.   return { message: `Hello, ${name}` };
  8. }
  10. export default function Invoices() {
  11.   const data = useActionData();
  12.   return (
  13.     <Form method="post">
  14.       <p>
  15.         <label>
  16.           What is your name?
  17.           <input type="text" name="visitorsName" />
  18.         </label>
  19.       </p>
  20.       <p>{data ? data.message : "Waiting..."}</p>;
  21.     </Form>
  22.   );
  23. }

The most common use-case for this hook is form validation errors. If the form isn’t right, you can simply return the errors and let the user try again (instead of pushing all the errors into sessions and back out of the loader).

  1. import { redirect, json, Form, useActionData } from "remix";
  3. export async function action({ request }) {
  4.   const form = await request.formData();
  5.   const email = form.get("email");
  6.   const password = form.get("password");
  7.   const errors = {};
  9.   // validate the fields
  10.   if (typeof email !== "string" || !email.includes("@")) {
  11.     errors.email =
  12.       "That doesn't look like an email address";
  13.   }
  15.   if (typeof password !== "string" || password.length < 6) {
  16.     errors.password = "Password must be > 6 characters";
  17.   }
  19.   // return data if we have errors
  20.   if (Object.keys(errors).length) {
  21.     return json(errors, { status: 422 });
  22.   }
  24.   // otherwise create the user and redirect
  25.   await createUser(body);
  26.   return redirect("/dashboard");
  27. }
  29. export default function Signup() {
  30.   const errors = useActionData();
  32.   return (
  33.     <>
  34.       <h1>Signup</h1>
  35.       <Form method="post">
  36.         <p>
  37.           <input type="text" name="email" />
  38.           {errors?.email && <span>{errors.email}</span>}
  39.         </p>
  40.         <p>
  41.           <input type="text" name="password" />
  42.           {errors?.password && (
  43.             <span>{errors.password}</span>
  44.           )}
  45.         </p>
  46.         <p>
  47.           <button type="submit">Sign up</button>
  48.         </p>
  49.       </Form>
  50.     </>
  51.   );
  52. }

Notes about resubmissions

When using <Form> (instead of <form> or <Form reloadDocument>), Remix does not follow the browser’s behavior of resubmitting forms when the user clicks back, forward, or refreshes into the location.

Remix client-side navigation does not resubmit forms on pop events like browsers.

Form submissions are navigation events in browsers (and Remix), which means users can click the back button into a location that had a form submission and the browser will resubmit the form. You usually don’t ever want this to happen.

For example, consider this user flow:

  1. The user lands at /buy
  2. They submit a form to /checkout
  3. They click a link to /order/123

The history stack looks like this, where “*“ is the current entry:

  1. GET /buy > POST /checkout > *GET /order/123

Now consider the user clicks the back button 😨

  1. GET /buy - *POST /checkout < GET /order/123

The browser will repost the same information and likely charge their credit card again. You usually don’t want this.

The decades-old best practice is to redirect in the POST request. This way the location disappears from the browser’s history stack and the user can’t “back into it” anymore.

  1. GET /buy > POST /checkout, Redirect > GET /order/123

This results in a history stack that looks like this:

  1. GET /buy - *GET /order/123

Now the user can click back without resubmitting the form.

When you should worry about this

Usually your actions will either return validation issues or redirect, and then you’re data and your user’s are safe no matter how the form is submitted. But to go into further detail, if you’re using:

  • <form>
  • <Form reloadDocument>
  • You’re not rendering <Scripts/>
  • The user has JavaScript disabled

The browser will resubmit the form in these situations unless you redirect from the action. If these are cases you want to support, we recommend you follow the age-old best practice of redirecting from actions.

If you’re using <Form> and don’t care to support the cases above, you don’t need to redirect from your actions. However, if you don’t redirect from an action, make sure reposting the same information isn’t dangerous to your data or your visitors because you can’t control if they have JavaScript enabled or not.

In general, if the form validation fails, return data from the action and render it in the component, but once you actually change data (in your database, or otherwise) you should redirect.

See also:

useFormAction

Resolves the value of a <form action> attribute using React Router’s relative paths. This can be useful when computing the correct action for a <button formAction>, for example, when a <button> changes the action of its <form>.

  1. <button
  2.   formAction={useFormAction("destroy")}
  3.   formMethod="DELETE"
  4. >
  5.   Delete
  6. </button>

(Yes, HTML buttons can change the action of their form!)

useSubmit

Returns the function that may be used to submit a <form> (or some raw FormData) to the server using the same process that <Form> uses internally onSubmit. If you’re familiar with React Router’s useNavigate, you can think about this as the same thing but for <Form> instead of <Link>.

This is useful whenever you need to programmatically submit a form. For example, you may wish to save a user preferences form whenever any field changes.

  1. import { useSubmit, useTransition } from "remix";
  3. export async function loader() {
  4.   await getUserPreferences();
  5. }
  7. export async function action() {
  8.   await updatePreferences(await request.formData());
  9.   return redirect("/prefs");
  10. }
  12. function UserPreferences() {
  13.   const submit = useSubmit();
  14.   const transition = useTransition();
  16.   function handleChange(event) {
  17.     submit(event.currentTarget, { replace: true });
  18.   }
  20.   return (
  21.     <Form method="post" onChange={handleChange}>
  22.       <label>
  23.         <input type="checkbox" name="darkMode" value="on" />{" "}
  24.         Dark Mode
  25.       </label>
  26.       {transition.state === "submitting" && (
  27.         <p>Saving...</p>
  28.       )}
  29.     </Form>
  30.   );
  31. }

This can also be useful if you’d like to automatically sign someone out of your website after a period of inactivity. In this case we’ve defined inactivity as the user hasn’t navigated to any other pages after 5 minutes.

  1. import { useSubmit, useTransition } from "remix";
  2. import { useEffect } from "react";
  4. function AdminPage() {
  5.   useSessionTimeout();
  6.   return <div>{/* ... */}</div>;
  7. }
  9. function useSessionTimeout() {
  10.   const submit = useSubmit();
  11.   const transition = useTransition();
  13.   useEffect(() => {
  14.     const id = setTimeout(() => {
  15.       submit(null, { method: "post", action: "/logout" });
  16.     }, 5 * 60_000);
  17.     return () => clearTimeout(timer);
  18.   }, [transition]);
  19. }

useTransition

This hook tells you everything you need to know about a page transition to build pending navigation indicators and optimistic UI on data mutations. Things like:

  • Global loading spinners
  • Spinners on clicked links
  • Disabling forms while the mutation is happening
  • Adding spinners to submit buttons
  • Optimistically showing a new record while it’s being created on the server
  • Optimistically showing the new state of a record while it’s being updated
  1. import { useTransition } from "remix";
  3. function SomeComponent() {
  4.   const transition = useTransition();
  5.   transition.state;
  6.   transition.type;
  7.   transition.submission;
  8.   transition.location;
  9. }

transition.state

You can know the state of the transition with transition.state, it will be one of:

  • idle - There is no transition pending.
  • submitting - A form has been submitted, if GET, then the route loader is being called, if POST, PUT, PATCH, DELETE, then the route action is being called.
  • loading - The loaders for the next routes are being called to render the next page.

Normal navigations transition as follows:

  1. idle → loading → idle

GET form submissions transition as follows:

  1. idle → submitting → idle

Form submissions with POST, PUT, PATCH, or DELETE transition as follows:

  1. idle → submitting → loading → idle
  1. function SubmitButton() {
  2.   const transition = useTransition();
  4.   const text =
  5.     : transition.state === "submitting"
  6.     ? "Saving..."
  7.     : transition.state === "loading"
  8.     ? "Saved!"
  9.     : "Go"
  11.   return <button type="submit">{text}</button>;
  12. }

transition.type

Most pending UI only cares about transition.state, but the transition can tell you even more information on transition.type.

Remix calls your route loaders at various times, like on normal link clicks or after a form submission completes. If you’d like to build pending indication that is more granular than “loading” and “submitting”, use the transition.type.

Depending on the transition state, the types can be the following:

  • state === "idle"

    • idle - The type is always idle when there’s not a pending navigation.

  • state === "submitting"

    • actionSubmission - A form has been submitted with POST, PUT, PATCH, or DELETE, and the action is being called
    • loaderSubmission - A form has been submitted with GET and the loader is being called

  • state === "loading"

    • loaderSubmissionRedirect - A “loaderSubmission” was redirected by the loader and the next routes are being loaded
    • actionRedirect - An “actionSubmission” was redirected by the action and the next routes are being loaded
    • actionReload - The action from an “actionSubmission” returned data and the loaders on the page are being reloaded
    • fetchActionRedirect - An action fetcher redirected and the next routes are being loaded
    • redirect - A loader from a normal navigation (or redirect) redirected to a new location and the new routes are being loaded
    • load - A normal load from a normal navigation
  1. function SubmitButton() {
  2.   const transition = useTransition();
  4.   const loadTexts = {
  5.     actionRedirect: "Data saved, redirecting...",
  6.     actionReload: "Data saved, reloading fresh data..."
  7.   };
  9.   const text =
  10.     transition.state === "submitting"
  11.       ? "Saving..."
  12.       : transition.state === "loading"
  13.       ? loadTexts[transition.type] || "Loading..."
  14.       : "Go";
  16.   return <button type="submit"></button>;
  17. }

transition.submission

Any transition that started from a <Form> or useSubmit will have your form’s submission attached to it. This is primarily useful to build “Optimistic UI” with the submission.formData FormData object.

TODO: Example

transition.location

This tells you what the next location is going to be. Its most useful when matching against the next URL for custom links and hooks.

For example, this Link knows when it’s page is loading and it’s about to become active:

  1. import { useResolvedPath } from "react-router-dom";
  2. import { Link } from "remix";
  4. function PendingLink({ to, children }) {
  5.   const transition = useTransition();
  6.   const path = useResolvedPath(to);
  8.   const isPending =
  9.     transition.state === "loading" &&
  10.     transition.location.pathname === path.pathname;
  12.   return (
  13.     <Link
  14.       data-pending={isPending ? "true" : null}
  15.       to={to}
  16.       children={children}
  17.     />
  18.   );
  19. }

Note that this link will not appear “pending” if a form is being submitted to the URL the link points to because we only do this for “loading” states. The form will contain the pending UI for whie the state is “submitting”, once the action is complete, then the link will go pending.

useFetcher

This hook is for advanced cases that most features of your app don’t need. It does not work with server rendering, usually requires JavaScript in the browser, and requires you to deal with pending states.

It is common for Remix newcomers to see this hook and think it is the primary way to interact with the server for data loading and updates, but it is not! Remix was specifically designed to avoid this type of interaction with the server and has better ways of handling typical data loading and updating workflows, you probably want one of these:

This hook will call loaders and actions without navigating. It’s similar to useFetch() wrappers found in many React apps but with extra behavior specific to Remix (like capturing data updates automatically across the whole page).

  1. import { useFetcher } from "remix";
  3. function SomeComponent() {
  4.   const fetcher = useFetcher();
  6.   // trigger the fetch with these
  7.   <fetcher.Form {..formOptions} />;
  8.   fetcher.submit(data, options);
  9.   fetcher.load(href);
  11.   // build UI with these
  12.   fetcher.state;
  13.   fetcher.type;
  14.   fetcher.submission;
  15.   fetcher.data;
  16. }

In HTML/HTTP, data mutations and loads are modeled with navigation: <a href> and <form action> both cause a navigation in the browser. The remix equivalents are <Link> and <Form>.

In Remix, when the user submits a <Form> the action is called and then the loaders for the routes on the page are called again to get fresh data.

But sometimes you want to call an action to update data (and get the routes to reload) but you don’t want the URL to change. Many interactions with the server aren’t navigation events. This hook lets you plug your UI into your actions and loaders without navigating.

Notes about how it works:

  • Automatically handles cancellation of the fetch at the browser level
  • When submitting with POST, PUT, PATCH, DELETE, the action is called first
    • After the action completes, the loaders on the page are reloaded to capture any mutations that may have happened, automatically keeping your UI in sync with your server state
  • When multiple fetchers are inflight at once, it will
    • commit the freshest available data as they each land
    • ensure no stale loads overrite fresher data, no matter which order the responses return
  • Handles uncaught errors by rendering the nearest ErrorBoundary (just like a normal navigation from <Link> or <Form>)
  • Will redirect the app if your action/loader being called returns a redirect (just like a normal navigation from <Link> or <Form>)

fetcher.state

You can know the state of the fetcher with fetcher.state, it will be one of:

  • idle - nothing is being fetched
  • submitting - A form has been submitted. If the method is GET then the route loader is being called, if POST, PUT, PATCH, or DELETE then the route action is being called.
  • loading - The loaders for the routes are being reloaded after an action submission completed.

fetcher.type

This is the type of state the fetcher is in. It’s like fetcher.state but more granular. Depending on the fetcher’s state, the types can be the following:

  • state === "idle"

    • init - The fetcher isn’t doing anything currently and hasn’t done anything yet.
    • done - The fetcher isn’t doing anything currently, but it has completed a fetch and you can safely read the fetcher.data.

  • state === "submitting"

    • actionSubmission - A form has been submitted with POST, PUT, PATCH, or DELETE, and the action is being called.
    • loaderSubmission - A form has been submitted with GET and the loader is being called

  • state === "loading"

    • actionReload - The action from an “actionSubmission” returned data and the loaders on the page are being reloaded.
    • load - A route’s loader is being called without a submission (fetcher.load())

fetcher.submission

When using <fetcher.Form> or fetcher.submit(), the form submission is available to build optimistic UI.

It is not available when the fetcher state is “idle” or “loading”.

fetcher.data

When using <fetcher.Form> or fetcher.submit(), the action or loader’s response is stored here.

In the case of action submissions, the data is available even before the routes on the page are reloaded.

It is not available when the fetcher state is “submitting”. If you need it around when the same form is resubmit, you’ll need to persist it to your own React state.

fetcher.Form

Just like <Form> except it doesn’t cause a navigation. (You’ll get over the dot in JSX, don’t worry.)

  1. function SomeComp() {
  2.   const fetcher = useFetcher();
  3.   return (
  4.     <fetcher.Form method="post" action="/some/route">
  5.       <input type="text" />
  6.     </fetcher.Form>
  7.   );
  8. }

fetcher.submit()

Just like useSubmit except it doesn’t cause a navigation.

  1. const fetcher = useFetcher();
  2. fetcher.submit({ some: "values" }, { method: "post" });

fetcher.load()

Loads data from a route loader.

  1. const fetcher = useFetcher();
  2. fetcher.load("/some/route");
  3. fetcher.data; // the data from the loader

Examples

Newsletter Signup Form

Perhaps you have a persistent newsletter signup at the bottom of every page on your site. This is not a navigation event, so useFetcher is perfect for the job:

  1. // routes/newsletter/subscribe.js
  2. export async function action({ request }) {
  3.   const email = (await request.formData()).get("email");
  4.   try {
  5.     await subscribe(email);
  6.     return json({ ok: true });
  7.   } catch (error) {
  8.     return json({ error: error.message });
  9.   }
  10. }
  1. // NewsletterSignup.js
  2. function NewsletterSignup() {
  3.   const newsletter = useFetcher();
  4.   const ref = useRef();
  6.   useEffect(() => {
  7.     if (newsletter.type === "done" && newsletter.data.ok) {
  8.       ref.current.reset();
  9.     }
  10.   }, [newsletter]);
  12.   return (
  13.     <newsletter.Form
  14.       ref={ref}
  15.       method="post"
  16.       action="/newsletter/subscribe"
  17.     >
  18.       <p>
  19.         <input type="text" name="email" />{" "}
  20.         <button
  21.           type="submit"
  22.           disabled={newsletter.state === "submitting"}
  23.         >
  24.           Subscribe
  25.         </button>
  26.       </p>
  28.       {newsletter.type === "done" &&
  29.         (newsletter.data.ok ? (
  30.           <p>Thanks for subscribing!</p>
  31.         ) : newsletter.data.error ? (
  32.           <p data-error>{newsletter.data.error}</p>
  33.         ) : null)}
  34.     </newsletter.Form>
  35.   );
  36. }

You can still provide a no-JavaScript experience

Because useFetcher doesn’t cause a navigation, it won’t automatically work if there is no JavaScript on the page like a normal Remix <Form> will because the browser will still navigate to the form’s action.

If you want to support a no JavaScript experience, just export a component from the route with the action.

  1. // routes/newsletter/subscribe.js
  2. export function action({ request }) {
  3.   // just like before
  4. }
  6. export default function NewsletterSignupRoute() {
  7.   const data = useActionData();
  8.   return (
  9.     <Form method="post" action="/newsletter/subscribe">
  10.       <p>
  11.         <input type="text" name="email" />{" "}
  12.         <button type="submit">Subscribe</button>
  13.       </p>
  15.       {newsletter.data.ok ? (
  16.         <p>Thanks for subscribing!</p>
  17.       ) : newsletter.data.error ? (
  18.         <p data-error>{newsletter.data.error}</p>
  19.       ) : null}
  20.     </Form>
  21.   );
  22. }
  • When JS is on the page, the user will subscribe to the newsletter and the page won’t change, they’ll just get a solid, dynamic experience
  • When JS is not on the page, they’ll be transitioned to the signup page by the browser.

You could even refactor the component to take props from the hooks and reuse it:

  1. // NewsletterSignup.js
  2. import { Form, useFetcher } from "remix";
  4. // used in the footer
  5. export function NewsletterSignup() {
  6.   const newsletter = useFetcher();
  7.   return (
  8.     <NewsletterForm
  9.       Form={newsletter.Form}
  10.       data={newsletter.data}
  11.       state={newsletter.state}
  12.       type={newsletter.type}
  13.     />
  14.   );
  15. }
  17. // used here and in the route
  18. export function NewsletterForm({
  19.   Form,
  20.   data,
  21.   state,
  22.   type
  23. }) {
  24.   // refactor a bit in here, just read from props instead of useFetcher
  25. }

And now you could reuse the same form, but it gets data from a different hook for the no-js experience:

  1. // routes/newsletter/subscribe.js
  2. import { NewsletterForm } from "~/NewsletterSignup";
  3. import { Form } from "remix";
  5. export default function NewsletterSignupRoute() {
  6.   const data = useActionData();
  7.   return (
  8.     <NewsletterForm
  9.       Form={Form}
  10.       data={data}
  11.       state="idle"
  12.       type="done"
  13.     />
  14.   );
  15. }

Mark Article as Read

Imagine you want to mark an article has been read by the current user after they’ve been on the page for a while and scrolled to the bottom, you could make a hook that looks something like this:

  1. function useMarkAsRead({ articleId, userId }) {
  2.   const marker = useFetcher();
  4.   useSpentSomeTimeHereAndScrolledToTheBottom(() => {
  5.     marker.submit(
  6.       { userId },
  7.       {
  8.         method: "POST",
  9.         action: "/article/${articleID}/mark-as-read"
  10.       }
  11.     );
  12.   });
  13. }

User Avatar Details Popup

Anytime you show the user avatar, you could put a hover effect that fetches data from a loader and displays it in a popup.

  1. // routes/user/$id/details.js
  2. export function loader({ params }) {
  3.   return fakeDb.user.find({ where: { id: params.id } });
  4. }
  1. // UserAvatar.js
  2. function UserAvatar({ partialUser }) {
  3.   const userDetails = useFetcher();
  4.   const [showDetails, setShowDetails] = useState(false);
  6.   useEffect(() => {
  7.     if (showDetails && userDetails.type === "init") {
  8.       userDetails.load(`/users/${user.id}/details`);
  9.     }
  10.   }, [showDetails]);
  12.   return (
  13.     <div
  14.       onMouseEnter={() => setShowDetails(true)}
  15.       onMouseLeave={() => setShowDetails(false)}
  16.     >
  17.       <img src={partialUser.profileImageUrl} />
  18.       {showDetails &&
  19.         (userDetails.type === "done" ? (
  20.           <UserPopup user={userDetails.data} />
  21.         ) : (
  22.           <UserPopupLoading />
  23.         ))}
  24.     </div>
  25.   );
  26. }

Async Reach UI Combobox

If the user needs to select a city, you could have a loader that returns a list of cities based on a query and plug it into a Reach UI combobox:

  1. // routes/city-search.tsx
  2. export function loader({ request }) {
  3.   const url = new URL(request.url);
  4.   return searchCities(url.searchParams.get("city-query"));
  5. }
  1. function CitySearchCombobox() {
  2.   const cities = useFetcher();
  4.   return (
  5.     <cities.Form method="get" action="/city-search">
  6.       <Combobox aria-label="Cities">
  7.         <div>
  8.           <ComboboxInput
  9.             name="city-query"
  10.             onChange={event =>
  11.               cities.submit(event.target.form)
  12.             }
  13.           />
  14.           {cities.state === "submitting" && <Spinner />}
  15.         </div>
  17.         {cities.data && (
  18.           <ComboboxPopover className="shadow-popup">
  19.             {cities.data.error ? (
  20.               <p>Failed to load cities :(</p>
  21.             ) : cities.data.length ? (
  22.               <ComboboxList>
  23.                 {cities.data.map(city => (
  24.                   <ComboboxOption
  25.                     key={city.id}
  26.                     value={city.name}
  27.                   />
  28.                 ))}
  29.               </ComboboxList>
  30.             ) : (
  31.               <span>No results found</span>
  32.             )}
  33.           </ComboboxPopover>
  34.         )}
  35.       </Combobox>
  36.     </cities.Form>
  37.   );
  38. }

useFetchers

Returns an array of all inflight fetchers.

This is useful for components throughout the app that didn’t create the fetchers but want to use their submissions to participate in optimistic UI.

For example, imagine a UI where the sidebar lists projects and the main view displays a list of checkboxes for the current project. The sidebar could display the number of completed and total tasks for each project.

  1. ┌─────────────────┬────────────────────────────┐
  2. │                 │                            │
  3. │   Soccer  (8/9) │ [x] Do the dishes          │
  4. │                 │                            │
  5. │ > Home    (2/4) │ [x] Fold laundry           │
  6. │                 │                            │
  7. │                 │ [ ] Replace battery in the │
  8. │                 │     smoke alarm            │
  9. │                 │                            │
  10. │                 │ [ ] Change lights in kids  │
  11. │                 │     bathroom               │
  12. │                 │                            │
  13. └─────────────────┴────────────────────────────┘

When the user clicks a checkbox, the submission goes to the action to change the state of the task. Instead of creating a “loading state” we want to create an “optimistic UI” that will immediately update the checkbox to appear checked even though the server hasn’t processed it yet. In the checkbox component, we can use fetcher.submission:

  1. function Task({ task }) {
  2.   const toggle = useFetcher();
  3.   const checked = toggle.submission
  4.     ? // use the optimistic version
  5.       Boolean(toggle.submission.formData.get("complete"))
  6.     : // use the normal version
  7.       task.complete;
  9.   const { projectId, id } = task;
  10.   return (
  11.     <toggle.Form
  12.       method="put"
  13.       action={`/project/${projectId}/tasks/${id}`}
  14.     >
  15.       <label>
  16.         <input
  17.           type="checkbox"
  18.           checked={checked}
  19.           onChange={e => toggle.submit(e.target.form)}
  20.         />
  21.       </label>
  22.     </toggle.Form>
  23.   );
  24. }

This awesome for the checkbox, but the sidebar will say 2/4 while the checkboxes show 3/4 when the user clicks on of them!

  1. ┌─────────────────┬────────────────────────────┐
  2. │                 │                            │
  3. │   Soccer  (8/9) │ [x] Do the dishes          │
  4. │                 │                            │
  5. │ > Home    (2/4) │ [x] Fold laundry           │
  6. │                 │                            │
  7. │          CLICK!-->[x] Replace battery in the │
  8. │                 │     smoke alarm            │
  9. │                 │                            │
  10. │                 │ [ ] Change lights in kids  │
  11. │                 │     bathroom               │
  12. │                 │                            │
  13. └─────────────────┴────────────────────────────┘

Because Remix will automatically reload the routes, the sidebar will quickly update and be correct. But for a moment, it’s gonna feel a little funny.

This is where useFetchers comes in. Up in the sidebar we can get access too all of the inflight fetcher states from the checkboxes—even though it’s not the component that created them.

The strategy has three steps:

  1. Find the submissions for tasks in a specific project
  2. Use the fetcher.submission.formData to immediately update the count
  3. Use the normal task’s state if it’s not inflight

Here’s some sample code:

  1. function ProjectTaskCount({ project }) {
  2.   const fetchers = useFetchers();
  3.   const completedTasks = 0;
  5.   // 1) Find my task's submissions
  6.   const myFetchers = new Map();
  7.   for (const f of fetchers) {
  8.     if (
  9.       f.submission &&
  10.       f.submission.action.startsWith(
  11.         `/projects/${project.id}/task`
  12.       )
  13.     ) {
  14.       const taskId = f.submission.formData.get("id");
  15.       myFetchers.set(
  16.         parseInt(taskId),
  17.         f.submission.formData.get("complete") === "on"
  18.       );
  19.     }
  20.   }
  22.   for (const task of project.tasks) {
  23.     // 2) use the optimistic version
  24.     if (myFetchers.has(task.id)) {
  25.       if (myFetchers.get(task.id)) {
  26.         completedTasks++;
  27.       }
  28.     }
  29.     // 3) use the normal version
  30.     else if (task.complete) {
  31.       completedTasks++;
  32.     }
  33.   }
  35.   return (
  36.     <small>
  37.       {completedTasks}/{project.tasks.length}
  38.     </small>
  39.   );
  40. }

useMatches

Returns the current route matches on the page. This is useful for creating layout abstractions with your current routes.

  1. const matches = useMatches();

matches has the following shape:

  1. [
  2.   { pathname, data, params, handle }, // root route
  3.   { pathname, data, params, handle }, // layout route
  4.   { pathname, data, params, handle } // child route
  5.   // etc.
  6. ];

Remix knows all of your route matches and data at the top of the React element tree. That’s how we can:

  • add meta tags to the top of the document even though they are defined in nested routes lower in the tree
  • add <link> tags to assets at the top of the document even though …
  • add <script> bundles for each route at the top of the document …

Pairing route handle with useMatches, you can build your own, similar conventions to Remix’s built-in <Meta>, <Links>, and <Scripts> components.

Let’s consider building some breadcrumbs. If a route wants to participate in these breadcrumbs at the top of the root layout, it normally can’t because it renders down low in the tree.

You can put whatever you want on a route handle, here we’ll use breadcrumb, it’s not a Remix thing, it’s whatever you want. Here it’s added to a parent route:

  1. Add the breadcrumb handle to the parent route

    1. // routes/parent.tsx
    2. export const handle = {
    3.   breadcrumb: () => <Link to="/parent">Some Route</Link>
    4. };

  2. We can do the same for a child route

    1. // routes/parent/child.tsx
    2. export const handle = {
    3.   breadcrumb: () => (
    4.     <Link to="/parent/child">Child Route</Link>
    5.   )
    6. };

  3. Now we can put it all together in our root route with useMatches.

    1. // root.tsx
    2. import {
    3.   Links,
    4.   Scripts,
    5.   useLoaderData,
    6.   useMatches
    7. } from "remix";
    9. export default function Root() {
    10.   const matches = useMatches();
    12.   return (
    13.     <html lang="en">
    14.       <head>
    15.         <meta charSet="utf-8" />
    16.         <Links />
    17.       </head>
    18.       <body>
    19.         <header>
    20.           <ol>
    21.             {matches
    22.               // skip routes that don't have a breadcrumb
    23.               .filter(
    24.                 match =>
    25.                   match.handle && match.handle.breadcrumb
    26.               )
    27.               // render breadcrumbs!
    28.               .map((match, index) => (
    29.                 <li key={index}>
    30.                   {match.handle.breadcrumb(match)}
    31.                 </li>
    32.               ))}
    33.           </ol>
    34.         </header>
    36.         <Outlet />
    37.       </body>
    38.     </html>
    39.   );
    40. }

Notice that we’re passing the match to breadcrumbs. We didn’t use it, but we could have used match.data to use our route’s data in the breadcrumb.

Another common use case is enabling JavaScript for some routes and not others.

Once again, useMatches with handle is a great way for routes to participate in rendering abstractions at the top of element tree, above where the route is actually rendered.

useBeforeUnload

This hook is just a helper around window.onbeforeunload.

When users click links to pages they haven’t visited yet, Remix loads the code-split modules for that page. If you deploy in the middle of a user’s session, and you or your host removes the old files from the server (many do 😭) then Remix’s requests for those modules will fail. Remix recovers by automatically reloading the browser at the new URL. This should start over from the server with the latest version of your application. Most of the time this works out great and user doesn’t even know anything happened.

In this situation, you may need to save important application state on the page (to something like the browser’s local storage) because the automatic page reload will lose any state you had.

Remix or not, this is just good practice to do. The user can change the url, accidentally close the browser window, etc.

  1. import { useBeforeUnload } from "remix";
  3. function SomeForm() {
  4.   const [state, setState] = React.useState(null);
  6.   // save it off before the automatic page reload
  7.   useBeforeUnload(
  8.     React.useCallback(() => {
  9.       localStorage.stuff = state
  10.     }, [state])
  11.   );
  13.   // read it in when they return
  14.   React.useEffect(() => {
  15.     if (state === null && localStorage.stuff != null) {
  16.       setState(localStorage.stuff);
  17.     }
  18.   }, []);
  20.   return (
  21.     // ...
  22.   );
  23. }

HTTP Helpers

json

This is a shortcut for creating application/json responses. It assumes you are using utf-8 encoding.

  1. import type { LoaderFunction } from "remix";
  2. import { json } from "remix";
  4. export const loader: LoaderFunction = () => {
  5.   // So you can write this:
  6.   return json({ any: "thing" });
  8.   // Instead of this:
  9.   return new Response(JSON.stringify({ any: "thing" }), {
  10.     headers: {
  11.       "Content-Type": "application/json; charset=utf-8"
  12.     }
  13.   });
  14. };

You can also pass a status code and headers:

  1. export const loader: LoaderFunction = () => {
  2.   return json(
  3.     { not: "coffee" },
  4.     {
  5.       status: 418,
  6.       headers: {
  7.         "Cache-Control": "no-store"
  8.       }
  9.     }
  10.   );
  11. };

redirect

This is shortcut for sending 30x responses.

  1. import type { ActionFunction } from "remix";
  2. import { redirect } from "remix";
  4. export const action: ActionFunction = async () => {
  5.   const userSession = await getUserSessionOrWhatever();
  7.   if (!userSession) {
  8.     return redirect("/login");
  9.   }
  11.   return json({ ok: true });
  12. };

By default it sends 302, but you can change it to whichever redirect status code you’d like:

  1. redirect(path, 301);
  2. redirect(path, 303);

You can also send a ResponseInit to set headers, like committing a session.

  1. redirect(path, {
  2.   headers: {
  3.     "Set-Cookie": await commitSession(session)
  4.   }
  5. });
  7. redirect(path, {
  8.   status: 302,
  9.   headers: {
  10.     "Set-Cookie": await commitSession(session)
  11.   }
  12. });

Of course, you can do redirects without this helper if you’d rather build it up yourself:

  1. // this is a shortcut...
  2. return redirect("/else/where", 303);
  4. // ...for this
  5. return new Response("", {
  6.   status: 303,
  7.   headers: {
  8.     Location: "/else/where"
  9.   }
  10. });

Cookies

A cookie is a small piece of information that your server sends someone in a HTTP response that their browser will send back on subsequent requests. This technique is a fundamental building block of many interactive websites that adds state so you can build authentication (see sessions), shopping carts, user preferences, and many other features that require remembering who is “logged in”.

Remix’s Cookie interface provides a logical, reusable container for cookie metadata.

Using cookies

While you may create these cookies manually, it is more common to use a session storage.

In Remix, you will typically work with cookies in your loader and/or action functions (see mutations) since those are the places where you need to read and write data.

Let’s say you have a banner on your e-commerce site that prompts users to check out the items you currently have on sale. The banner spans the top of your homepage, and includes a button on the side that allows the user to dismiss the banner so they don’t see it for at least another week.

First, create a cookie:

  1. import { createCookie } from "remix";
  3. export const userPrefs = createCookie("user-prefs", {
  4.   maxAge: 604_800 // one week
  5. });

Then, you can import the cookie and use it in your loader and/or action. The loader in this case just checks the value of the user preference so you can use it in your component for deciding whether or not to render the banner. When the button is clicked, the <form> calls the action on the server and reloads the page without the banner.

Note: We recommend (for now) that you create all the cookies your app needs in app/cookies.js and import them into your route modules. This allows the Remix compiler to correctly prune these imports out of the browser build where they are not needed. We hope to eventually remove this caveat.

  1. import { useLoaderData, json, redirect } from "remix";
  2. import { userPrefs } from "~/cookies";
  4. export async function loader({ request }) {
  5.   const cookieHeader = request.headers.get("Cookie");
  6.   const cookie =
  7.     (await userPrefs.parse(cookieHeader)) || {};
  8.   return { showBanner: value.showBanner };
  9. }
  11. export async function action({ request }) {
  12.   const cookieHeader = request.headers.get("Cookie");
  13.   const cookie =
  14.     (await userPrefs.parse(cookieHeader)) || {};
  15.   const bodyParams = await request.formData();
  17.   if (bodyParams.get("banner") === "hidden") {
  18.     cookie.showBanner = false;
  19.   }
  21.   return redirect("/", {
  22.     headers: {
  23.       "Set-Cookie": await userPrefs.serialize(cookie)
  24.     }
  25.   });
  26. }
  28. export default function Home() {
  29.   const { showBanner } = useLoaderData();
  31.   return (
  32.     <div>
  33.       {showBanner && (
  34.         <div>
  35.           <Link to="/sale">Don't miss our sale!</Link>
  36.           <Form method="post">
  37.             <input
  38.               type="hidden"
  39.               name="bannerVisibility"
  40.               value="hidden"
  41.             />
  42.             <button type="submit">Hide</button>
  43.           </Form>
  44.         </div>
  45.       )}
  46.       <h1>Welcome!</h1>
  47.     </div>
  48.   );
  49. }

Cookies have several attributes that control when they expire, how they are accessed, and where they are sent. Any of these attributes may be specified either in createCookie(name, options), or during serialize() when the Set-Cookie header is generated.

  1. const cookie = createCookie("user-prefs", {
  2.   // These are defaults for this cookie.
  3.   domain: "remix.run",
  4.   path: "/",
  5.   sameSite: "lax",
  6.   httpOnly: true,
  7.   secure: true,
  8.   expires: new Date(Date.now() + 60),
  9.   maxAge: 60
  10. });
  12. // You can either use the defaults:
  13. cookie.serialize(userPrefs);
  15. // Or override individual ones as needed:
  16. cookie.serialize(userPrefs, { sameSite: "strict" });

Please read more info about these attributes to get a better understanding of what they do.

Signing cookies

It is possible to sign a cookie to automatically verify its contents when it is received. Since it’s relatively easy to spoof HTTP headers, this is a good idea for any information that you do not want someone to be able to fake, like authentication information (see sessions).

To sign a cookie, provide one or more secrets when you first create the cookie:

  1. const cookie = createCookie("user-prefs", {
  2.   secrets: ["s3cret1"]
  3. });

Cookies that have one or more secrets will be stored and verified in a way that ensures the cookie’s integrity.

Secrets may be rotated by adding new secrets to the front of the secrets array. Cookies that have been signed with old secrets will still be decoded successfully in cookie.parse(), and the newest secret (the first one in the array) will always be used to sign outgoing cookies created in cookie.serialize().

  1. // app/cookies.js
  2. const cookie = createCookie("user-prefs", {
  3.   secrets: ["n3wsecr3t", "olds3cret"]
  4. });
  6. // in your route module...
  7. export async function loader({ request }) {
  8.   const oldCookie = request.headers.get("Cookie");
  9.   // oldCookie may have been signed with "olds3cret", but still parses ok
  10.   const value = await cookie.parse(oldCookie);
  12.   new Response("...", {
  13.     headers: {
  14.       // Set-Cookie is signed with "n3wsecr3t"
  15.       "Set-Cookie": await cookie.serialize(value)
  16.     }
  17.   });
  18. }

createCookie

Creates a logical container for managing a browser cookie from there server.

  1. import { createCookie } from "remix";
  3. const cookie = createCookie("cookie-name", {
  4.   // all of these are optional defaults that can be overridden at runtime
  5.   domain: "remix.run",
  6.   expires: new Date(Date.now() + 60),
  7.   httpOnly: true,
  8.   maxAge: 60,
  9.   path: "/",
  10.   sameSite: "lax",
  11.   secrets: ["s3cret1"],
  12.   secure: true
  13. });

To learn more about each attribute, please see the MDN Set-Cookie docs.

isCookie

Returns true if an object is a Remix cookie container.

  1. import { isCookie } from "remix";
  2. const cookie = createCookie("user-prefs");
  3. console.log(isCookie(cookie));
  4. // true

A cookie container is returned from createCookie and has handful of properties and methods.

  1. const cookie = createCookie(name);
  2. cookie.name;
  3. cookie.parse();
  4. // etc.

cookie.name

The name of the cookie, used in Cookie and Set-Cookie HTTP headers.

cookie.parse()

Extracts and returns the value of this cookie in a given Cookie header.

  1. const value = await cookie.parse(
  2.   request.headers.get("Cookie")
  3. );

cookie.serialize()

Serializes a value and combines it with this cookie’s options to create a Set-Cookie header, suitable for use in an outgoing Response.

  1. new Response("...", {
  2.   headers: {
  3.     "Set-Cookie": await cookie.serialize({
  4.       showBanner: true
  5.     })
  6.   }
  7. });

cookie.isSigned

Will be true if the cookie uses any secrets, false otherwise.

  1. const cookie = createCookie("user-prefs");
  2. console.log(cookie.isSigned); // false
  4. cookie = createCookie("user-prefs", {
  5.   secrets: ["soopersekrit"]
  6. });
  7. console.log(cookie.isSigned); // true

cookie.expires

The Date on which this cookie expires. Note that if a cookie has both maxAge and expires, this value will the date at the current time plus the maxAge value since Max-Age takes precedence over Expires.

  1. const cookie = createCookie("user-prefs", {
  2.   expires: new Date("2021-01-01")
  3. });
  5. console.log(cookie.expires); // "2020-01-01T00:00:00.000Z"

Sessions

Sessions are an important part of websites that allow the server to identify requests coming from the same person, especially when it comes to server-side form validation or when JavaScript is not on the page. Sessions are a fundamental building block of many sites that let users “log in”, including social, e-commerce, business, and educational websites.

In Remix, sessions are managed on a per-route basis (rather than something like express middleware) in your loader and action methods using a “session storage” object (that implements the SessionStorage interface). Session storage understands how to parse and generate cookies, and how to store session data in a database or filesystem.

Remix comes with several pre-built session storage options for common scenarios and one to create your own:

  • createCookieSessionStorage
  • createMemorySessionStorage
  • createFileSessionStorage (node)
  • createCloudflareKVSessionStorage (cloudflare-workers)
  • custom storage with createSessionStorage

Using Sessions

This is an example of a cookie session storage:

  1. // app/sessions.js
  2. import { createCookieSessionStorage } from "remix";
  4. const { getSession, commitSession, destroySession } =
  5.   createCookieSessionStorage({
  6.     // a Cookie from `createCookie` or the CookieOptions to create one
  7.     cookie: {
  8.       name: "__session",
  10.       // all of these are optional
  11.       domain: "remix.run",
  12.       expires: new Date(Date.now() + 60),
  13.       httpOnly: true,
  14.       maxAge: 60,
  15.       path: "/",
  16.       sameSite: "lax",
  17.       secrets: ["s3cret1"],
  18.       secure: true
  19.     }
  20.   });
  22. export { getSession, commitSession, destroySession };

We recommend setting up your session storage object in app/sessions.js so all routes that need to access session data can import from the same spot (also, see our Route Module Constraints).

The input/output to a session storage object are HTTP cookies. getSession() retrieves the current session from the incoming request’s Cookie header, and commitSession()/destroySession() provide the Set-Cookie header for the outgoing response.

You’ll use methods to get access to sessions in your loader and action functions.

A login form might look something like this:

  1. import { json, redirect } from "remix";
  2. import { getSession, commitSession } from "../sessions";
  4. export async function loader({ request }) {
  5.   const session = await getSession(
  6.     request.headers.get("Cookie")
  7.   );
  9.   if (session.has("userId")) {
  10.     // Redirect to the home page if they are already signed in.
  11.     return redirect("/");
  12.   }
  14.   const data = { error: session.get("error") };
  16.   return json(data, {
  17.     headers: {
  18.       "Set-Cookie": await commitSession(session)
  19.     }
  20.   });
  21. }
  23. export async function action({ request }) {
  24.   const session = await getSession(
  25.     request.headers.get("Cookie")
  26.   );
  27.   const form = await request.formData();
  28.   const username = form.get("username");
  29.   const password = form.get("password");
  31.   const userId = await validateCredentials(
  32.     username,
  33.     password
  34.   );
  36.   if (userId == null) {
  37.     session.flash("error", "Invalid username/password");
  39.     // Redirect back to the login page with errors.
  40.     return redirect("/login", {
  41.       headers: {
  42.         "Set-Cookie": await commitSession(session)
  43.       }
  44.     });
  45.   }
  47.   session.set("userId", userId);
  49.   // Login succeeded, send them to the home page.
  50.   return redirect("/", {
  51.     headers: {
  52.       "Set-Cookie": await commitSession(session)
  53.     }
  54.   });
  55. }
  57. export default function Login() {
  58.   const { currentUser, error } = useLoaderData();
  60.   return (
  61.     <div>
  62.       {error && <div className="error">{error}</div>}
  63.       <form method="POST">
  64.         <div>
  65.           <p>Please sign in</p>
  66.         </div>
  67.         <label>
  68.           Username: <input type="text" name="username" />
  69.         </label>
  70.         <label>
  71.           Password:{" "}
  72.           <input type="password" name="password" />
  73.         </label>
  74.       </form>
  75.     </div>
  76.   );
  77. }

And then a logout form might look something like this:

  1. import { getSession, destroySession } from "../sessions";
  3. export const action: ActionFunction = async ({
  4.   request
  5. }) => {
  6.   const session = await getSession(
  7.     request.headers.get("Cookie")
  8.   );
  9.   return redirect("/login", {
  10.     headers: { "Set-Cookie": await destroySession(session) }
  11.   });
  12. };
  14. export default function LogoutRoute() {
  15.   return (
  16.     <>
  17.       <p>Are you sure you want to log out?</p>
  18.       <Form method="post">
  19.         <button>Logout</button>
  20.       </Form>
  21.       <Link to="/">Nevermind</Link>
  22.     </>
  23.   );
  24. }

It’s important that you logout (or perform any mutation for that matter) in an action and not a loader. Otherwise you open your users to Cross-Site Request Forgery attacks. Also, Remix only re-calls loaders when actions are called.

Session Gotchas

Because of nested routes, multiple loaders can be called to construct a single page. When using session.flash() or session.unset(), you need to be sure no other loaders in the request are going to want to read that, otherwise you’ll get race conditions. Typically if you’re using flash, you’ll want to have a single loader read it, if another loader wants a flash message, use a different key for that loader.

createSession

TODO:

isSession

TODO:

createSessionStorage

Remix makes it easy to store sessions in your own database if needed. The createSessionStorage() API requires a cookie (or options for creating a cookie, see cookies) and a set of create, read, update, and delete (CRUD) methods for managing the session data. The cookie is used to persist the session ID.

The following example shows how you could do this using a generic database client:

  1. import { createSessionStorage } from "remix";
  3. function createDatabaseSessionStorage({
  4.   cookie,
  5.   host,
  6.   port
  7. }) {
  8.   // Configure your database client...
  9.   const db = createDatabaseClient(host, port);
  11.   return createSessionStorage({
  12.     cookie,
  13.     async createData(data, expires) {
  14.       // `expires` is a Date after which the data should be considered
  15.       // invalid. You could use it to invalidate the data somehow or
  16.       // automatically purge this record from your database.
  17.       const id = await db.insert(data);
  18.       return id;
  19.     },
  20.     async readData(id) {
  21.       return (await db.select(id)) || null;
  22.     },
  23.     async updateData(id, data, expires) {
  24.       await db.update(id, data);
  25.     },
  26.     async deleteData(id) {
  27.       await db.delete(id);
  28.     }
  29.   });
  30. }

And then you can use it like this:

  1. const { getSession, commitSession, destroySession } =
  2.   createDatabaseSessionStorage({
  3.     host: "localhost",
  4.     port: 1234,
  5.     cookie: {
  6.       name: "__session",
  7.       sameSite: "lax"
  8.     }
  9.   });

The expires argument to readData and updateData is the same Date at which the cookie itself expires and is no longer valid. You can use this information to automatically purge the session record from your database to save on space, or to ensure that you do not otherwise return any data for old, expired cookies.

createCookieSessionStorage

For purely cookie-based sessions (where the session data itself is stored in the session cookie with the browser, see cookies) you can use createCookieSessionStorage().

The main advantage of cookie session storage is that you don’t need any additional backend services or databases to use it. It can also be beneficial in some load balanced scenarios. However, cookie-based sessions may not exceed the browser’s max allowed cookie length (typically 4kb).

The downside is that you have to commitSession in almost every loader and action. If your loader or action changes the session at all, it must be committed. That means if you session.flash in an action, and then session.get in another, you must commit it for that flashed message to go away. With other session storage strageties you only have to commit it when it’s created (the browser cookie doesn’t need to change because it doesn’t store the session data, just the key to find it elsewhere).

  1. import { createCookieSessionStorage } from "remix";
  3. const { getSession, commitSession, destroySession } =
  4.   createCookieSessionStorage({
  5.     // a Cookie from `createCookie` or the same CookieOptions to create one
  6.     cookie: {
  7.       name: "__session",
  8.       secrets: ["r3m1xr0ck5"],
  9.       sameSite: "lax"
  10.     }
  11.   });

createMemorySessionStorage

This storage keeps all the cookie information in your server’s memory.

This should only be used in development. Use one of the other methods in production.

  1. // app/sessions.js
  2. import {
  3.   createCookie,
  4.   createFileSessionStorage
  5. } from "remix";
  7. // In this example the Cookie is created separately.
  8. const sessionCookie = createCookie("__session", {
  9.   secrets: ["r3m1xr0ck5"],
  10.   sameSite: true
  11. });
  13. const { getSession, commitSession, destroySession } =
  14.   createFileSessionStorage({
  15.     // The root directory where you want to store the files.
  16.     // Make sure it's writable!
  17.     dir: "/app/sessions",
  18.     cookie: sessionCookie
  19.   });
  21. export { getSession, commitSession, destroySession };

createFileSessionStorage (node)

For file-backed sessions, use createFileSessionStorage(). File session storage requires a file system, but this should be readily available on most cloud providers that run express, maybe with some extra configuration.

The advantage of file-backed sessions is that only the session ID is stored in the cookie while the rest of the data is stored in a regular file on disk, ideal for sessions with more than 4kb of data.

If you are deploying to a serverless function, ensure you have access to a persistent file system. They usually don’t have one without extra configuration.

  1. // app/sessions.js
  2. import {
  3.   createCookie,
  4.   createFileSessionStorage
  5. } from "remix";
  7. // In this example the Cookie is created separately.
  8. const sessionCookie = createCookie("__session", {
  9.   secrets: ["r3m1xr0ck5"],
  10.   sameSite: true
  11. });
  13. const { getSession, commitSession, destroySession } =
  14.   createFileSessionStorage({
  15.     // The root directory where you want to store the files.
  16.     // Make sure it's writable!
  17.     dir: "/app/sessions",
  18.     cookie: sessionCookie
  19.   });
  21. export { getSession, commitSession, destroySession };

createCloudflareKVSessionStorage (cloudflare-workers)

For Cloudflare KV backed sessions, use createCloudflareKVSessionStorage().

The advantage of KV backed sessions is that only the session ID is stored in the cookie while the rest of the data is stored in a globaly replicated, low-latency data store with exceptionally high read volumes with low-latency.

  1. // app/sessions.js
  2. import {
  3.   createCookie,
  4.   createCloudflareKVSessionStorage
  5. } from "remix";
  7. // In this example the Cookie is created separately.
  8. const sessionCookie = createCookie("__session", {
  9.   secrets: ["r3m1xr0ck5"],
  10.   sameSite: true
  11. });
  13. const { getSession, commitSession, destroySession } =
  14.   createCloudflareKVSessionStorage({
  15.     // The KV Namespace where you want to store sessions
  16.     kv: YOUR_NAMESPACE,
  17.     cookie: sessionCookie
  18.   });
  20. export { getSession, commitSession, destroySession };

Session API

After retrieving a session with getSession, the session object returned has a handful of methods and properties:

  1. export async function action({ request }) {
  2.   const session = await getSession(
  3.     request.headers.get("Cookie")
  4.   );
  5.   session.get("foo");
  6.   session.has("bar");
  7.   // etc.
  8. }

session.has(key)

Returns true if the session has a variable with the given name.

  1. session.has("userId");

session.set(key, value)

Sets a session value for use in subsequent requests:

  1. session.set("userId", "1234");

session.flash(key, value)

Sets a session value that will be unset the first time it is read. After that, it’s gone. Most useful for “flash messages” and server-side form validation messages:

  1. import { getSession, commitSession } from "../sessions";
  3. export async function action({ request, params }) {
  4.   const session = await getSession(
  5.     request.headers.get("Cookie")
  6.   );
  7.   const deletedProject = await archiveProject(
  8.     params.projectId
  9.   );
  11.   session.flash(
  12.     "globalMessage",
  13.     `Project ${deletedProject.name} successfully archived`
  14.   );
  16.   return redirect("/dashboard", {
  17.     headers: {
  18.       "Set-Cookie": await commitSession(session)
  19.     }
  20.   });
  21. }

Now we can read the message in a loader.

You must commit the session whenever you read a flash. This is different than you might be used to where some type of middleware automatically sets the cookie header for you.

  1. import React from "react";
  2. import { Meta, Links, Scripts, Outlet, json } from "remix";
  4. import { getSession, commitSession } from "./sessions";
  6. export async function loader({ request }) {
  7.   const session = await getSession(
  8.     request.headers.get("Cookie")
  9.   );
  10.   const message = session.get("globalMessage") || null;
  12.   return json(
  13.     { message },
  14.     {
  15.       headers: {
  16.         // only necessary with cookieSesionStorage
  17.         "Set-Cookie": await commitSession(session)
  18.       }
  19.     }
  20.   );
  21. }
  23. export default function App() {
  24.   const { message } = useLoaderData();
  26.   return (
  27.     <html>
  28.       <head>
  29.         <Meta />
  30.         <Links />
  31.       </head>
  32.       <body>
  33.         {message && <div className="flash">{message}</div>}
  34.         <Outlet />
  35.         <Scripts />
  36.       </body>
  37.     </html>
  38.   );
  39. }

session.get()

Accesses a session value from a previous request:

  1. session.get("name");

session.unset()

Removes a value from the session.

  1. session.unset("name");

When using cookieSessionStorage, you must commit the session whenever you unset

  1. return json(data, {
  2.   headers: {
  3.     "Set-Cookie": await commitSession(session)
  4.   }
  5. });

Types

  1. import type {
  2.   ActionFunction,
  3.   LoaderFunction,
  4.   MetaFunction,
  5.   LinksFunction,
  6.   ShouldReloadFunction
  7. } from "remix";