Best usage with Storybook?

[RasyadiAbdoellah]

I've been trying to wrap my head around how to best use Storybook with react-query hooks, especially with isLoading and isError results.

As of now the best I've come up with is to wrap the component in a WithQuery component and passing the response down.

So, for example a BlogPost component that gets blog id from a URL param using react-router...

//BlogPost.js
export function BlogPost ({response}) {
const {data} = response
  if(response.isLoading) {
    <h1>...loading</h1>
  }
  if(response.isError) {
    <h1>...oops</h1>
  }
  return (
    <>
      <h1>{data.title}</h1>
      <p>{data.content}</p>
    </>
  )
}

//hooks are in a parent component and passed down via props
export default WithQuery() {
  const {id} = useParams()
  const response = usePost(id) //wrapped useQuery hook

  return <BlogPost response={response} />
}

This would allow me to import {BlogPost} in BlogPost.stories and view the different results in isolation.

//BlogPost.stories

import {BlogPost} from 'BlogPost.js'

export default {
  component: BlogPost,
  title: 'Blog Post',
}

export const Success = () => <BlogPost response={{data: mockBlogPost}}/>

export const Loading = () => <BlogPost response= {{isLoading: true}}/>

export const Error = () => <BlogPost response={{isError: true}}/>

This method works and isolates the component from the query, but I feel like this goes against the point of using hooks. Additionally complex components that uses multiple endpoints to populate its data (like an aggregator that pulls content from various sources) would require a lot of data to be passed down via props.

Has anyone come up with a better usage pattern?

[TkDodo]

Here is a very good guide of setting up storybook with react-query and mock service worker: storybookjs/storybook#12489 (comment)

I haven’t tried it out yet, but theoretically, it will allow you to get rid of your abstraction and just add stories for components that make actual requests, and they will be mocked on network level.

[RasyadiAbdoellah]

Thanks for the link, that looks like it's the best method for integrating queries to SB.

After having a look through other forums it looks like there's no avoiding the presentational/container component pattern with Storybook, so I'll have to stick with the current component structure.

[angie]

For anybody still arriving at this discussion, Storybook now has msw-storybook-addon.

[mhesham32]

I think the answer in the link will be perfect for most scenarios but there is a problem if you're using something like Firebase where the back-end endpoints are hard to track not like a regular API. Does anyone have a suggestion about this case? I think we can mock the data of the query by using queryClient.setQueryData('rest-ricky', mockFn) but will this be applied for all the references of this query or some of them will still call the firebase query

[TkDodo]

If you put mock data into the cache with setQueryData and set staleTime to Infinity, the api won't be called.

[mhesham32]

thanks, I will go with that then

[pahans]

here is how we mock react query data for the storybook.

const queryClient = new QueryClient({
  defaultOptions: { queries: { staleTime: Infinity, refetchOnMount: true } },
});

export const BlogPost: Story = {
  args: {},
  decorators: [
    (Story) => {
      queryClient.setQueryData(["cash-key"], {
        //... set your mocked data here
      });
      return (
        <QueryClientProvider client={queryClient}>
          <Story />
        <QueryClientProvider>
      );
    },
  ],
};

[mhesham32]

it's a great way to do it

[k0l11]

For anyone arriving at this usage example: it should be </QueryClientProvider> as the closing tag and not <QueryClientProvider>