[dsego]

Why only for UI libraries? I imagine you can develop & test your UI independently from your app. Say a page has complex form with many states, you test it out in storybook before embedding in your app and connecting to your API backend. The other things is for all your custom components, easier to onboard a new developer, they can just look at storybook to see if a UI component already exists in the project, without having to dig through the code.

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

[lowboy]

This has great discoverability for other eng teams ime. Duplication of components across multiple product teams is a drag on velocity and a major pain when you want to update brand/design across the board. In a previous role, we spun up a Storybook with the few dozen atomic React + pure HTML components, shopped it around the relevant teams. Saw great uptake for centralizing components, and a few teams did storybook-driven development for their more complex UIs. Can recommend.

Also very useful for non technical stakeholders (design, product, etc) to test UIs in isolation.