Here are all the things you probably forgot to do, Trys:

1. Use renderHook from testing-library-test-utils

It gives you a result object, as well as some very handy waitFor functions. These are particularly useful when the hook fires off an async function in useEffect.

const { result, rerender } = renderHook(useHookYouAreTesting, { initialProps: { ...props } });

2. Wrap act around state updates

Anything that causes a state update and subsequent rerender should be wrapped in act.

3. Use the right act

act from react-dom/test-utils is different from act from @testing-library/react which is different from react-test-renderer. Use the right one. I don’t know which is the right one, but one of them is 🤷

4. waitFor is your friend

waitFor waits for an assertion to pass. It’s handy when you’re testing async code waitForValueToChange was really useful, but doesn’t work in React 18. Use waitFor instead.

5. jest.useFakeTimers is also your friend

Timeouts and Intervals are a pain to test. jest.useFakeTimers makes them a little less painful. Use jest.advanceTimersByTime to move time forward. Use jest.runOnlyPendingTimers to run any pending timers. Use jest.useRealTimers to go back to the real world (pop that in an afterEach).

6. Group things

I’m waiting for my friend Szymon to write a blog post on this (consider this a nudge, pal!) - he’s come up with a beautiful pattern for testing hooks/components, so I’ll link to that here when it’s done.

use lets you read the value of a promise (or context if you’re that way inclined). It feels like a bit of syntactic sugar, to avoid writing .then() or await within your component, but I’m sure there’s more to it than that.

When is ‘use’ useful?

Take this carousel. Pretty standard stuff at the end of a product page. Definitely shouldn’t be render-blocking, and a prime candidate for deferred loading. We could move the data request into a client-side handler and call useEffect to fetch the data on the client, but finding ways to avoid useEffect becomes a source of personal pride once you’ve worked on a React project for any length of time. This approach has to wait for the whole page to hydrate before it can get to work loading the data.

Instead, we can still begin fetching the data on the server, but combine <Suspense> and use to handle the loading state before resolving it on the client.

What does ‘use’ look like?

Before:

export default async function Page() {
    // Wait for the data to load
    const vehicles = await getVehiclesFromDB();

    return (
        <SimilarVehicles vehicles={vehicles} />
    );
}

export const SimilarVehicles: React.FC<{
    vehicles: VehiclePreview[];
}> = ({ vehicles }) => {
    return (
        <section className={cx(styles.section)}>
            {vehicles.map((vehicle) => (
                <VehicleCard
                    key={vehicle.vehicleId}
                    vehicle={vehicle}
                />
            ))}
        </section>
    );
};

After:

export default async function Page() {
    // Crack on rendering the page
    const vehiclesPromise = getVehiclesFromDB();

    return (
        <Suspense fallback={<LoadingState />}>
            <SimilarVehicles vehiclesPromise={vehiclesPromise} />
        </Suspense>
    );
}

export const SimilarVehicles: React.FC<{
    vehiclesPromise: Promise<VehiclePreview[]>;
}> = ({ vehiclesPromise }) => {
    // Resolve the promise
    const vehicles = use(vehiclesPromise);

    return (
        <section className={cx(styles.section)}>
            {vehicles.map((vehicle) => (
                <VehicleCard
                    key={vehicle.vehicleId}
                    vehicle={vehicle}
                />
            ))}
        </section>
    );
};

How does ‘use’ work?

By continuing to call the vehicles database from the server, we’ve kept our precious server-side secrets safe. But by omitting await, we can crack on with streaming the page to the user much quicker than before.

React pops our fallback component in place, and continues to stream the page in the background until the database call resolves. At that point, the page connection closes and the component inside <Suspense> is rendered. use converts the promise over to our intended data format, and the component renders as expected.

You can even use ErrorBoundary to handle promise failures. Pretty neat.

Does ‘use’ work without JS?

Sadly not. React needs JS at runtime to swap out the loading content with the deferred content. Non-JS users will be left with the loading component for infinity. So this isn’t appropriate for core user journey functionality, or spider-friendly content.

In a client-side app, a new ApolloClient gets created for each page load. But in a node.js service, it runs once on application launch and sits in memory till the whole application has been killed - that could be days or weeks.

Not only that, as the server-side ApolloClient sits in memory, it’s shared between every user connection, and is therefore ripe for leaking data between connections. Not what we want.

To overcome this problem, we instantiate a new ApolloClient for each connection. We can wrap this up in a nice reusable method:

import { ApolloClient } from 'apollo-client';
import { createHttpLink } from 'apollo-link-http';
import { InMemoryCache } from 'apollo-cache-inmemory';
import { withClientState } from 'apollo-link-state';
import { ApolloLink } from 'apollo-link';

const CreateClient = (defaults = {}, links: any[] = []): ApolloClient<{}> => {
  const cache = new InMemoryCache();

  const stateLink = withClientState({
    cache,
    resolvers: {},
    defaults
  });

  return new ApolloClient({
    connectToDevTools: false,
    ssrMode: true,
    link: ApolloLink.from([
      stateLink,
      ...links,
      createHttpLink({
        uri: process.env.GRAPHQL_URL
      })
    ]),
    cache
  });
};

export { CreateClient };

We can then import the file on launch, and crucially, run the CreateClient function for each request. Not only that, we can pass in defaultState and prime the apollo-link-state cache with any user defaults. Furthermore, we can add additional link helpers like onError.

server.get('/*', async (req: express.Request, res: express.Response) => {
  const defaultState = {};
  const errorLink = onError((error) => {});

  const client: ApolloClient<{}> = CreateClient(defaultState, [errorLink]);

  const Application = () => {
    return (
      <ApolloProvider client={client}>
        <App />
      </ApolloProvider>
    )
  }

Reusing CreateClient

We could’ve run all that CreateClient code within the server.get method, but by moving it outside, we can reuse it in our tests. This time, there’s no defaultState or additional links, so we can call createClient directly.

import * as React from 'react';
import ApolloClient from 'apollo-client';
import { ApolloProvider } from 'react-apollo';
import { mount } from 'enzyme';
import { CreateClient } from '@/gql/CreateClient';
import { User } from '@/pages/User';

describe('<User /> page', () => {
  const client: ApolloClient<{}> = CreateClient();
  it('renders a user profile', () => {
    mount(
      <ApolloProvider client={client}>
        <User match={{ params: { username: 'trys' } }} />
      </ApolloProvider>
    );
  });
});

Here’s a ‘standard’ component as a starting point:

import * as React from 'react'

class Sidebar extends React.Component {
  public render() {
    // ...
  }
}

export { Sidebar }

On the surface, that final line looks like a ordinary object with property/value shorthand, but sadly that’s not the case. Assignment within that ‘object’ is not allowed, it only accepts a comma separated list. This prevents withApollo being assigned in a ‘normal’ object-y way:

export { Sidebar: withApollo(Sidebar) }

The solution

Although not very elegant, the best solution I found was to rename the original class declaration and export the correctly named wrapped variable:

import { withApollo } from 'react-apollo';

class SidebarComponent extends React.Component {
  public render() {
    // ...
  }
}

export const Sidebar = withApollo(SidebarComponent);

Now with added Typescript

The above code works well in JS-land, but Typescript tends to get a bit grumpy. The component needs to be aware of props being passed in from the withApollo HOC. The solution is to add a new type to the component:

import * as React from 'react';
import { withApollo, WithApolloClient } from 'react-apollo';

class SidebarComponent extends React.Component<WithApolloClient<{}>> {
  public render() {
    // ...
  }
}

export const Sidebar = withApollo(SidebarComponent);

If you already have some custom props defined on the component, they can be nested within the WithApolloClient annotation:

interface Props {
  id: number;
}

class SidebarComponent extends React.Component<WithApolloClient<Props>>