Re:Storybook 8
by SebastianKra on Thursday March 14, 2024 @01:56AM
(#39700932)
I don't think the point is to isolate all state. In the SiloUtilizationPage, I would assume that the hard part is getting the result of the two useApiQuery calls. The other state could be set up by clicking around or in a `play()` function. Since you're using ReactQuery, you can just create a separate QueryClient for testing, call `setQueryData` on it, and then pass it in through a context.
That way you could render this component without any changes to it.
> I don't think the point is to isolate all state
We may have been using it incorrectly in my team, but our pattern is moving out all of the state out of the component, essentially separating the logic from the view.
I'm going to use Oxide console [1] as an example because it has a really good setup of MSW + OpenAPI autogenerated mocks (which means that it doesn't need any complete running backend, just a defined contract).
Consider this fairly simple page [2]. If I'm using the Storybook pattern, I'm keeping all of the state outside of the component, which means I now have to manually memoize every single variable defined before the return to make sure that the component doesn't do any unnecessary re-renders. This includes `intervalPicker`, `commonProps`, `setFilterId`, every return of `useDateTimeRangePicker`. With MSW I have benefits of not needing the API as well as developing in the context of a real production app, using the same exact mocks for unit tests and development.
[1]: https://github.com/oxidecomputer/console
[2]: https://github.com/oxidecomputer/console/blob/main/app/pages...