Pattern for isolating "loading" checks

[ehaynes99]

I'm curious how others are handing this issue. It's clear enough in simple examples, but I've been wrestling with the pattern for doing this at scale that's both nice to use in the code and easy to test.

My current pattern is using react-async along with contexts, so for each of these, I have a file such as OrderContext.js that exports:

• OrderContext - the React.createContext() result
• OrderProvider - loads the data and provides the result of react-async#useAsync
• useOrder - exposes the data of the context

For each route, I have a top level OrderPage which renders a bunch of Providers, watches the raw contexts, handles errors, and renders a spinner until they're all complete. This is convenient, because then I can write all of my display components to assume that the hooks they use provide a valid, synchronous value.

These components are easy to test, as I simply wrap the component with <OrderContext.Provider value={{ data: { mock: 'value' } }})>,

However, with react-query, the suggested pattern is to use the query result directly. I can still do the spinner pattern, which works well enough in the app, but when trying to test... now we have a problem. There is no way to avoid the asynchronicity, so there is always an initial render where data is undefined. I've played with various solutions, but none of these are particularly nice to use:

• a pseudo-spinner for tests, but this ends up with a lot of boilerplate
• using a ReactQueryCacheProvider as in this discussion, but this means every single test needs to be aware of the structure of query keys
• mock the custom hook providing the query. This seems like the simplest, but jest.mock is rather wordy when using dynamic results

[wolverineks]

what aspect of the component are you trying to test?
could you provide a sample test?

[ehaynes99]

The specifics of the component could be anything, but a contrived example below. Obviously, I could just pass it down for this simple example, but pretend it's much deeper.

Overall, I just don't want layers of nested components all having to care about the async status. I want gatekeepers higher in the tree so that the majority of them are simply data -> markup

The test in this sandbox has a couple of the solutions I mentioned above, so not an insurmountable problem. I like the ReactQueryCacheProvider solution, but I assume mutators are going to wipe out that data, so mocking the fetch call would still have to happen.

https://codesandbox.io/s/dreamy-mestorf-k4fyz

// apiClient.getFilms does a `fetch`
const useFilms = () => useQuery('films', apiClient.getFilms)

const FilmsPage = () => {
  const query = useFilms()

  switch(query.status) {
    case 'error' : return <div>Something went wrong!</div>
    case 'loading': return <div>Loading...</div>
    default: {
      // Nothing lower in the tree needs to be concerned
      // with loading or errors
      return <div><FilmsList /></div>
    }
  }
}

const FilmsList = () => {
  // this wouldn't be rendered unless `data` was defined
  const films = useFilms().data.results

  return (
    <ul>
      {films.map(({ title }) => (
        <li key={title}>{title}</li>
      ))}
    </ul>
  )
}

But then to render FilmsList in the test, that safety from the pending value is not present:

jest.spyOn(apiClient, 'getFilms').mockImplementation(async () => ({ results: mockFilms }))

it('fails to render', async () => {
  // useFilms().data will be undefined on initial render
  render(<FilmsList />)
})

[wolverineks]

are you saying that you are ensuring that data is preloaded in the app, prior to mounting the component that consumes the data?

[wolverineks]

if thats the case, i would consider testing them both together