Many teams struggle to write tests for their UI. It's a hard problem to solve, a mixture of culture challenges and technology challenges.
Tests show how pieces work together outside of the small confines of a live system. If you don't write tests, you probably aren't considering all the ways you component can work outside of the narrow confines when you, as the author, wrote and tested it. And, you probably can't consider how another developer will use your component and change the environmental code around it.
Storybook gives you all the benefits of tests in that you can pull out pieces and play them back in isolation. I see all the benefits of tests (except that I don't see the results in CI) when using storybook and refactoring. Broken stories tell me a lot about code problems.
Storybook is UI testing done right, we just needed to brand it as a story rather than a test. ;)
Congratulations on a big milestone. This is an incredible piece of software that I use on all my projects.
Storybook pairs extremely well with https://www.chromatic.com to give you that great test automation experience. Essentially Chromatic runs visual diffing for all your stories. You can run them on multiple browsers and even for multiple view port sizes.
Storybook is also a nice launching point for visual diffing. At my previous job we used a tool that ran all of our stories and did an image diff. It makes catching css regressions much easier. There are some challenges, for example when I had left we still hadn't fully found a solid way to diff the components in interactive states, but even without that it was very useful.
We recently did this inside Google for LitElement (our web components library). We wrote a small Storybook-like system that pulls from the monorepo, and checked-in stories can both be displayed in a visual catalog, as well as run as visual regression tests. They can also be used for live development with our hot reload server.
I am not following how you can use Storybook for testing? I think it's mostly a dummy renderer of your components? I don't see any easy way to put a component in a specific interactive state forcing code in the component to support this.
Would someone run the Storybook pages through something like Cypress?
Does/can it integrate with CI? This is what I need now. While I want full integration testing I'd like to have stories/unit tests for UI components too.
This is great to see. I've always been a fan of Storybook but have also struggled with it a lot. Each new release has reduced the struggle. To their credit, it's hard to drop something like Storybook into a project because frontend projects have almost no rhyme or reason to how they are made up (well, React anyway, which is what I mostly work in).
I am also using Storybook for my game dev. I wrote my own renderer for my engine and so the entities in my game have stories. It makes building new entities and seeing how two entities interact so much nicer and faster.
Anecdote, but at my work there's two teams whose libraries we use that use Storybook for documentation and it is decidedly worse than other teams that create non-Storybook documentation.
I don't know if this is a doc writing problem or a product problem with how Storybook works (is it even supposed to be a documentation product? I don't know), but so far my experience has been a 0 for 2 with Storybook-based documentation being significantly worse than normal.
Hey, someone from the Storybook team here. We'd love to get actionable feedback about Storybook for documentation. Why is it so much worse that what you're used to? Can you be specific?
Storybook as an official documentation tool is a fairly new idea. They added Storybook Docs pretty recently, which is basically stories that can be written in MDX. It also enables you to document a component's props among other things. IMO, Storybook Docs is on the right path and will become a great documentation tool.
But just using straight up Storybook as documentation, I agree that isn't very good. Whenever I'm just given a random Storybook, my success with that library has been pretty low.
Styleguidist works way better for docs since it’s markdown based and can render numerous “stories” in one page. I find a lot of teams that use storybook end up using features like “knobs” that also require manual interaction. In styleguidist most users just render the components with each possible permutations of props they want to test
I've skimmed that page and I'm not entirely sure I came away knowing what it meant. It's good to see an open source project that can compete with large commercial companies in terms of inscrutable fluff.
Storybook is a tool for organizing UI components. It displays the different components and their variants in a easy to glance UI. Highly recommended if you're working with React, Vue etc
I haven't played around with v6.0 yet, but I've been using Storybook for a while now and it's been great! A lot of the new features aren't relevant to most of the components in the current app I'm working on, but the changes still help reduce a lot of the boilerplate with configuration.
On a related note, I've also started playing with Percy (https://percy.io/) which automatically integrates with Storybook to provide visual diffs of components in multiple browsers. Super useful for quickly validating changes since it can automatically comment on your GitHub PRs when a change is detected. (Not affiliated with Percy at all, just a fan.)
I would love for someone to give examples of how snapshot / storyshot testing actually helped. Always seemed like the dollar-store version of screenshot diffing, with extra baggage kept around the source tree, added maintenance, and seemingly worthless tests.
(No, `expect(<MyComponent />).toMatchSnapshot()` is not a good test).
Although configuration can be a bit problematic at first, the benefits of using Storybook are clear. In my previous job, the typical question of "Is there a component for something like <X>?" was pretty much resolved going to Storybook and check for it.
I wonder how they render the components - I see that the the component previews [1] are rendered inside an iframe, maybe they render the component to string and insert it into an iframe? If so, should be straightforward to implement if the wasm frameworks support render-to-string or equivalent apis.
Storybook has been great working on an incrementally enhanced Vue app. The standard app doesn't really work with HMR and is a PITA when it comes to feedback loop.
Building out components in Storybook with all but the final page integration into the main app has been a great workflow thus far. Some custom API recording/playback utils have even made it a snap to work on larger "connected" components within Storybook. Even just being able to manually verify a bunch of different states after making a refactor by flipping through the component stories is a huge win over doing that in-app.
What was no so great with 5.x is getting it to build like a @vue/cli stock build with sass and full sourcemap support. This took quite a bit of Webpack knowledge of which I already had a fair bit but now have far more. Still the source lines are wrong in error messages for Vue compoments(at least with TypeScript) and I haven't looked too far into why yet.
I know they have put work into making Storybook 6.0 setup for Vue closer to the ecosystem defacto defaults, but I'm not super looking forward to upgrading and having to sort out any issues haha.
This looks fantastic! I just installed it to a test branch on my React/Redux project. Unfortunately after running 'npm run storybook' and clicking any of the 'Configure' options I get a 404 from Github.
Maybe it has to do with my install method? The 'npx sb init' on the get-started page did not work, I had to hunt down the npm package manually and do 'npx -p @storybook/cli sb init'. I'm assuming the sb init listed on the get-started page failed because I didn't have it installed yet? No mention of how to do that on the page though. I'm relatively inexperienced with npm. It does report that I'm running v6.0.4 instead of v6.0.0 though.
Again this looks like it'll be a great help for my work (I tend to struggle with UI work a bit) but by now I should know that when a project promises 'magic simple setup' it is never the case :P
I'll keep playing when I have more time later because I think it will be worth it.
I've played a little with storybooks now included-by-default addon-controls package (designated successor to addon-knobs) and got to say, the API has become worse - especially if you are using TypeScript. It seems the API wasn't created at all with strong typing in mind, and I can't see how they will ever be able to get there. Instead of having strong typed concise functions (number(), color(), etc.) everything now is supposed to be a generic map of string properties, attached to Component.args and the "type" information is a custom map assigned to Component.argTypes (similar to prop-types which are almost obsolete when using TypeScript).
If a SB dev reads this: Please, drop controls, and continue to support the knobs API.
I strangely use storybook with cypress for react native ui testing automation. Also to get multiple screen size on the same screen to check everything is done properly.
I didn't intended to share the repo but as HN is talking about storybook, here it is. Not ready for prod, many todos but the storybook/cypress is demonstrated here.
> The UI component explorer you’ll ️ to use.
> Production-grade component development
Huh? Yes, as a dev I understand what these words mean. But there should be just a tiny amount of exposition of why I'd want to this, on the front page. Not sure why I'd want to, besides neat pictures.
I'm guessing the folks are so deep into this they don't remember what it's like to be a newcomer. Interestingly, the github readme is a bit more descriptive.
We were using it for awhile and it was pretty much a nightmare. Couldn’t use a debugger, hot reloading didn’t work, if an error was thrown you’d have to refresh like 8 times. That being said I think it was v4 or v5. Maybe it’s better now. Eventually I just decided to roll my own for our team.
Yea absolutely. I've used it on a few projects. The workflow is slightly different since the stories on the the simulator/device but, you get all the same benefits.
Yes I use storybook and tailwindcss. Storybook uses webpack so you configure it's webpack config with postcss-loader and then use the tailwindcss plugins; no different than just using tailwindcss and webpack anywhere else.
[+] [-] xrd|5 years ago|reply
Tests show how pieces work together outside of the small confines of a live system. If you don't write tests, you probably aren't considering all the ways you component can work outside of the narrow confines when you, as the author, wrote and tested it. And, you probably can't consider how another developer will use your component and change the environmental code around it.
Storybook gives you all the benefits of tests in that you can pull out pieces and play them back in isolation. I see all the benefits of tests (except that I don't see the results in CI) when using storybook and refactoring. Broken stories tell me a lot about code problems.
Storybook is UI testing done right, we just needed to brand it as a story rather than a test. ;)
Congratulations on a big milestone. This is an incredible piece of software that I use on all my projects.
[+] [-] DrBazza|5 years ago|reply
https://blog.jetbrains.com/teamcity/2020/06/teamcity-ui-how-...
[+] [-] winkerVSbecks|5 years ago|reply
[+] [-] city41|5 years ago|reply
[+] [-] spankalee|5 years ago|reply
[+] [-] ghengeveld|5 years ago|reply
[+] [-] wdb|5 years ago|reply
Would someone run the Storybook pages through something like Cypress?
[+] [-] getpolarized|5 years ago|reply
[+] [-] city41|5 years ago|reply
I am also using Storybook for my game dev. I wrote my own renderer for my engine and so the entities in my game have stories. It makes building new entities and seeing how two entities interact so much nicer and faster.
[+] [-] Kiro|5 years ago|reply
[+] [-] xingped|5 years ago|reply
I don't know if this is a doc writing problem or a product problem with how Storybook works (is it even supposed to be a documentation product? I don't know), but so far my experience has been a 0 for 2 with Storybook-based documentation being significantly worse than normal.
[+] [-] ghengeveld|5 years ago|reply
[+] [-] city41|5 years ago|reply
But just using straight up Storybook as documentation, I agree that isn't very good. Whenever I'm just given a random Storybook, my success with that library has been pretty low.
[+] [-] joshribakoff|5 years ago|reply
[+] [-] andybak|5 years ago|reply
[+] [-] rkwz|5 years ago|reply
Here's a post I wrote about how my team uses it - http://www.sheshbabu.com/posts/how-we-use-storybook-for-docu...
[+] [-] michaelmior|5 years ago|reply
On a related note, I've also started playing with Percy (https://percy.io/) which automatically integrates with Storybook to provide visual diffs of components in multiple browsers. Super useful for quickly validating changes since it can automatically comment on your GitHub PRs when a change is detected. (Not affiliated with Percy at all, just a fan.)
[+] [-] ghengeveld|5 years ago|reply
[+] [-] sthomas1618|5 years ago|reply
Hot take: Delete your snapshot tests. Use Chromatic instead.
[+] [-] mikewhy|5 years ago|reply
(No, `expect(<MyComponent />).toMatchSnapshot()` is not a good test).
[+] [-] thrownaway954|5 years ago|reply
https://www.chromatic.com/
[+] [-] randiantech|5 years ago|reply
[+] [-] gmaster1440|5 years ago|reply
[1] https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor
[+] [-] rkwz|5 years ago|reply
I wonder how they render the components - I see that the the component previews [1] are rendered inside an iframe, maybe they render the component to string and insert it into an iframe? If so, should be straightforward to implement if the wasm frameworks support render-to-string or equivalent apis.
[1] https://5d28eb5ee163f6002046d6fb-paaagcevde.chromatic.com/?p...
[+] [-] Rapzid|5 years ago|reply
Building out components in Storybook with all but the final page integration into the main app has been a great workflow thus far. Some custom API recording/playback utils have even made it a snap to work on larger "connected" components within Storybook. Even just being able to manually verify a bunch of different states after making a refactor by flipping through the component stories is a huge win over doing that in-app.
What was no so great with 5.x is getting it to build like a @vue/cli stock build with sass and full sourcemap support. This took quite a bit of Webpack knowledge of which I already had a fair bit but now have far more. Still the source lines are wrong in error messages for Vue compoments(at least with TypeScript) and I haven't looked too far into why yet.
I know they have put work into making Storybook 6.0 setup for Vue closer to the ecosystem defacto defaults, but I'm not super looking forward to upgrading and having to sort out any issues haha.
[+] [-] raihansaputra|5 years ago|reply
[+] [-] somehnguy|5 years ago|reply
Any of these links: https://i.imgur.com/GwrOwiS.png
Maybe it has to do with my install method? The 'npx sb init' on the get-started page did not work, I had to hunt down the npm package manually and do 'npx -p @storybook/cli sb init'. I'm assuming the sb init listed on the get-started page failed because I didn't have it installed yet? No mention of how to do that on the page though. I'm relatively inexperienced with npm. It does report that I'm running v6.0.4 instead of v6.0.0 though.
Again this looks like it'll be a great help for my work (I tend to struggle with UI work a bit) but by now I should know that when a project promises 'magic simple setup' it is never the case :P
I'll keep playing when I have more time later because I think it will be worth it.
[+] [-] domyen|5 years ago|reply
[+] [-] littlecranky67|5 years ago|reply
If a SB dev reads this: Please, drop controls, and continue to support the knobs API.
[+] [-] shilman|5 years ago|reply
[+] [-] Fr33maan|5 years ago|reply
I didn't intended to share the repo but as HN is talking about storybook, here it is. Not ready for prod, many todos but the storybook/cypress is demonstrated here.
https://github.com/Fr33maan/react-native-ui-real-boilerplate
[+] [-] yboris|5 years ago|reply
[+] [-] kylesuss|5 years ago|reply
[+] [-] mixmastamyk|5 years ago|reply
Huh? Yes, as a dev I understand what these words mean. But there should be just a tiny amount of exposition of why I'd want to this, on the front page. Not sure why I'd want to, besides neat pictures.
I'm guessing the folks are so deep into this they don't remember what it's like to be a newcomer. Interestingly, the github readme is a bit more descriptive.
[+] [-] hsavit1|5 years ago|reply
[+] [-] yawnr|5 years ago|reply
[+] [-] winkerVSbecks|5 years ago|reply
[+] [-] brightball|5 years ago|reply
[+] [-] wingtask|5 years ago|reply
[+] [-] cheez|5 years ago|reply