[mm263]

I've used Storybook during development for a while now and the use case you present is how the Storybook is usually pitched. I actually agree about the simplicity of discovering the components. What I disagree with, though, is that I can't see the value of "develop & test your UI independently from your app" part. It forces me to decouple the state from a component and this in turn adds unnecessary complexity to the architecture.

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...

[SebastianKra]

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.

[mm263]

> 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.