DEV Community: Mike Schutte

Leveraging the `key` prop to re-render Storybook stories

Mike Schutte — Thu, 19 May 2022 16:07:29 +0000

I've written a fair amount about combining Storybook (SB), react-query (RQ), and Mock Service Worker (MSW) (see related posts below). I finally solved another piece of the puzzle for a better developer experience: forcing RQ queries to refetch after changing a control in SB that influences a response from MSW.

A lot of times, the stories I write only leverage controls/args to influence the result of a mock response handled by MSW. Because of this, changing controls within the story does not update the UI because no props have changed. In order to demonstrate different states, I'll write separate stories with different args configurations.

E.g.,

export type Args = ChecklistsSummaryProps & {
  isLoading: boolean;
  isEmpty: boolean;
  bigNumbers: boolean;
  avgCompletionMinutes: number;
};

// ...

const Template: SB.StoryObj<Args> = {
  render: _args => <ChecklistsSummary />,
};

export const Default: typeof Template = {
  ...Template,
};

export const Loading: typeof Template = {
  ...Template,
  args: { isLoading: true },
};

export const Empty: typeof Template = {
  ...Template,
  args: { isEmpty: true },
};

export const BigNumbers: typeof Template = {
  ...Template,
  args: { bigNumbers: true },
};

It's a bit tedious, but ends up being very declarative and descriptive in tandem with composeStories from SB's testing-react addon.

But for cases where you want to have that nice and snappy feedback of SB controls that we know and love, you can leverage the key property on the component to force the component to refresh and run all its queries again.

const Template: SB.StoryObj<Args> = {
  render: args => <ChecklistsSummary key={JSON.stringify(args)} />,
};

Demo!

Integration stories: elevating Storybook with Mock Service Worker

Mike Schutte ・ Apr 28 '21

#mockserviceworker #storybook #react #javascript

Accessing unique queryClients in Storybook-based Jest tests

Mike Schutte ・ Dec 13 '21

#react #storybook #testing #javascript

Accessing unique queryClients in Storybook-based Jest tests

Mike Schutte ・ Dec 13 '21

#react #storybook #testing #javascript

Accessing unique queryClients in Storybook-based Jest tests

Mike Schutte — Mon, 13 Dec 2021 14:22:28 +0000

tl;dr

I recently came up with a pattern for accessing unique React Query clients on a per-render basis in Storybook stories and tests (using Jest and React Testing Library). This enables the following kind of API:

// composeStories from `@storybook/testing-react`
const Story = composeStories(stories)
const { queryClient } = renderStory(<Story.FancyButton />)
// ...wait for query client state, assert state, etc

(If this sounds like a fun stack to you, we're hiring at Process Street!)

Keep reading for more of the story, or just jump into the code in this template:

I prefer to give each test its own QueryClientProvider and create a new QueryClient for each test. That way, tests are completely isolated from each other. A different approach might be to clear the cache after each test, but I like to keep shared state between tests as minimal as possible. Otherwise, you might get unexpected and flaky results if you run your tests in parallel.

- TkDodo on Testing React Query

...But what if I need access to the query client in my tests!?

At Process Street we use the lovely @storybook/testing-react package to use Storybook stories as our components under test. This is a great pattern because you can effectively automate the manual QA you do in the Storybook browser.

Let's say you just added a toast alert for an API exception case. You finish your code changes and switch to your browser to test the toast in the story. It works! Now you can keep your user hat on and use Testing Library fundamentals to write a Jest spec matching what you did in the browser.

An example (pseudo code):

import * as React from 'react'
// local util module to wrap test utils like React Testing 
// Library (RTL) and @storybook/testing-react
import * as Test from 'test'
import * as stories from './index.stories'

const Story = Test.composeStories(stories)

test("FancyButton shows an alert for failures", () => {
  Test.renderStory(<Story.Failure />)
  Test.user.click(Test.screen.getByText(/do stuff/i))
  await Test.findByText(/uh oh!/i)
})

Yep. That's it. For the past few months our *.spec.tsx files have been very concise and declarative. This is because all the setup is in *.stories.tsx files. Tests just become expressions of how I'm testing the stories, as a user, in the browser.

Along with testing "integrated" components powered by React Query, we've been using a global queryClient instance to leverage patterns like:

await Test.waitFor(() => {
  expect(queryClient.isFetching()).toEq(0)
})

We can't follow TkDodo's advice very easily because if each story sets up it's own query client, how do we get access to it? We could instantiate a new query client for each test, but that's the kind of boilerplate that makes testing feel terrible. My goal is always to make testing feel as good as possible (maybe even fun?!).

The code I wish I had has the following characteristics:

All stories and tests have a unique queryClient instance.
The unique queryClient instance is easily accessible in each test.
The pattern for accessing the queryClient feels like "The Testing Library Way".

By #3, I refer to how Testing Library has normalized our eyes to the pattern of rendering something and destructuring results from that render call.

const { rerender } = Test.render(<FancyButton />)

It would feel awfully nice to be able to do something like:

const { queryClient } = Test.render(<FancyButton />)

Right? It's quite clear that the queryClient is unique to this particular invocation of Test.render.

So the big question is, how do we implement this?

I know right away that I won't instantiate the queryClient nor the QueryClientProvider at the individual story level for the same reasons I wouldn't instantiate it in each test: too much annoying boilerplate that makes writing stories less fun. So that's out. We need some kind of "do this for every test" lever.

It's recommended to have a custom render function that wraps the component under test the same way your app is globally wrapped by some combination of providers. We'll borrow this notion of "all the providers" but skip the custom render wrapper and instead use it for a Storybook decorator. Since we'll want control of our queryClient, we'll parameterize it for a root provider.

// ./test/index.tsx
import React from "react";
import { render, RenderOptions } from "@testing-library/react";
import { QueryClient, QueryClientProvider } from "react-query";
import { ChakraProvider } from "@chakra-ui/react";

export const makeQueryClient = () =>
  new QueryClient({
    defaultOptions: { queries: { retry: false } }
  });

type Props = { queryClient?: QueryClient };

export const AllTheProviders: React.FC<Props> = ({
  queryClient = makeQueryClient(),
  children
}) => {
  return (
    <QueryClientProvider client={queryClient}>
      <ChakraProvider>{children}</ChakraProvider>
    </QueryClientProvider>
  );
};

Now we'll jump straight to decorating all stories with AllTheProviders.

// .storybook/main-decorator.tsx
import * as React from "react";
import { AllTheProviders } from "../test";

export const MainDecorator: DecoratorFn = (
  Story,
  options
) => {
  return (
    <AllTheProviders queryClient={options.args.queryClient}>
      <Story {...options} />
    </AllTheProviders>
  );
};

Note that options.args.queryClient is still nullable, but allows us to pass a query client to the component results of composeStories.

Now we just export that decorator for Storybook's browser configuration in preview.js.

// .storybook/preview.js
import { MainDecorator } from './main-decorator'
//...
export const decorators = [AllTheProviders]

Now we have "decorated" stories for testing with composeStories from @storybook/testing-react, but we need a custom render function that adds queryClient to the return value of render from React Testing Library.

export const renderStory = (
  ui: React.ReactElement<{ queryClient?: QueryClient }>,
  options: RenderOptions = {}
) => {
  const queryClient: QueryClient =
    ui.props.queryClient ?? makeQueryClient();
  const clonedUi = React.cloneElement(ui, { queryClient });
  return { ...render(clonedUi, options), queryClient };
};

Boom! We use React.cloneElement to modify the already-invoked component function so we can pass a queryClient from a different scope. If the ui component was already called with a queryClient, that will be reused thanks to our nullish coalescing operator ??. Now in our tests we can access the queryClient as a result of our render call.

const { queryClient } = Test.renderStory(<Story.FancyButton />)

If you do need to test implementation details (which, face it, sometimes you Just Do), you can do something like this:

const queryClient = makeQueryClient()
const invalidateQueriesSpy = 
  jest.spyOn(queryClient, 'invalidateQueries');

Test.render(<Story.Success queryClient={queryClient} />)
Test.user.click(Test.screen.getByText(/do stuff/i))
expect(queryClient.invalidateQueries)
  .toHaveBeenCalledWith("user-profile")

That's where the ui.props.queryClient check comes into play.

And that's it! Check out the sandbox for more implementation details. Happy testing!

Controlling global decorators via Storybook `args` and `parameters`

Mike Schutte — Thu, 27 May 2021 14:15:17 +0000

Storybook decorators (in React) provide a powerful way to reuse component environments across multiple stories. However, there aren't any off-the-shelf levers to manipulate global decorators from individual stories.

At work (we're hiring!) I recently cleaned up our many context providers into one Base decorator. Here is a simplified example.

// .storybook/decorators/base.tsx
export const Base: DecoratorFn = (Story, options) => {
  return (
    <TestReactRoot {...options.args}>
      <Story {...options} />
    </TestReactRoot>
  );
};

// .storybook/preview.js
import { Base } from './decorators/base';

export const decorators = [Base];

TestReactRoot encapsulates a few providers, including the classic react-redux provider. So now we can easily write stories that have useSelector and other Redux hooks with minimal boilerplate. But how do I, say, set the initial Redux state from a story, when there is no visible reference to the global Base decorator? Specifically, I want to use Storybook controls to dynamically set the Redux state.

I couldn't find any existing strategies for this in the Storybook community, so I ended up using inversion of control: individual stories supply a function to the args config, which the global decorator invokes.

// ./storybook/decorators/base.tsx
export const Base: DecoratorFn = (Story, options) => {
  const { args, parameters } = options;

  if (parameters.modifyArgs) {
    Object.assign(args, parameters.modifyArgs(args));
  }

  return (
    <TestReactRoot {...args}>
      <Story {...options} />
    </TestReactRoot>
  );
};

// src/components/user-avatar.stories.tsx
export default {
  title: "User Avatar",
  args: {
    admin: false,
  },
  parameters: {
    modifyArgs: (args) => {
      return {
        reduxState: generateReduxState({ admin: args.admin })
      }
    }
  }
}

Boom! The story config just knows it can pass a pure function to modifyArgs, and the Base decorator decides what do do with the return value.

So there you have it: if you want to influence global decorator/provider state via Storybook controls:

Use a good ol' pure callback function in the args config that takes the args as a value and returns a partial of the args object.
Check for that callback function in the global decorator
If the callback is there, invoke it and assign the result to the args object (or whatever part needs mutation).
Pass around your updated data accordingly.

Enjoy!

Integration stories: elevating Storybook with Mock Service Worker

Mike Schutte — Wed, 28 Apr 2021 17:51:42 +0000

During our last product cycle at Process Street, our development experience was heavily aided by combining Mock Service Worker (MSW) and Storybook. It's a powerful union of tools worth knowing about.

Building a rich text editor

At Process Street, we're adding rich text documents ("Pages") to our app to help people document their processes faster without having to learn right away about our more structured workflow models.

We chose Slate.js to be the engine of our text editing features, topped off with UI composed by Chakra components.

You don't need a re-write to improve developer experience

Process Street is one of many teams who has done its darnedest to keep up with the rapidly evolving JavaScript landscape whilst iterating rapidly on product. The product started as an AngularJS (1.5.6) application and has gradually adopted more and more React components using react2angular.

The surface area of our product is already huge, and the frankenstein-state of our UI architecture adds some...friction...to the development experience in certain ways. Instead of loading up the entire application and depending on a locally running API server, we do all of our new UI work in React starting with Storybook.

Getting integrated

In my 3+ years of using Storybook to build user interfaces, most of the story-able components end up being leaves or very close to leaves in the DOM tree: the ones that are basically taking props and rendering JSX. This is a great pattern for rendering myriad states as named stories, but it's always been a challenge to move up the tree and achieve what is essentially an integration test, but in the form of an interactive story.

Modern React features and patterns make the demand for integration stories even greater. With the rising popularity and leverage of React's hook and context APIs along with adopting more colocated network fetching patterns (e.g., react-query and Apollo Client) in place of a global store like Redux, it's becoming more common and instinctual to build opaque components (meaning you don't pass them props) that fetch their own data via hooks and context providers.

The same patterns and tools that have allowed us to write more powerful, loosely coupled, and extensible components have left us in somewhat of a pickle when trying to express these components as stories without going through a kind of surgery to separate prop-driven UI components from wrapping components that take care of sourcing those props.

Enter Mock Service Worker.

Mock by intercepting requests on the network level. Seamlessly reuse the same mock definition for testing, development, and debugging.

By combining MSW with Storybook, you can express components anywhere in the DOM tree as interactive stories. Here's how I got an integration story set up for that Pages feature.

Implement a working MVP in the app

Similar to testing, you can either build your story after you have a working feature, or use the story to drive the component's development. I like starting with a low-fidelity working feature in the app, then moving to Storybook to refine the UI.

All of the necessary API endpoints for this feature already existed, so I opted to build the MSW handlers based on real data from the server. To do so, I observed the network traffic in the developer console while exercising the feature. After that I copied (via right-click) the relevant requests and responses related to the feature's interaction points.

Wire up MSW for Storybook

I'm going to focus specifically on how we integrated Storybook with MSW, ignoring setup. Check out this article for a more thorough walk through of setting everything up. While we're not using it yet in our app, I recently learned there is even a Storybook addon that simplifies the integration. For educational purposes, I'll still walk through the DIY setup we currently use.

Given a standard MSW setup, first make sure the service worker is kicked off in preview.js.

// .storybook/preview.js

import { worker } from '../src/mocks/browser';

// this allows you to simply use `worker.use` in your story and/or story decorators
worker.start();

In my case there was a lot of API responses that would clutter the story itself, so I exported an object with named keys from a file called story-data.

// story-data.ts
export const data = {
  latest: { ... }
}

With the response data in place, import data and configure the worker.use API from MSW using the Storybook template pattern.

import { data } from './story-data'
const Template: Story<Args> = (props) => {
  worker.use(
    rest.get("/latest", (req, res, ctx) => {
      return res(ctx.json(data.latest))
    },
    ...
  )
  return <Component {...props} />
}
export const Demo = Template.bind({})

I prefer to put worker.use in the story component itself instead of a decorator because I often end up using Storybook args to influence the MSW response data.

const Template: Story<Args> = ({ loading, ...props }) => {
  worker.use(
    rest.get("/latest", (req, res, ctx) => {
      if (loading) {
        return res(
          ctx.delay(1000 * 60),
          ctx.json(data.latest)
        )
      }
      return res(ctx.json(data.latest))
    },
    ...
  )
  return <Component {...props} />
}

Another thing to remember is you can often leverage the request object data (req) to influence the response data.

const Template: Story<Args> = ({ loading, ...props }) => {
  worker.use(
    rest.get("/latest/:id", (req, res, ctx) => {
      if (loading) {
        return res(
          ctx.delay(1000 * 60),
          ctx.json(data.latest)
        )
      }
      return res(ctx.json(data.someLookup[req.params.id]))
    },
    ...
  )
  return <Component {...props} />
}

From here, you can get creative combining Storybook arguments and request data to simulate full interaction with a remote data source. Now in addition to observing with and interacting with specific UI states, we get to leverage MSW and Storybook to represent specific server and network states. Similar to the ethos of integration tests using React Testing Library, we're testing and exercising our components in a way that is much closer to how a user will interact with them in production, which is a good, good thing.

If you're interested in working at Process Street, we're hiring!

Mocking framer-motion v4

Mike Schutte — Wed, 14 Apr 2021 23:44:29 +0000

Testing Library has changed the UI testing game for the better. If you haven't tried it yet, check it out.

At work our new UI efforts are powered by Chakra UI, which uses Framer Motion under the hood for animations. With all this work, we're testing all of it using Jest and React Testing Library (RTL).

One great way to defend against UI regressions (copy, styles, etc) is snapshot testing. As we're getting more and more into Chakra's features and better tests, we've run into issues where the animated style properties have minute differences between snapshots.

RTL recommends mocking animation libraries to solve this problem. There are a few solutions for doing this with framer-motion on the web, but I don't think they are up to snuff for the current version of the library (4._).

After digging around the framer motion source, I realized our attempt at mocking the motion export as an object (see here) wasn't working because motion is constructed using Proxy.

Enough with the words, how do I stabilize my snapshot tests?!

// __mocks__/framer-motion.ts

import { CustomDomComponent, CustomMotionComponentConfig } from 'framer-motion/types/render/dom/motion-proxy';
import * as React from 'react';

const actual = jest.requireActual('framer-motion');

// https://github.com/framer/motion/blob/main/src/render/dom/motion.ts
function custom<Props>(
  Component: string | React.ComponentType<Props>,
  _customMotionComponentConfig: CustomMotionComponentConfig = {},
): CustomDomComponent<Props> {
  // eslint-disable-next-line @typescript-eslint/ban-ts-comment
  // @ts-ignore
  return React.forwardRef((props, ref) => {
    const regularProps = Object.fromEntries(
      // do not pass framer props to DOM element
      Object.entries(props).filter(([key]) => !actual.isValidMotionProp(key)),
    );
    return typeof Component === 'string' ? (
      // eslint-disable-next-line @typescript-eslint/ban-ts-comment
      // @ts-ignore
      <div ref={ref} {...regularProps} />
    ) : (
      // eslint-disable-next-line @typescript-eslint/ban-ts-comment
      // @ts-ignore
      <Component ref={ref} {...regularProps} />
    );
  });
}

const componentCache = new Map<string, unknown>();
const motion = new Proxy(custom, {
  get: (_target, key: string) => {
    if (!componentCache.has(key)) {
      componentCache.set(key, custom(key));
    }

    // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
    return componentCache.get(key)!;
  },
});

module.exports = {
  __esModule: true,
  ...actual,
  AnimatePresence: ({ children }: { children: React.ReactChildren }) => <>{children}</>,
  motion,
};

Now in your test setup file you can call jest.mock('framer-motion') and all the animation related properties will be filtered out.

Happy testing!

React listbox component

Mike Schutte — Tue, 02 Feb 2021 21:26:26 +0000

I recently posted about a hook that manages the state needed for a list with the listbox role.

After writing about it and making an isolated code sandbox for it, a thought kept nagging at me.

I shouldn't have to use a hook directly for this. There should be a component for Listbox component and ListboxOption that manages that state implicitly.

I don't want to have to manually add the mouseenter event listener to change the selected item. I want a component to handle that detail for me.

This desire and instinct for implicit compound component state comes from APIs like ReachUI's Tabs.

With the help of React.Children.map, React Context, and keys, I was able to implement a lovely compound component API.

<Listbox>
  {items.map((item) => (
    <ListboxOption key={item.id}>
      <Item {...item} />
    </ListboxOption>
  ))}
</Listbox>

An item can tell if its selected by way of render props or a useContext hook. See the details and working example here:

Thanks! Happy coding ✌️

Listbox role state in React

Mike Schutte — Fri, 29 Jan 2021 22:26:35 +0000

Background

Over at Process Street we're on the tail end of an integration with Algolia to manage global search functionality.

Working on a shape up style team with two people on the back-end, one on design, and one on the front-end (me), we had a little over two weeks to implement a small batch pitch to get global search rolled out.

Once we got the feature working, we got some feedback.

I wish I could use keyboard commands to go up and down the list and then hit enter to go to that link.

Totally makes sense. A UX instinct we have from the many modals we interact with like Apple's Spotlight, Alfred, and most Algolia-powered search modals.

We're using Chakra UI to implement our design system and power our new features. I assumed that there would be a preconfigured way to use keyboard controls on a modal. Alas, nothing in the modal docs hinted at keyboard controls for a list.

It didn't take long for me to realize I had concluded hastily that Chakra would have that behavior out of the box. The fact that a modal contains a list of items is my choice as the consumer of the modal. A modal isn't designed just for lists.

So then I thought:

Wait a second, how is Chakra's own documentation search modal implemented?

Inspecting the modal with dev tools quickly revealed an ARIA role I had never even heard of: the listbox. Digging even further, I found that Chakra is using a third-party listbox implementation from Algolia's DocSearch project. DocSearch doesn't fit Process Street's proprietary use case, so I decided to dig in and manage our own listbox.

A listbox is like an "ejected" select component. It's an interface for choosing one or more options from a list. Surprisingly, I didn't find much written on implementing these from scratch in React or in other JS ecosystems. Therefore, I stitched together a few different resources to create a hook that manages the effects and state for a listbox component.

The shiny code

I think for certain problems, it's better to share the code and context than to package it up as yet-another-npm-module that requires upkeep.

Here is a sandbox with the hook's implementation and test.

Maybe Chakra would be open to adding this hook to their library 😉.

Thank you! Happy problem solving ✌️

Sources

Dynamically assigning a function name in javascript

Mike Schutte — Sat, 16 Jan 2021 01:17:57 +0000

Say you're writing some higher order functions that return other functions. In my case it was a utility that creates a typed hook to consume some context.

I wanted to let the consumer of this utility to have a reasonable name property on the hook returned, not some generic library code name like "useContext".

The first attempt did not work.

const someFunc = () => { ... }
someFunc.name = someConfig.name

You get a nice error at least.

So then I think to myself 🤔 Do I know anything about dynamic naming in general in JavaScript?

💡

Objects can have dynamic keys! With square brackets, we can stringify runtime values.

{ [someVar]: "woohoo" }

So, to solve my configurable function name problem, I used computed keys to create an object and computed keys again to destructure the function value.

🤯 Right?

const custom = "Jerome"
const { [custom]: someFunc } = { [custom]: () => void 0 }
someFunc.name === "Jerome" // true

^ You can try that example in your browser console.

Pretty neat stuff! Here was my final solution, inspired by this cheatsheet.

import * as React from 'react';

export function assertContext<T>(
  context: T | undefined,
  config: {
    hookName: string;
    providerName: string;
  },
): asserts context is T {
  if (typeof context === 'undefined') {
    throw new Error(`\`${config.hookName}\` must be used within \`<${config.providerName} />\``);
  }
}

export function createUsableContext<T>(config: {
  hookName: string;
  providerName: string;
}): [() => T, React.Context<T | undefined>] {
  const Context = React.createContext<T | undefined>(undefined);

  // assign the function name dynamically by instantaneously assigning and destructuring an object field
  // const useContext = ... would result in the fn name being `useContext`. Not helpful.
  const { [config.hookName]: useContext } = {
    [config.hookName]: (): T => {
      const context = React.useContext(Context);
      assertContext(context, config);
      return context;
    },
  };

  return [useContext, Context];
}

Mise en place React

Mike Schutte — Sat, 09 Jan 2021 15:25:55 +0000

I really love what React development can feel like nowadays. I wrote (a lot) about how to up the positive feels and momentum of feature development. It builds on the culinary idea of mise en place, where you prepare all your ingredients before composing them together to make a dish. I spent a lot of time on this, I'd love to hear your feedback!

I leaned into a lot of Notion features like toggles and nested pages, so all the content is there but I wanted to share with the dev.to community all the same.

Full tutorial here.

Happy ~~cooking~~ coding!

Photo by Icons8 Team on Unsplash.

Testing element dimensions without the browser

Mike Schutte — Fri, 18 Dec 2020 01:49:59 +0000

React Testing Library takes the joy and possibilities of testing to the next level.

I ran into a case today at work where I wanted to assert a conditional tooltip. The tooltip should only show up if the label text was overflowing and cut off by an ellipsis.

Here is a simplified implementation of what I did.

import * as React from 'react';
import { Tooltip } from 'Tooltip';

// text overflow is triggered when the scroll width
// is greater than the offset width
const isCutOff = <T extends HTMLElement>(node: T | null) => 
  (node ? node.offsetWidth < node.scrollWidth : false);

export const useIsTextCutOff = <T extends HTMLElement>(
  ref: React.RefObject<T>
): [boolean, () => void] => {
  // since the ref is null at first, we need a stateful value
  // to set after we have a ref to the node
  const [isTextCutOff, setIsTextCutOff] = React.useState(
    isCutOff(ref.current)
  );

  // allow the caller to refresh on account of refs being 
  // outside of the render cycle
  const refresh = () => {
    setIsTextCutOff(isCutOff(ref.current));
  };

  return [isTextCutOff, refresh];
};

interface Props {
  href: string;
  label: string;
}

export const NameRenderer: React.FC<Props> = ({
  label,
  href
}) => {
  const labelRef = React.useRef<HTMLDivElement>(null);
  const [isTextCutOff, refresh] = useIsTextCutOff(labelRef);

  return (
    <div>
      <Tooltip showTooltip={isTextCutOff} tooltip={label}>
        <div
          // adds ellipsis on overflow
          className="truncate-text"
          onMouseEnter={refresh} 
          ref={labelRef}
        >
          <a href={href}>
            {label}
          </a>
        </div>
      </Tooltip>
    </div>
  );
};

Because the ref.current value starts as null, I can't compute the width on the initial render. To solve this problem, I used the onMouseEnter event to check the element width once someone actually hovers over it. We can be confident ref.current will be defined by then.

Cypress would be a great way to test this as well, but the screen I'm on in this context requires auth and specific test data set up that's easier to do at a component integration test level.

The key here is to intervene with how React handles ref props. With hooks, you just assign a name to a React.useRef(null) result and pass that to a node like <div ref={someRef} />.

When you inspect the width on that virtual node, you'll get a big fat 🍩. There is no actually painted element with a width to measure.

So, we'll spy on React.useRef with jest.spyOn and use get and set functions from good ol' JavaScript getter and setters.

import * as React from 'react';
import * as utils from '@testing-library/react';
import user from '@testing-library/user-event';
import { NameRenderer } from '.';

describe('Components: NameRenderer', () => {
  const props = {
    href: "blah blah",
    label: "halb halb",
  };

  type NodeWidth = Pick<
    HTMLElement,
    'offsetWidth' | 'scrollWidth'
  >;

  const setMockRefElement = (node: NodeWidth): void => {
    const mockRef = {
      get current() {
        // jest dom elements have no width,
        // so mocking a browser situation
        return node;
      },
      // we need a setter here because it gets called when you 
      // pass a ref to <component ref={ref} />
      set current(_value) {},
    };

    jest.spyOn(React, 'useRef').mockReturnValue(mockRef);
  };

  it('shows a tooltip for cutoff text', async () => {
    setMockRefElement({ offsetWidth: 1, scrollWidth: 2 });

    const { getByRole } = utils.render(
      <NameRenderer {...props} />
    );
    const checklist = getByRole(
      'link',
      { name: new RegExp(props.label) }
    );

    expect(utils.screen.queryByRole('tooltip'))
      .not.toBeInTheDocument();

    user.hover(checklist);

    expect(utils.screen.getByRole('tooltip'))
      .toBeInTheDocument();

    user.unhover(checklist);

    await utils.waitForElementToBeRemoved(
      () => utils.screen.queryByRole('tooltip')
    );
  });


  afterEach(() => {
    jest.resetAllMocks();
  });
});

The setMockRefElement utility makes it easy to test different variations of the offsetWidth to scrollWidth ratio. With that visual part of the specification mocked, we can return to the lovely query and user event APIs brought to us by Testing Library.

Here is a full demo.

Declarative rendering with Apollo Client results

Mike Schutte — Mon, 07 Dec 2020 21:25:17 +0000

RedwoodJS introduces a great abstraction for dealing with query results from Apollo Client: cells.

If you've used Apollo Client before, you've probably written something like the following hundreds of times.

const { loading, data } = useQuery(...)
if (loading) {
  return ...
}

if (data.length === 0) {
  return ...
}

return (
  ...
)

Am I wrong?

I love the idea of cells. I can tell it's a great abstraction because there's no need to port my whole app over to RedwoodJS to get the same immediate declarative improvements. Here is a Redwoods-y utility function to render the result of a GraphQL query in any codebase with Apollo Client query results.

import * as React from "react";
import { ApolloError, QueryResult } from "@apollo/client";

const isEmpty = (data: NonNullable<QueryResult["data"]>): boolean => {
  const dataValue = data[Object.keys(data)[0]];
  return (
    dataValue === null || (Array.isArray(dataValue) && dataValue.length === 0)
  );
};

export const renderResult = <T extends QueryResult>(
  result: T,
  options: {
    isEmpty?: (data: NonNullable<T["data"]>) => boolean;
    Loading: React.FC;
    Failure: React.FC<{ error: ApolloError }>;
    Empty: React.FC;
    Success: React.FC<{ data: NonNullable<T["data"]> }>;
  }
): React.ReactElement => {
  return result.loading ? (
    <options.Loading />
  ) : result.error ? (
    <options.Failure error={result.error} />
  ) : (options.isEmpty ?? isEmpty)(result.data) ? (
    <options.Empty />
  ) : (
    <options.Success data={result.data} />
  );
};

We can pass a custom isEmpty function if the shape of our data is more unique than the basic case.

Example usage:

import * as React from "react";

import { render } from "lib/render-result";

const MyComponent: React.FC = () => {
  const result = useQuery(...)
  return render(result, {
    Loading,
    Failure,
    Success,
    Empty,
    isEmpty: (data) => data.customPath.toCheck.length === 0
  });
};

export default MyComponent;

const Loading: React.FC = () => {
  return ...
};

const Empty: React.FC = () => {
  return ...
};

type Data = NonNullable<QueryResult["data"]>;
const Success: React.FC<{ data: Data }> = ({ data }) => {
  return ...
};

type FetchError = NonNullable<QueryResult["error"]>;
const Failure: React.FC<{ error: FetchError }> = ({ error }) => {
  console.error(error);
  return ...
};

✌️

Loading states with Storybook and Mock Service Worker

Mike Schutte — Sat, 05 Dec 2020 19:31:53 +0000

So there I am wanting to make Storybook stories for four states of a component that fetches its own data by way of an Apollo Client hook.

The four states are:

Loading 🐌
Error 🚨
No data 📭
Data 😊

I have Mock Service Worker (MSW) set up to intercept network calls. It's pretty straight forward to set up the mocks for the two data states (empty and present) with MSW's context.data and the error state with context.errors.

But how do I render a component in its loading state indefinitely for the purpose of viewing it in a Storybook demo?

I didn't find anything existing on the usual suspects of Stack Overflow, GitHub issues, and or here on DEV, so I went back to the MSW docs and found the perfect solution:

context.delay

I tried using Infinity as the duration at first, but to no avail. I figure one hour is more than enough to adequately work on or review the loading state UI.

Here is my final implementation:

graphql.query<GetTagsQuery, GetTagsQueryVariables>(
  "GetTags",
  (_req, res, ctx) => {
    // 1 hour delay to view the loading state
    return res(
      ctx.delay(1000 * 60 * 60 * 60), 
      ctx.data(newGetTagsData({}))
    );
  }
)

And here is all of the relevant story code:

import * as React from "react";
import { Flex, Heading } from "@chakra-ui/react";
import { Meta, Story } from "@storybook/react";
import { worker } from "mocks/browser";
import { graphql } from "msw";

import { GetTagsQuery, GetTagsQueryVariables, newGetTagsData } from "api";

import ViewTags from ".";

export default {
  title: "Features/View Tags",
  component: ViewTags,
  decorators: [
    (story) => (
      <Flex py="20" flex="1" direction="column" justify="center" align="center">
        <Heading mb={4} fontSize="6xl">
          Avett Rx
        </Heading>
        {story()}
      </Flex>
    ),
  ],
} as Meta;

const Template: Story = () => <ViewTags />;

export const Loading: Story = Template.bind({});
Loading.decorators = [
  (story) => {
    worker.use(
      graphql.query<GetTagsQuery, GetTagsQueryVariables>(
        "GetTags",
        (_req, res, ctx) => {
          // 1 hour delay to view the loading state
          return res(
            ctx.delay(1000 * 60 * 60 * 60), 
            ctx.data(newGetTagsData({}))
          );
        }
      )
    );
    return story();
  },
];

This use case comes from an article I'm publishing soon that outlines setting up a project with all of my favorite tools for React development in 2020:

👀 Keep an eye out for it! 👀