Norbert de Langen

Posted on Jul 26, 2018 with shilman and Daniel Duan

We're the core maintainers of Storybook, Ask Us Anything!

#ama #javascript #webdev #storybook

Hey Dev.to, we’re the core maintainers of Storybook ask us anything. Here today are Norbert de Langen, Michael Shilman, Filipp Riabchun, Igor Davydkin, Daniel Duan, and Tom Coleman. We’ll be answering questions from 2pm ET on.

Storybook is the most popular tool for developing UI components. The open source project has grown to over 450 contributors, 26k GitHub stars, and 1M npm downloads/month. It’s now used by teams at Dropbox, Slack, Airbnb, Squarespace and many more. Furthermore, we just announced that Storybook has full-time maintenance.

Common Questions
Why should you consider Storybook?
Storybook helps you develop components in isolation. This is handy because it enables you to mock hard-to-reach states and edge cases while developing the component. In practice, you end up building durable components much faster.

What view layers does Storybook support?
React, React Native, Vue, Angular, Polymer, Mithril, Marko, raw HTML, and more soon.

How do you try Storybook?
Install it here

Are there any examples online?
Airbnb has a lovely datepicker. More examples here.

What’s a good way to learn Storybook?
The Storybook Tutorial is a great start.

Latest comments (92)

Arun K • Apr 25 '20

Hi i am into react coding since past few months. Storybook seems to be good for isolated components for both development and testing. However i am just wondering how do we build entire application.
Say i have Shopping cart application.
Should i consider one of the story to be complete development
and rest of the stories to be granular components

like,
Main App

Button
Form
Products
Cart
Checkout

robinwatson • Sep 20 '19

Hey Norbert, whats the best way to mock Vuex data or local data in our stories?
Some components have quite alot of functionality and its proving to be tricky to mock that data while keeping the story small in size.

Thanks for working on this full time!

Dominik Richner • Jul 10 '19

Hi there, i have a question. How do you handle the versioning of the storybook? I want to use it in many projects as single source of truth but im afraid that i can break old projects. I read about an approach to create an NPM package but i cant figure out if this is the way to go.

ydagana • Jul 3 '19

Hello and thank you for the great work on Storybook, I'm currently integrating it with a non traditional angular (nrwl/nx) project, hot reloading is not working out of the box and I guess I need to customize the webpack configuration, my question is where can I find a standard storybook webpack configuration for Angular CLI so I can fiddle with it?
Thank you!

eda29 • May 2 '19

HI! I have a question about Storybook in Angular: Is Storybook a style guide, Component testing, API reference and more all in one?

Gustavo Garsaky • Jul 27 '18

As a JavaScript project scale, debug it becomes harder. So, if you start a large project, do you prefer Typescript or Flow? Why?

Norbert de Langen • Aug 1 '18

I seriously don't know.

Typescript seems to be more popular and so from a community / onboarding perspective I think it makes more sense. I've used Flow in the past and it helped a lot, but there was also a cost associated with maintaining it.

My recommendation would be to try to to keep the complexity as low as possible. I think static typing can help deal with high complexity but at the same time it introduced some. So only you can decide if the trade-off makes sense for you, your team and the project.

Optimise for feedback and confidence, type-systems can help.

Nick Taylor • Jul 27 '18

Thanks again Norbert and the whole team for taking the time to answer our questions today. Looking forward to helping add Preact to the CLI! Is there an issue for it in the repo, or should I create one?

Norbert de Langen • Aug 1 '18

Hey Nick!

I think it could be relatively straight-forward!

The code for the CLI is here:
github.com/storybooks/storybook/tr...

And the change would essentially be to add detection for the 'preact-project', here's the detect code:
github.com/storybooks/storybook/bl...

And then code a 'generator' for it. We have a few generators already:
github.com/storybooks/storybook/tr... so you can use those as an example!

Last but not least, we should add tests!
The CLI is tested by literally running the CLI on 'fixtures' folders, and assert the file-changes it makes are in occurrence to stored snapshots.

Josh Callender • Jul 26 '18 • Edited

Hey Norbert / Shilman! First of all, thank you for all the work that y'all are doing on Storybook!

I'm curious if it's possible to restyle or customize the storybook UI? I know you were working on being able to theme storybook, but what about additional customizations? Being able to add logos etc. I'm hoping to open source / make my storybook publicly available, but my company is asking me to make it more "on brand."

Also, how's 4.0 coming along??

shilman • Jul 26 '18

Hey Josh! Late to the game but we've merged the theming PR into the master branch, so you can customize a lot better now than you could before. This is available in the latest 4.0-alpha. The feature needs more documentation, but there are theming examples in the official-storybook example:

github.com/storybooks/storybook/pu...

We're still waiting on a few more big changes for 4.0, but so far the stuff that's in there is feeling pretty solid. Please give it a whirl and let us know how it's looking for you!

Folashade O • Jul 26 '18

I've downloaded a few open source storybook repos from other companies, and worked on storybook repo at mid-size companies. They seem to all have the same problem of keeping start-up and HMR (Hot Module Reloading) time down. Any work planning to increase the performance of storybook applications?

It seems like scale is an avenue where storybook has more opportunity to grow! Especially if you're interested in loading components from multiple frameworks into one Storybook application.

Nick Taylor • Jul 26 '18 • Edited

That could be an issue related to how big the project is, and that is probably more webpack related.

We have large TypeScript/React projects and ended up using Happy Pack and fork-ts-checker-webpack-plugin to speed up things.

I was able to bring an initial build time down from 2 minutes to 30 seconds with subsequent super fast HMR thanks to these great projects.

So thanks to custom webpack configs in Storybook, we were able to apply these plugins to Storybook as well.

Norbert de Langen • Jul 26 '18

Wow, that looks cool! Could we use that by default do you think?

Nick Taylor • Jul 26 '18

You probably could. It's pretty minimal webpack changes. You include a plugin/loader and you're good to go. Here's the current TypeScript/React project I'm working on's webpack config for Storybook

/**
 * This extends the default webpack configuration used in storybook.
 */
const { resolve } = require('path');
const ForkTsCheckerWebpackPlugin = require('fork-ts-checker-webpack-plugin');
const HappyPack = require('happypack');

module.exports = {
  devtool: 'cheap-module-source-map',
  resolve: {
    extensions: ['.ts', '.tsx', '.js'],
    alias: {
      types: resolve(__dirname, '../types'),
      helpers: resolve(__dirname, '../src', 'helpers'),
      services: resolve(__dirname, '../src', 'services'),
      reducers: resolve(__dirname, '../src', 'reducers'),
      actions: resolve(__dirname, '../src', 'actions'),
      components: resolve(__dirname, '../src', 'components'),
      routes: resolve(__dirname, '../src', 'routes'),
      utilities: resolve(__dirname, '../src', 'utilities'),
      assets: resolve(__dirname, '../src', 'assets'),
    },
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        loader: 'happypack/loader?id=ts',
      },
    ],
  },
  plugins: [
    new HappyPack({
      id: 'ts',
      threads: 2,
      loaders: [
        {
          path: 'ts-loader',
          query: { happyPackMode: true },
        },
      ],
    }),
    // Handles type  checking on another thread.
    new ForkTsCheckerWebpackPlugin({
      async: false,
      tslint: true,
      checkSyntacticErrors: true,
    }),
  ],
};

Norbert de Langen • Jul 26 '18 • Edited

Yes Yes, absolutely.

Performance enhancement is #3 on the list of my priorities:

Support other maintainers, onboard new maintainers, grow the community, support users
Documentation view
Performance

During the documentation view epic, I'll make storybook a lot more extensible as well!

rouzbeh • Jul 26 '18

Are there plans to have any automation in building stories similar to Styleguidist? I really want to use Storybook but given the size of the project I recently jumped into it really seems like a sizable effort would need to be made to get going...

Norbert de Langen • Jul 26 '18

Possibly we could look at type-definitions or propTypes and create stories from that.

That would we a pretty cool feature to have indeed!

We're also playing around with the idea of a new story format that isn't tied to storybook per see, and could be re-used for unit tests and other tools, that's likely coming this year!

Wilfredo Pérez • Jul 26 '18

Was diffucult integrate all the frameworks?? because you support Angular, React Vue and others right now.

Thanks alot for this, although I've not too much using it but it's awesome.

Daniel Duan • Jul 26 '18

We definitely rely on the community to support Angular, Vue, etc. and this will still be our policy going forward.

In terms of the engineering efforts, we've extracted all the shared code into their own separate packages. We have at least one person on the maintainers list who is well versed in the framework and can contribute or review pull requests.

Igor • Jul 26 '18

In the beginning, it was a bit challenging, but we moved most of the common parts to the "core" package, and now it's quite easy to add support for new frameworks.

Norbert de Langen • Jul 26 '18

Right, when we were just starting out I just copied the React version and made modifications to make it work for Vue.

That was pretty successful, and after Angular was build the same way, we needed to start refactoring and remove duplicated code.

Moe • Jul 26 '18

How do y'all make money and find the resources you need to keep this project afloat?

shilman • Jul 26 '18

We have an open collective to support the project, and are getting donations from a bunch of big users like Airbnb, Facebook OSS, Xebia, Tipe, and Algolia, as well as from commercial tools built on top of Storybook like Chromatic, Percy, and Applitools:

opencollective.com/storybook#

We plan to use the funds to promote the project and help organize/educate the community and will document that as part of the open collective.

On the personal side, Norbert and I have both joined Chroma to make more time for Storybook:

medium.com/storybookjs/storybook-t...

Peter Kim Frank • Jul 26 '18

What are some common misconceptions about UI development?

Daniel Duan • Jul 26 '18 • Edited

"Frontend is easy"

Frontend interfaces have gotten more and more complex and so has the need for systems and architecture within the frontend. Many companies have large teams of 50+ people working on a single frontend system and that creates a lot of communication, management, and architectural challenges. This means that frontend developers on larger projects focus on very specific issues like build systems and webpack, performance, tooling, etc.

One thing that came out of this focus is a recent trend of companies discussing "Design Systems" and creating custom tooling around the shared Design <-> Engineering standards as a single source of truth. What a component is to an engineer may be totally different from what a designer thinks it is. In Sketch, it is easy to drag and drop a component, place it inside another component, and imagine that it works. But on the engineering side, these seemingly small changes can create lots of unnecessary work that can be prevented if the designer understands the engineering constraints. Communicating those constraints is hard.

I don't know what form of tooling or communication framework this will ultimately look like. Airbnb is working on importing React components into Sketch and creating drag and drop compilers to generate components on different platforms. InVision is creating a tool for designers to create branding and style guides with individual components. There are some pretty exciting developments in this area.

Norbert de Langen • Jul 26 '18

Great answer!

Ben Halpern • Jul 26 '18

How do people typically “get buy-in” on their team for Storybook, from what you’ve seen?

Daniel Duan • Jul 26 '18 • Edited

It improves your code.

Modularizes components and makes it easy to reuse and distribute
Isolates components from parent environments so components can be worked on separately and versioned independently
Enables component level testing for better test coverage

shilman • Jul 26 '18

Storybook is really easy to adopt incrementally. You can add it to your project in 30 seconds, write stories for one component at a time, and get a feel for the benefits right away without having to invest a lot. Developers love it because because it's the best way to develop and test components in isolation. Designers love it because they can inspect live components without having to run an entire build on their local machine.

Ben Halpern • Jul 26 '18

What I found nice is that I was able to say “yeah, I agree we can get this integrated”, without having to immediately adopt it on day one myself. Way easier to say yes in this way.

Big ups to @nickytonline for introducing it to our project!

K • Jul 26 '18

Haha, I just came across it few days ago, wanted to blog about it, because it seems to solve one of my main pain points, visual regression.

Gytis Vinclovas • Jul 26 '18

One of the future ideas I have is to integrate storybook with detox (e2e testing for React Native). It would allow to create screenshot testing or do even more complex things for the stories. I already had a small POC, I will continue to work on it some time in the future.