Storybook 6.0 your new favourite tool for front-end development | Hacker News Reader

Storybook 6.0 your new favourite tool for front-end development

medium.com

168 pointswinkerVSbecks63 comments

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

Check out Chromatic if you want CI for Storybook.

Jetbrains use Storybook and capture screenshots of the UI and automatically (visually) diff them.

https://blog.jetbrains.com/teamcity/2020/06/teamcity-ui-how-...

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.

It actually pairs well because this is a SaaS service run by the maintainers of Storybook.

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.

Is any of that system open source? It would be interesting to see the difference between that and storybook.

No, and I'm not sure it would be. It's a very small subset of Storybook, and offloads all dependency management and build aspects to the build system of the monorepo (like Bazel).

The story format is a combination of a small container for story templates and knob definitions, then a custom element that can render stories. Maybe we could release that on an as-is basis.

Hi Justin. I'd be very interested in seeing that custom element! If you're able to work to get that open sourced that would be amazing. (Interested as a user of both litelement and bazel)

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.

Yes, it can

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?

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.

Do you mind explaining more about how you use Storybook for your game entities?

I will eventually write a blog post about it. But in the mean time this tweet give the overall gist

https://twitter.com/mattegreer/status/1244012323976515584

I made it so I can create a game scene out of ASCII characters, and then I can also tweak the scene and/or entities within the scene with code if needed (but it almost never is). Then the Storybook renderer instantiates a canvas and the game engine, and populates it with the scene.

Making your own renderer is pretty much totally undocumented. I took the React renderer as a basis (https://github.com/storybookjs/storybook/tree/next/app/react) and tweaked from there. I have spoken with Michael Shilman about this and there are plans to document it and make it easier to do, not sure where they are on that though.

It's so undocumented and uncharted I'm not even sure if "renderer" is the right name for these things.

There's documentation for creating your own framework integration now: https://storybook.js.org/docs/react/api/new-frameworks

Oh awesome! Thanks for adding that, I will definitely be making use.

Storybook is pretty flexible if your work can render in a web browser. We recently rebuilt Chromatic's CLI and as an experiment decided to write stories to record and regression test the many states the CLI can be in. We were able to use Storybook as we used a React based library to output to STDOUT.

We're loving the result so far as it makes it really easy to answer questions like - "what will the user see if they have passed flag X but their workspace is in state Y and Z their build has failed to upload". You can check out the Storybook here:

https://5d67dc0374b2e300209c41e7-kgfpdfjsbm.chromatic.com/?p...

If I was building a game I'd find the component driven methodology (https://www.componentdriven.org) with a component explorer like Storybook or something specific to the game dev environment ideal because of how many hard to reach key states games have that could easily break as a result of code changes somewhere else.

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.

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.

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?

Hey there! I just say this as an anecdote of someone who has been a consumer of two teams that use Storybook, so I have not used Storybook myself.

That said, the biggest problem I've had is the "living code samples". I'm not sure of the exact name, but the feature where you display a component on the page and click the Show Code button to do a flip and see the code that drives it. The libraries we use that use Storybook are fairly complex, so I'm not sure how much that has something to do with it, but not a single "living code sample" has been a self-contained example.

When I look at code samples for libraries, I expect I should be able to more or less copy/paste the code directly into my application and it should just work (once the dependencies are added). This includes things like import statements as well so I know where things are being imported from in the case of multiple import paths for a library. Unfortunately, instead it's been lots of wrappers and helper functions in the storybook examples and I've only gotten vague answers of "storybook limitations" as to why they're not totally self-contained copy-and-paste-able.

I'll see if I can speak with one of the engineers at work to ask more about the limitations he meant when I complained about the examples not being self-contained and get back to you on that.

I hope this makes sense and is actually helpful!

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

This is totally possible with Storybook Docs. It also supports markdown (MDX).

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

Here's a post I wrote about how my team uses it - http://www.sheshbabu.com/posts/how-we-use-storybook-for-docu...

That's much clearer. I wish someone like you had written the original article.

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

If you like Percy, check out Chromatic which is similar and actually built by the same people who maintain Storybook.

Thanks for the pointer! Somehow I hadn't heard of Chromatic. I'll have to check it out.

In addition to Storybook, their Chromatic product is amazing.

Hot take: Delete your snapshot tests. Use Chromatic instead.

when suggesting a complementary or competing tool... it is best to add a link to it.

https://www.chromatic.com/

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

I've never understood snapshot tests either. My team tried them early on but abandoned them quickly. Whats the value in them?

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.

Really enjoyed using the tool when I was working on a React codebase, would love to see support for Blazor[1] at some point!

[1] https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

Yes, that would be awesome!

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

Here's how to add a new framework: https://storybook.js.org/docs/react/api/new-frameworks

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.

Interested on the incrementally enhanced part of your comment. Are you using Vue with the script tags and using .vue components?

Essentially. We build out a bunch of separate entry points(pages in @vue/cli language) in two separate groups; components and pages. Both serve the same purpose in that the entry point is responsible for wiring the Vue components into the legacy page. Components may be included on every page or a number of pages, "page" entry points are meant to be included on certain routes.

They are brought in via script tags in the legacy web framework.

What kind of webpack config are you using? Something similar to Laravel Mix?

I just found out about Laravel Mix a month or so ago so I'm not sure. They are customized @vue/cli configs:

Main UI: https://github.com/rundeck/rundeck/blob/main/rundeckapp/grai...

Component lib: https://github.com/rundeck/rundeck/blob/main/rundeckapp/grai...

Storybook: https://github.com/rundeck/rundeck/blob/main/rundeckapp/grai...

Thank you for sharing!

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.

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.

Fixing now, thanks for bringing it to our attention

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.

If you're interested in maintaining knobs, please jump on our Discord! https://discord.gg/UUt2PJb

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.

https://github.com/Fr33maan/react-native-ui-real-boilerplate

FYI: https://storybook.js.org/ eats 100% of my CPU when I'm on the website!

Thanks for the heads up! We just merged a fix for this so it should be fixed shortly.

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

anyone out there using Storybook with React Native? I'm curious to hear if it is as useful as Storybook for web is.

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.

Can you elaborate on the workflow you use? The web storybooks can be hosted which makes it easily shareable with anyone but the RN version cannot be shared easily - we need to build the storybook and run it inside the simulator.

The distribution mechanism is different. The Stories can't be hosted on the web but, you can embed them in the app itself and give people access to it with a dev mode flag.

https://github.com/storybookjs/react-native#optionally-run-s...

This is if your components are in the app’s codebase itself and not in a shared components library. The workflow there gets a bit messy IMO since you probably need to then maintain an entirely separate RN app just for the storybook in that component library’s codebase, which leads to a decent amount of redundant work when upgrading RN versions.

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.

Can it work with TailwindCSS?

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.

I have a Jupyter notebook that does this. Not sure I see the value of this tool but I guess packaging it up nicely is the value.

Reply on news.ycombinator.com