🗺️ Storybook + Testing Helper

[ryanflorence]

We need a way to stub the context of Remix for both unit tests and storybook.

Problem

It's common for a reusable component to render a <Link> inside of it or access something like useLoaderData. Also useFetcher is so flexible it will likely make it into a lot of shared components as well.

All of these components need the Remix context which includes a lot of things, but the two biggest problems are:

1. The manifest
2. Requests going off to the server when links are clicked and forms are submitted

The manifest is generated at build time, and requests need a running server. Developers don't want either of those things for story book or component unit tests.

function LikeButton({ liked, label, action }) {
  let fetcher = useFetcher();
  let isLiked = fetcher.formData?.get("liked") ?? liked;
  return (
    <fetcher.Form method="post" action={action}>
      <button
        aria-label={label}
        name="liked"
        value={isLiked ? "true" : "false"}
        type="submit"
      >
        {isLiked ? "♥" : "♡"}
      </button>
    </fetcher.Form>
  );
}

That simple code relies on a lot of Remix internals. We need to a way to send it down a bunch of render paths for tests or storybook without the tests or the developer knowing a bunch of internals or having a server running.

Proposal

We need a way to easily stub out the context of a fake Remix app that doesn't require app developers (and their tests) to know the shape of Remix internals, or require a running server. It also needs to go through as many actual Remix code paths as possible. In React Router it's easy because you can just render a <MemoryRouter> around your component and be done. We need something like that for Remix. I think we can do it with a function like this:

let RemixStub = createRemixStub({ routes });

The only configuration I can think of right now is routes but I'm leaving the API open to needing more.

Storybook

The story could look something like this:

export default function () {
  // set up a fake "database" record, we're going to mutate this in our stubbed
  // action
  let fakePost = {
    title: "Fake Post",
    liked: false,
  };

  // This is the proposed API, create a function that makes a stub of Remix
  // without exposing any internals, but allows stories and tests to define a
  // "remix app" all right here in the story/test.
  let RemixStub = createStubRemix({
    // the "routes" API here is the object config API of React Router, so "no
    // new API" or internals to learn for testing. Also, the like button doesn't
    // care what route it's rendered in or where it's posting to, so it makes sense
    // the story here defines these things.
    routes: [
      {
        path: "/post/:postId",
        // Each like button is expected to be rendered in the context of a route
        // that's passing data from a loader to it.
        loader: () => fakePost,
        element: <StoryPost />,
      },
      {
        path: "/post/:postId/like",
        // The story *is not* re-implementing app logic. Every instance of
        // `LikeButton` will be rendered in the context of routes that need to
        // do these things, but they will do them differently (like talk to a
        // real database, different database table, etc.)
        action: async ({ request }) => {
          // fake latency to see the loading states
          await new Promise(res => setTimeout(res, 1000));
          let formData = await request.formData();
          fakePost.liked = JSON.parse(formData.get("liked"));
          return null;
        },
      },
    ],
  });

  // This is the actual "story" component. It accesses loader data and passes it
  // to the like button. This is how the LikeButton is expected to be used in
  // the context of Remix.  We want to useLoaderData so we can watch the button
  // move through the Remix transition/revalidation states. It shows very nicely
  // how it's expected to be used in the context of Remix.
  function StoryPost() {
    let post = useLoaderData();
    return (
      <LikeButton
        liked={post.liked}
        label={post.liked ? `Unlike ${post.title}` : `Like ${post.title}`}
        href={`/post/${post.id}/like`}
      />
    );
  }

  // Finally, you render the stub, providing initial history entries and initial
  // loader data
  return (
    <RemixStub
      initialEntries={["/post/123"]}
      initialLoaderData={{ "/post/:postId": fakePost }}
    />
  );
}

Of course, today you could refactor your like button to just take a bunch of non-remix props to render in different states. That's a bit cumbersome to do, requires more development effort to design components that way (not to mention the component above that access Remix hooks still can't be tested well), but most importantly for a UI designer--it won't let you "feel" the way the button moves through loading states. That, to me, is the big benefit of using story book in the first place.

Additionally, it's easy to imagine that for a "component library" team they might just make a single RemixStub for an entire "Storybook version of the app". None of the stories even need to create routes or anything. Very easily abstract-able to keep the stories clean and feeling very "component" oriented.

Tests

I don't think tests really need this API, it might just be more convenient. You can use jest/vitest mocks today to send your code down different rendering paths in unit tests:

import { render, waitFor, screen } from "@testing-library/react";
import { useTransition } from "remix";

// the unit we're testing
import { LikeButton } from "./like-button";

// mock remix react so we can send our like button down different rendering paths
vi.mock("@remix-run/react", async () => {
  let remix = await vi.importActual("@remix-run/react");
  return {
    ...remix,
    // get useFetcher to return an idle state initially
    useFetcher: vi.fn().mockReturnValue({ state: "idle" }),
  };
});

afterEach(() => {
  vi.clearAllMocks();
});

test("LikeButton initial render", async () => {
  // each test can send the button down different render paths, we're not
  // mocking internal behavior of useTransition, we're mocking what public API
  // it's returning to our component for this unit test
  useTransition.mockReturnValue({ state: "idle" });

  // render it
  render(<LikeButton liked={false} label="" href="" />);
  await waitFor(() => screen.getByRole("button"));

  // do our assertions
  expect(screen.getByRole("heading").innerHTML).toMatch("♡");
});

test("LikeButton optimistic render", async () => {
  // Set up the formData the component expects
  let formData = new FormData();
  formData.append("liked", "true");

  // Now mock the transition state remix would send, can use TypeScript to make
  // sure you don't mock an incorrect state (not shown here)
  useTransition.mockReturnValue({ state: "submitting", formData: formData });

  // render it, still `false` but we're expecting the optimistic UI to show that
  // it's liked given a fetcher state
  render(<LikeButton liked={false} label="" href="" />);
  await waitFor(() => screen.getByRole("button"));

  // do our assertions
  expect(screen.getByRole("button").innerHTML).toMatch("♥");
});

This works out great, and works today just fine. There are some risks though:

• If we spelled "liked" wrong in the <button name="likeed"> the tests would pass but the component is broken.
• If we spelled "liked" wrong in the test FormData, the component is working but the test is broken.
• We might mock the return value of useFetcher incorrectly. TypeScript helps here but it's still a risk and most tests w/ mocks have a lot of type casting that will potentially lie as well.

With createRemixStub you can have some unit tests on this button without those risks and without needing to do a full blown e2e test with your server and database:

describe("LikeButton", () => {
  // set up a fake "database" record again
  let fakePost = { title: "Fake Post", liked: false };

  // Make the stub
  let RemixStub = createStubRemix({
    routes: [
      {
        path: "/post/:postId",
        loader: () => fakePost,
        element: <TestSubject />,
      },
      {
        path: "/post/:postId/like",
        action: async ({ request }) => {
          // fake latency to see the loading states
          let formData = await request.formData();
          fakePost.liked = JSON.parse(formData.get("liked"));
          return null;
        },
      },
    ],
  });

  // Now we're testing the component how it's more likely to be used:
  function TestSubject() {
    let post = useLoaderData();
    return (
      <LikeButton
        liked={post.liked}
        label={post.liked ? `Unlike ${post.title}` : `Like ${post.title}`}
        href={`/post/${post.id}/like`}
      />
    );
  }

  afterEach(() => {
    // reset the fake record
    fakePost.liked = false;
  });

  it("renders an empty heart initially", () => {
    render(
      <RemixStub
        initialEntries={["/post/123"]}
        initialLoaderData={{ "/post/:postId": fakePost }}
      />,
    );
    await waitFor(() => screen.getByRole("button"));
    expect(screen.getByRole("button").innerHTML).toMatch("♥");
  });

  // In this test we no longer need to mock useFetcher return values, the test
  // also no longer has to know the implementation details of the spelling of
  // "liked" in the formData
  it("optimistically renders the heart", () => {
    render(
      <RemixStub
        initialEntries={["/post/123"]}
        initialLoaderData={{ "/post/:postId": fakePost }}
      />,
    );
    fireEvent.click(screen.getByRole("button"));
    await waitFor(() => screen.getByText("♥"));
    expect().toBeDefined();
    // assert it's optimistic, our action will not have changed this yet
    expect(post.liked).toBe(false);

    // wait for the action
    await waitFor(() => post.liked === true);

    // expect to still see the heart
    expect(screen.getByText("♥")).toBeDefined();
  });
});

The async portions of these tests could be implemented with deferreds, where actions and loaders could be manually triggered to resolve, but that doesn't change anything about this proposal, but is up to the preference of the developer writing the test.

it("optimistically renders the heart", () => {
  render(
    <RemixStub
      initialEntries={["/post/123"]}
      initialLoaderData={{ "/post/:postId": fakePost }}
    />,
  );
  fireEvent.click(screen.getByRole("button"));

  // check optimistic render, we haven't resolved the action or loader yet
  await waitFor(() => screen.getByText("♥"));
  expect(screen.getByText("♥")).toBeDefined();

  // manually resolve the action, this is just something the person writing the
  // test could set up on the routes in the test with a `deferred()`
  // implementation.
  await actionDeferred.resolve(true);
  // assert it's still a filled in heart after the action resolves
  expect(screen.getByText("♥")).toBeDefined();

  // finally resolve the loader with the new record
  await loaderDeferred.resolve({ title: "fake", liked: true });
  // assert it's still a filled in heart
  expect(screen.getByText("♥")).toBeDefined();
});

In some cases this might be better, though the test needs to know the order Remix is going to call action and then loaders on the routes, a bit of implementation detail there, but not too much I don't think.

Some tests might be better served with mocking, others with creating a remix stub.

Implementation Notes

Implementing createRemixStub might require some changes to Remix React to make the fetch implementation pluggable (so it doesn't actually try to fetch stuff from the server), or we could duck punch window.fetch to fake out responses to URLs we know are trying to access to the Remix server and letting everything else go through to the real window.fetch. I think I'd got with duck punching window.fetch.

It also does dynamic imports of route modules, so we probably need to plug in a different routeModulesCache. I think that's already pluggable (since server/client modules are resolved differently) so it should be as simple as making a route modules cache that's a no-op for testing.

Then we'd need to just make up some assets based on the routes for the asset manifest and stub out everything else on context.

Off the top of my head, that should be it. I don't think it'd be too difficult since the multiple server/client render targets of Remix already made a lot of these pieces pluggable. Testing is just another target.

[kentcdodds]

I have nothing to add to this. It's well thought through and I think it solves all cases of which I'm aware. I agree that duck punching window.fetch is the right way to go.

The trickiest bit of all of this will be helping people know when to use E2E and when to use createRemixStub. The line I can draw is this: Do not use createRemixStub with a route module. Primarily because of all the side-effects you'll get in the process (jest/vitest will have issues resolving all the server imports etc.). You'll likely end up trying to connect to a database accidentally. So yeah, don't use createRemixStub with route modules. Those should be tested via E2E.

I'm a big fan of this proposal 👍 Would love to hear what others have to say.

[clgeoio]

TIL:duck punching is a thing.

[brandonpittman]

https://consolia-comic.com/comics/ducks-1-duck-punching

[luistak]

This stub proposal is intended to simulate multiple routes and sub-routes to simulate integration tests along with navigations between pages? Or Remix should explicitly opinionate on e2e tests for this use case?

[ryanflorence]

You could do that, but then you're just testing your test routes (pointless) and Remix (Remix already has tests).

This is for testing components that compose around Remix APIs but you don't care about the application behavior, just the component behavior.

If you want to test your actual routes, that's e2e.

[gabimor]

A bit off topic but related, i'm curious about how you would distribute your effort between Storybook/Cypress Testing Library and E2E tests to ensure high quality UI.
I have used SB in the past and it was a joy but have not really done testing to components. Storybook 6.4 has a new "Interactions" feature so i'm thinking about where to put my effort

[chantastic]

earlier this month I gave a talk exploring that. it might be helpful:
https://www.youtube.com/watch?v=Hpx3kOtPovk&t=10s

for me, e2e is great for testing flows (indifferent to number of pages).

I like (browser-integrated) visual integration testing for the rest of my visual componentry.

[moishinetzer]

Any updates on this proposal, it would allow a Remix Stack with preconfigured Storybook's...

[kentcdodds]

I have it on my list, but other things keep coming up.

If anyone else wants to start the work that would be welcome 👍 Happy to review/iterate with someone who has time and motivation to prioritize it now.

[gabimor]

Second that, I keep finding creative ways to keep Remix out of my stories lol, I would love to see an official support!
Unfortunately I don't have the time to help with this. just wanted to +1

[gabimor]

@kentcdodds thinking about making time to helping with this, any time estimate to implement it?

[kentcdodds]

No idea

[chantastic]

Hiya, friends!

I had the privilege of a chatting with @ryanflorence @shilman and @yannbf today on how we might integrate Remix components and Storybook.

I've mentioned them here to keep me honest — as I'm not super familiar with all the working parts.

Goal

Remix and Storybook have very similar goals:

• Remix: Build Better Websites
• Storybook: Improve the UX of the Web

Storybook takes a component-driven approach to visual integration testing.
We want to test as much as we can — using real code and real browsers — without requiring the full stack of an application.

Cypress is great at testing e2e feature flows. But we want to get as much visual integration testing juice out of components as we can.

The discussion we had today was about connecting Remix components — in Storybook — in a way that excludes the server.

Prerequisites

Remix has a project in flight to migrate some functionality back to React Router.
This integration project is contingent on that work.

In order to properly mock requests, data.js#fetchData and component.tsx#RemixEntry implementations need to be injectable.

Ryan estimates that this work might be done around August/September.
We can start work on the integration once that Remix/React Router migration is completed.

Ergonomics

Ryan whipped up a quick demonstration using Storybook parameters to to demonstrate a dynamic way to set up the component.
While verbose — this is the general shape of what parameters usage might look like for a story.

Whatever.paramaters = {
  remix: (setup) => {
    // let scopedJunk = {}
    return setup({
      Routes: [{
        Actions: () => {
          scopedJunk.foo = “lol”
        }
      }]

    })
  }
}

Serialization

While dynamic parameters are allowable (in this way), the channel architecture between Storybook canvas and manager works best when all parameters are serializable.
This isn't a hard constraint but a theoretical/eventual limit.

TypeScript

There was talk of ways to reduce boilerplate while keeping code statically analyzable.
However, that would depend on un-scoped Storybook work.
So unlikely part of a v1 scope.

Decorators

An eventual integration addon will likely use Storybook Decorators to provide ergonomics around repeated code.

MemoryManager

There was also discussion about needing a MemoryManager that I didn't understand but it sounded important 😅

Packaging

This integration will exist as a Storybook Addon.

• Existing Storybooks could be extended with the add-on
• npx storybook init could detect remix as a framework (Storybook work pending) and apply the add-on during Storybook generation
• Remix Stacks could be extended to include default Storybook configuration

Ownership

Once pre-requisite work is complete, we'd love to find someone in the community to bring these projects together and own the integration.
With the right pieces in place, Storybook integration add-ons are typically very small and would be a great size project for someone in both Remix and Storybook communities.

Some comments from Ryan

Any component that uses any Remix APIs could be rendered as a component (as long as you mash the [Storybook] params)

We could simulate loading states my utilizing unresolved promises.

What you're showing me (Storybook Play functions and Interaction testing) is blowing my mind. I'm pumped and want to start using it!

Outside art

• RedwoodJS Storybook integration

Follow-ups

• @ryanflorence you'd mentioned commenting on this thread about how you're thoughts on mocking had changed as a result of our chat

[ryanflorence]

Came here to write these notes myself, thanks for doing it!

(There is no MemoryManager, we need the Remix equivalent of React Router's <MemoryRouter>, which will be very easy once we're done "remixing react router")

[KevinMind]

@chantastic Is there any update about development of the addon? I've followed the storybook and remix community and have been pretty excited about what you could do here. Following the discussion it looks like several POCs have shown setting this up is possible. Would just require implementing the addon and adding features to the storybook UX as needed.

I would love to work on this over winter break if it is still open.

[janhesters]

I really love this proposal and wanted to add that E2E tests - even with modern tools such as Cypress - are very flaky. With enough code and enough UI complexity, eventually, all functional tests suites approach 100% false positive failure rate and must be automatically retriggered to prevent false positives from interfering with development process.

The stability improvements through more unit tests that this proposal would bring would be tremendously helpful.

Also I don't like that the current example has shared state, for reasons that @kentcdodds has written about a lot. Maybe there is a way to create this API without mutating fakePost?

[andrei9669]

with cypress coming out with component testing, I wonder, how much more useful the storybook aspect is.

[yannbf]

It'd be nice to have both as options. One could use Cypress (or Playwright) if they want to focus on tests, and Storybook if they want development, testing, documentation, design integrations and the rest of its ecosystem.
One could also use both in certain occasions and get good value for component testing + e2e.

[janhesters]

Cypress component testing is using a real browser and since that browser probably will import the component and won't import Remix, those tests will break. I think Cypress component testing is NOT working with components that depend on Remix internals, but I'm not sure ✌️

[fwouts]

When it comes time to implementing this, please consider tools other than Storybook as well, such as Preview.js, Ladle and so on (disclaimer I'm the author of Preview.js).

Luckily the current proposal looks like it'd be general enough to work in this context as well. Looking forward to seeing it come about!

[fkrauthan]

Yeah to me the main use-case is to develop components and pages. Don't care about the testing aspect. But it would allow me to develop my react components with hot reloading (which remix does not offer).

[eric-burel]

Hey, just a thing that has not been mentioned about testing: helpers you design for Storybook will indeed work in other context or even other competing tools (Preview, Ladle as mentioned above).

However the best mix between SB and testing happens when you are able to load Stories within your unit test, thanks to @storybook/testing-react. My workflow is usually like this:

• visual development with SB
• use the play function if needing more interaction
• starts there to create the unit test => the advantage is that you write a test to secure a feature that you have tested manually, while writing a test for a feature you only coded but not really tested in different scenarios is 10x harder
• get free regression test with snapshots

It would be even better if Testing Playground (https://chrome.google.com/webstore/detail/testing-playground/hejbmebodbijjdhflfknehhcgaklhano) worked with Storybook, because you would be able to compute accessible selectors from Storybook. The iframe prevents that currently but maybe in the future.

So to sum it up, for testing, you might want to focus in importing your mocked story within Vitest and see if it works.

Other random insights:

• can mocking reuse MSW syntax, or even MSW? This is currently my goto solution to mock queries in any technologies because the mocking occurs exactly in the right place (a worker that intercepts requests or server-side), covering all use cases I've met so far. It's the best mock system for GraphQL?
• how do you plan to handle server-only code? I think there's a package that handle data fetching methods for Next but couldn't find it, not sure if the solution is elegant enough. But that's a real issue to have to cut pages everytime you want to test them just because of the data fetching methods, while the logic to remove this code actually exists in the framework

[valotas]

What about providing a context with all the utilities that can/should be mocked? I might be missing something but that is what I do as a workaround for the moment. I'll take the <Link/> as an example:

// fallback implementation of remix's <Link />
function Anchor({ to, children, ...rest }: LinkProps) {
  return (
    <a href={`#${to}`} {...rest}>
      {children}
    </a>
  );
}

const RemixContext = createContext<RemixContextValue>({
  Link: Anchor,
});

export function useRemix() {
  return useContext(RemixContext)
}

Now within my components I can do the following:

function ComponentWithLink() {
  const { Link } = useRemix()
  return <Link to="/hi">Hi</Link>
}

And by default a simple anchor will be used.

Now, since I need to make use of the remix's implementation, I create a provider:

export function RemixContextProvider({ children }: PropsWithChildren<{}>) {
  return (
    <RemixContext.Provider value={{ Link: remix.Link }}>
      {children}
    </RemixContext.Provider>
  );
}

that I use to wrap the <RemixServer /> and <RemixBrowser /> in my entry files. The last two components could also act as the context provider.

Yet, I do not know how good of a practice is to have a hook returning components, but it makes mocking way easier.

[eric-burel]

This pattern is often used by tools that requires personalization. This is what I've picked for Vulcan (running the State of JS survey) and this let's us support raw HTML, Bootstrap and Mui versions, see "react-ui-*" packages here: https://github.com/VulcanJS/vulcan-npm/tree/main/packages.

This is also used by Form Builder: https://formbuilder.dev

Problem with this pattern (from my experience with Vulcan): it makes the bundle size literally explode. You can't statically optimize imports, so your context will contains each and every component without any hope for tree-shaking.

To fix this, you need to manually load the relevant component when setting up the context, which technically works but is cumberstone and unnatural.

I would only recommend this pattern if you are certain that you will stick with 2-3 small components or if you favour personalization over performances.

[eric-burel]

To rephrase it, this is a type of dependency injection. This pattern can be useful (https://sergiodxa.com/articles/dependency-injection-in-remix-loaders-and-actions) but Node.js traditionally favours mocking (replacing the import by another) to achieve the same goal during testing. So imo it makes sense to replace "remix" package with a similar mock package.

[alexbu92]

Any updates on this? Good temporary workarounds? I've gotten very used to using storybook for component dev and would hate to sacrifice that with Remix.

[kentcdodds]

You can probably customize the webpack config to stub out Remix components.

No updates yet though. We're waiting for the official release of the new router which is coming soon.

[Maxim-Filimonov]

Nuxt.js is apparently facing a similar issue. It might be worth to have a peek at a potential solution that the team over there came up with. Not sure it would fit requirement of not running remix server but its a potential approach to solve isolation issue.

[barbinbrad]

Curious how the new (awesome) release of React Router affects this discussion?

[jrestall]

I really needed this for a design system library with basic Form and Input components with validation that would fail to render if not rendered in a Remix route. If you have similar basic needs then this temporary workaround might work for you also.

It uses a storybook decorator to wrap all stories in a RemixBrowser component that is initialized with a single splat route that matches all urls and renders the story.

⚠️ Uses internal Remix data structures so could break in the future with a new Remix release. ⚠️

// .storybook/preview.tsx
import { RemixStub } from "./RemixStub";

export const decorators = [
  (Story) => (
    <RemixStub>
      <Story />
    </RemixStub>
  ),
];

// RemixStub.tsx 
import { RemixBrowser } from "@remix-run/react";

export function RemixStub({ children }) {
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  const win = window as any;
  win.__remixManifest = {
    routes: {
      "routes/$": {
        id: "routes/$",
        path: "*",
      },
    },
  };
  win.__remixRouteModules = {
    "routes/$": {
      default: () => children,
    },
  };
  win.__remixContext = {
    appState: {},
    matches: [],
    routeData: {},
  };

  return <RemixBrowser />;
}

[frontsideair]

Might I suggest an improvement for Ladle, which was causing an infinite loop in useEffect?

// .ladle/components.tsx
import type { GlobalProvider } from "@ladle/react";
import { RemixStub } from "./RemixStub";

export const Provider: GlobalProvider = ({ children, globalState }) => {
  return (
    <RemixStub globalState={globalState}>
      {children}
    </RemixStub>
  );
};

import React from "react";
import { RemixBrowser } from "@remix-run/react";

export function RemixStub({ children, globalState }) {
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  const win = window as any;
  win.__remixManifest = {
    routes: {
      "routes/$": {
        id: "routes/$",
        path: "*",
      },
    },
  };
  win.__remixRouteModules = {
    "routes/$": {
      default: React.useCallback(() => children, [globalState.story]),
      // it doesn't update when switching to another story with an empty dependency array, hence the globalState plumbing
    },
  };
  win.__remixContext = {
    appState: {},
    matches: [],
    routeData: {},
  };

  return <RemixBrowser />;
}

[runmoore]

The internals of __remixContext have changed in v1.10. To get tests working I've updated it to the following:

win.__remixContext = {
  state: {},
};

⚠️ Again this comes with the caveats that it might break again in the future ⚠️

[tkovis]

I had issues in v1.8, upgraded to v1.13 and the above didn't fix issues. Updating to the following fixed issues:

win.__remixContext = {
    state: {},
    future: {},
  };

[comuneoOrg]

Starting at remix >2 the storybook flickers. i would love to have any idea how to solve it. ?

[frontsideair]

What is the official solution until this proposal lands? I've started creating stories with Ladle and the first component that uses Form/Link started throwing errors that can't be fixed trivially. I'm looking at ways to use Remix internals to create a context that provide the bare necessities but I'm not sure if it's even possible without ugly hacks or at all.

[frontsideair]

I just noticed this comment, which helped Ladle to render without any problems. Thanks!

[tpaulshippy]

Has anyone been able to get the RemixStub working with an <Outlet />? My components have useOutletContext and I'm unable to provide this in my stub. The only workaround I've found is to pass outlet context in as a prop, but this requires me to change my component code which I was hoping to avoid.

[jrestall]

I've just added support for useOutletContext to my createRemixStub implementation at https://github.com/jrestall/remix-stubs. There's an example here. Feel free to give it a go and let me know if any issues.

[jamesarosen]

Pro tip:

win.__remixContext = {
  routeData: {
    "routes/$": { locale: "en-US" },
  },
  // the rest…
}

will let you use test components that use useLocale() from remix-i18next.

[fergusmeiklejohn]

Sadly the RemixStub workaround is failing in 7.0alpha38 using vite-builder :-(

[1] 12:00:56 PM [vite] Internal server error: Failed to parse source for import analysis because the content contains invalid JS syntax. If you are using JSX, make sure to name the file with the .jsx or .tsx extension.
[1]   Plugin: vite:import-analysis
[1]   File: /Users/fergus/proj/test/.storybook/preview.js
[1]   17 |      <RemixStub>
[1]   18 |        <Story />
[1]   19 |      </RemixStub>
[1]      |                  ^
[1]   20 |    ),
[1]   21 |  ];

[jrestall]

Does renaming the preview.js file to preview.jsx help at all?

[jrestall]

I've created an example Storybook + Testing Helper implementation based on Ryan's createRemixStub design. There's also working examples for Storybook 7.0 w/ Vite and Vitest w/ jsdom.

https://github.com/jrestall/remix-stubs

Please raise issues and/or contribute fixes and improvements.

[jrestall]

@ryanflorence I modified the API slightly as prefer the simplicity of passing the routes as a param rather than in an object. I figured if more options are needed they could be added as a second parameter. Also this API is more consistent with the new 6.4 createBrowserRouter APIs.

export function createRemixStub(routes: RouteObject[], opts?: { ... })

[kwiat1990]

@jrestall I'm wondering if this setup can also work for context providers. In my case a test for a dumb component, which switches theme using provided API from context breaks due to missing context.

The provider is set in root.ts and both boundaries like this:

export default function Root() {
  const { theme } = useLoaderData<typeof loader>();

  return (
    <ThemeProvider specifiedTheme={theme}>
      <Document hasInitialTheme={!!theme}>
        <Outlet />
      </Document>
    </ThemeProvider>
  );
}

I get error Error: useTheme must be used within a ThemeProvider, which I throw myself in the useTheme hook if context is missing:

const ThemeContext = createContext<ThemeContextType | undefined>(undefined);

function useTheme() {
  const context = useContext(ThemeContext);

  if (!context) {
    throw new Error("useTheme must be used within a ThemeProvider");
  }

  return context;
}

EDIT: well, it does partially work when provider gets manually added directly inside the stub like this:

function TestSubject() {
    const theme = useLoaderData();
    return (
      <ThemeProvider specifiedTheme={theme}>
        <ThemeToggler />
      </ThemeProvider>
    );
  }

[jrestall]

Hi @kwiat1990, I've pushed an enhancement to the remix-stubs example that should enable you to set loader data for the root route. Then you can reuse the Root route in your test rather than copying the code.

describe("Theme Toggler", () => {
  // Make the stub
  let RemixStub = createRemixStub([
    {
      element: <Root />,
      children: [
        {
          path: "/toggler",
          element: <ThemeToggler />,
        },
      ],
    },
  ]);

  it("renders successfully", () => {
    render(
      <RemixStub
        initialEntries={["/toggler"]}
        initialLoaderData={{ "/": { theme: "MyTheme" } }}
      />
    );

    expect(...).toBeDefined();
  });
});

[huangc28]

@jrestall I encounter following error when using create-remix-stub

with following story:

let story: Meta<typeof TopProductsColumn> = {
  title: 'Top Products Column',
  component: TopProductsColumn,
  decorators: [
    (Story) => {
      const [args, updateArgs] = useArgs();
      const RemixStub = createRemixStub([
        {
          element: (
            <RemixMockSetup>
              <Story />
            </RemixMockSetup>
          ),
          path: 'product/1234',
          loader: () => { return null },
          action: async ({ request }) => {
            return { top_products: [], super_deal_products: [] };
          },
        }
      ]);

      return (<RemixStub initialEntries={["/post/1234"]} />);
    }
  ],
};

Where <RemixMockSetup> ... <RemixMockSetup> is from this comment. Am I missing something?

[jrestall]

Hi @huangc28, the issue is you are mixing two different mocking approaches. The createRemixStub approach replaces the need for RemixStub, so you should remove RemixMockSetup. Maybe this example from the remix-stubs repo will help.

[huangc28]

@jrestall Thank you for the reply. when I removed RemixMockSetup:

let story: Meta<typeof TopProductsColumn> = {
  title: 'Top Products Column',
  component: TopProductsColumn,
  decorators: [
    (Story) => {
      const [args, updateArgs] = useArgs();
      const RemixStub = createRemixStub([
        {
          element: (<Story />),
          path: 'product/1234',
          loader: () => { return null },
          action: async ({ request }) => {
            return { top_products: [], super_deal_products: [] };
          },
        }
      ]);

      return (<RemixStub initialEntries={["product/1234"]} />);
    }
  ],
};

export default story;

I got this error:

I think that's why I added RemixMockSetup back for the story to render within remix context.

[jrestall]

Hi @huangc28, your code looks good to me and matches the working example at remix-stubs. If you can share a repo with a minimal reproduction I can take a better look.

[huangc28]

@jrestall Really appreciate for your time addressing the issue. i recreated a minimalistic example for this issue with a brand new remix project and storybook in here.

The problematic files are located at:

• app/routes/TopProductColumn/index.tsx
• app/routes/TopProductColumn/TopProductColumn.stories.tsx

I was able to reproduce the error You must render this element inside a <Remix> element in this brand new repository. Please kindly take a look. Thank you

[huangc28]

I'm using storybook@^6 instead of 7 same as my current project. I'm not sure If that's a problem?

[fergusmeiklejohn]

Since this is in active development right now I just wanted to say how much I want to be able to develop components in Storybook and also how I use it. So I use storybook exclusively for building and testing UIs. That means I want any component at any level to potentially be openable to work on in Storybook and I also want the entire UX of that component to be disabled. In other words as cool and useful as mocking like createRemixStub is I don't as a user want to mock anything! I don't want a link to work, or a form to submit or a page to navigate or anything else like that. If I'm working on that side of things I'll do it in Remix. So in an ideal world from my POV I'd like the Storybook env to mock every single Remix function to be like () => null. That's the DX I want for Storybook.

Like this is an example of an error I get when trying to work on a component that uses Remix-Validated-Form:

invariant@http://localhost:6006/node_modules/.cache/.vite-storybook/deps/chunk-U2MEYXUE.js?v=c891f1a6:169:11
useRemixRouteContext@http://localhost:6006/node_modules/.cache/.vite-storybook/deps/chunk-U2MEYXUE.js?v=c891f1a6:1649:12
useActionData@http://localhost:6006/node_modules/.cache/.vite-storybook/deps/chunk-U2MEYXUE.js?v=c891f1a6:2333:7
useErrorResponseForForm@http://localhost:6006/node_modules/.cache/.vite-storybook/deps/chunk-YOKLCYJ4.js?v=c891f1a6:1387:22
ValidatedForm@http://localhost:6006/node_modules/.cache/.vite-storybook/deps/chunk-YOKLCYJ4.js?v=c891f1a6:1834:47
renderWithHooks@http://localhost:6006/node_modules/.cache/.vite-storybook/deps/chunk-HAKVT6QR.js?v=c891f1a6:11763:35
... etc

From which I guess that is expecting some Remix APIs to be available and when they are not it throws. That's cool I totally understand but my point is that I don't want to use <ValidatedForm /> within Storybook. I only want to work on the UI in Storybook, to focus on quickly iterating on the UI, pushing it to see where it breaks.

[thomasverleye]

Our component library has regular input components and we also export a wrapping component variant (eg: TextInput & ValidatedTextInput).
This has the benefit that we don't need Remix-Validated-Form for all of our routes + we can render the regular components in Storybook as well :-)

[thomasverleye]

Besides that, Remix-Validated-Form isn't part of the Remix sourcecode so this is something to discuss in that repository instead.

[fergusmeiklejohn]

thanks Thomas but I'm not looking for support for Remix-Validated-Form, I just use that as an example of how I believe the integration for Storybook shouldn't proceed. I believe it would be a mistake to create an integration that required users to write any config at all. I think that for two reasons:

1. the config will grow over time in size and complexity as edge cases are discovered and the API changes and it will be a constant source of trouble for users and especially maintainers.
2. Remix and ReactRouter are logically separate from pure UI development. The UI shouldn't care about Remix and Remix shouldn't care about the UI.

Testing is different of course, if people want to unit test components that use Remix API's then they'll need specific mocking but barebones Storybook shouldn't IMO.

[thomasverleye]

Alright, I didn't fully understand your initial comment, thanks for clarifying :-)

I agree, maintenance wise it potentially can be a footgun to have a mocking layer which you would need to update along with the Remix updates.

[fergusmeiklejohn]

Yeah it's interesting in a way that this thread exists. What do the UI and Remix care about each other?

[expressodaily]

https://github.com/jrestall/remix-stubs

[fergusmeiklejohn]

@jrestall has done a great job with remix-stubs. It would be best if we didn't have to stub anything though

[davidhousedev]

We've just started using this and it's super exciting to be able to render Remix routes within Storybook.

After digging into createRemixStub, I noticed that it isn't generic to the routes you're hoping to implement. I wonder if it might be possible to pass in the type of a loader or even an action, which would enforce that any stubbed loaders/actions return the same data to the component as their runtime counterparts.

I worry that without using generic typing to bridge the gap between the real routes and the stubbed routes, that the Storybook stories will get out of sync very quickly. These errors would only be caught at PR time, whereas the error could be caught by the type checker.

[yannbf]

@kasperpeulen you might be interested

[kasperpeulen]

@davidhousedev I am experimenting here with mocking the backend of the loader, instead of the loader itself in storybook:
https://github.com/kasperpeulen/storybook-remix

It is now using context to override the backend dependencies, but replacing "server" modules should also work, I'm going to experiment with that as well.

[daguitosama]

@kasperpeulen your setup works amazing for component driven development, is easy & just works !
thanks su much for sharing.

[tachibanayu24]

Is anyone still watching this discussions?
I need help in using Remix's Router in Storybook.

I have submitted a question but have not reached a resolution.
#6273

All I want to achieve is to display a UI component in Storybook that uses the Link component in @remix-run/react.

Thanks.

[tachibanayu24]

I upgraded the storybook version to the latest (7.0.12) and it solved the problem 🙏

[ghost23]

Hi @ryanflorence ,

I read your proposal and I have a perhaps stupid question regarding your Tests example (in your initial post).
Your are mocking useFetcher, yet later on you always set mockReturnValue(...) for useTransition. What am I missing here? I would have thought you would set mockReturnValue for useFetcher, no?

[aaronadamsCA]

I've managed to set up createRemixStub + Storybook + Mock Service Worker and it's working well. We can create multiple stories for each route using different mocked API responses, and it even works with useRouteLoaderData to allow child routes to continue to access data from parent loaders.

I have two big questions so far:

• How can I just get Remix to build me the routes object? I'd love to be able to call createRemixStub(routes) without having to manually recreate the entire structure of my app's routes.
• How can I prevent route changes? It looks like I might be able to directly implement React Router's useBlocker, but is there a better way?
  • Obviously I can't just use a splat route that redirects to the index, that breaks our entire approach here.

[squarism]

By createRemixStub do you mean you are using the createRemixStub API from 2.1.0?

[aaronadamsCA]

I'm still using the prefixed version from v2.0.1, but otherwise yes.

[r41ph]

@aaronadamsCA any chance you share an example of how you achieved this please?

[moishinetzer]

Here is a sample repo to show example setup: https://github.com/moishinetzer/epic-stack-with-storybook
Specific example within the repo: https://github.com/moishinetzer/epic-stack-with-storybook/blob/main/stories/GeneralErrorBoundary.stories.tsx