Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
> For those wondering what the use case is, you must not have tried it. It does take work to set up (with each version that's less), but it can be very nice to test in isolation esp in cases where a component is under a login, the 4th page of a 10 page form, etc. Also obviously if you're working on a component library that ships without an app, Storybook can be your development and/or demo app.
I have worked with storybook extensively over the past couple of years and my team is moving away from it in favour of MSW (https://mswjs.io).
For "4th page of a 10 page form" during the development there's hot reloading which is really stable nowadays and haven't failed me, although I understand that some setups are old and it might be easier to configure Storybook than good hot reloading.
I'm not entirely sure about the testing part of it and I'd be grateful if you could elaborate. I haven't felt the need for some special setup with SB because for unit tests, I can test a deeply nested component separately. For E2E tests, I usually test the whole form.
I agree on the component library part, this is probably the only use case where Storybook is 100% justified, but I'm unconvinced about the
Storybook is great and all, but these days nearly every Dependabot alert I get is about a sub-dependency of Storybook. Since Dependabot doesn't currently allow you to ignore dev dependencies and only check production dependencies [0], this makes Storybook a Big Noise Generator and every time I dismiss another alert from it, I can't help but wonder if there's a better option out there.
[0] https://github.com/dependabot/dependabot-core/issues/2521
I've used Storybook during development for a while now and the use case you present is how the Storybook is pitched. I actually agree about the simplicity of discovering the components. What I disagree with, though, is that I can't see 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 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 not needing the API, testing in 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...
It seems like CloudCannon has this with their open-source Bookshop component editor which can integrate with their hosted CMS.
https://github.com/CloudCannon/bookshop
The small user base, however, means there probably aren't other CMSs that use the same component representations or CMS live data bindings. This means while Bookshop components are portable between CMSs on paper, it's not in practice (e.g. you can't easily hook it up to another CMS with a visual editor like Wordpress's Gutenberg, Storyblok, etc.).