DEV Community

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

Norbert de Langen on July 26, 2018

Hey Dev.to, we’re the core maintainers of Storybook ask us anything. Here today are Norbert de Langen, Michael Shilman, Filipp Riabchun, Igor Davyd...

Read full post

Sloan the DEV Moderator • Jul 26 '18

What's the hardest/worst part about maintaining OSS? How will that change with going full-time?

Igor • Jul 26 '18

Sometimes, I see people asking questions in IMO inappropriate way. For example, requesting things to be fixed or being rude about lack of documentation.

They probably hardly understand what an open source project is =)

So for me, the hardest part is seeing these posts/issues. I always have a strong desire to reply with this great article:

hackernoon.com/i-thought-i-underst...

Daniel Duan • Jul 26 '18 • Edited

It's hard to prioritize different feature requests and bug fixes.

Up until very recently, we are all volunteers, and most of us still are. We take time out of our lives to make sure Storybook works as intended.

Sometimes on GitHub issues, we get requests demanding that a bug be fixed and not ignored or put off until a later date. We mean no harm and many times we do need to prioritize other things over fixing a bug for an edge case. As always, pull requests are welcome.

Norbert de Langen • Jul 26 '18

I've been pretty lucky so far I think. I haven't come across 'the worst' I think.

I've been really happy with it all. I sometimes take breaks, and I know I can because there are other maintainers besides me, we all help each other!

The hardest are the big features and changes, the ones that will be breaking people's setup of disrupt their workflow... We don't want to do any harm, but also don't want to end up with a over-complex codebase with tons of backwards compatibility and hacks.

Mistakes are made and they have to be corrected in software.

The hard part in any software is the clear and friendly communication between humans.

shilman • Jul 26 '18

For me, I hate the guilty feeling when a community member does a lot of work on a contribution and I don't have the bandwidth to turn it around right away. Here's a recent example of a contribution that needs feedback from the community, a partial rewrite of the React Native storybook that shows addons on the device:

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

My biggest hope is that I can have more bandwidth to help shepherd great work like this into the project more quickly.

Nicholas ―M― • Jul 26 '18 • Edited

I remember trying to use storybook in the past, but ran into an issue with installing it because my company's computer has their npm configuration to point to Nexus rather than the public npm repository (I vaguely remember having an issue with how one of the packages were named even after changing a locally scoped npmrc file, but I don't recall if I got to the bottom of what was causing it).

However, I just tried installing it again and now it works ¯\(ツ)/¯ I'm excited to finally get to play around with it, but my lack of experience means I will have to come up with a lame, sort of generic, question on the spot.

What's the one thing you've worked on regarding this tool that you're most proud of? It could be a feature, UI decision, algorithm, anything really!

Norbert de Langen • Jul 26 '18

Hey That's so awesome that it works for you now! If you have any question don't be afraid to jump on our slack and ask for help on our support channel!

I'm proud of the community we've created! I take the time to onboard people unto the project and help them get to know the project.

I've partially responsible for the fact that Storybook now supports more FE frameworks then I can remember off the top of my head. This makes me very happy as well.

I think having a tool like this that's framework-agnostic just makes so much sense!

Daniel Duan • Jul 26 '18

I think a big part of why Storybook is so successful is because of community.

I've definitely done more things on the community side of things rather than the coding part. When I joined in on the Storybook efforts, there weren't really anyone to answer questions, verify bug reports, and deal with the sheer amount of GitHub issues that we get. I started answering as many questions as I know the answers to and fixed bugs when appropriate or urgent. It goes a long way to understanding real user problems and also show users that we actually do care.

Gytis Vinclovas • Jul 26 '18

For me the feature I am proud of is still WIP. It is functionality to display addons in react native app itself instead of depending on the browser. I really hope it kicks of RN part move forward. Since this will allow to more easily use RN Storybook as a UI lib/playground that not only developers but designers/product people can use too.

There more things that need attention in RN Storybook. Better documentation, better ui, story hierarchy, more addons, creating screenshot testing. Also currently RN part of storybook is more or less done without testing, so we have a gap to fill. If more people will be attracted to RN part these things will be implemented a lot faster.

Igor • Jul 26 '18

My career in Storybook began from adding a hierarchy feature =) I think it was a life-changing moment in my professional growth =D

Nick Taylor • Jul 26 '18

Thanks for all your work on this OSS product. A couple of questions...

Is Arunoda still working on Storybook, or is he full-time at Zeit?

I'm curious if you'd be considering creating other default setups for Storybook?

There's Vue, React and Angular. Would you consider something like Preact? I've done it by installing the React Storybook then just adding the preact-compats, and it works pretty well, but maybe for new comers, it could help them out if they show an interest in using Preact.

Also, we use Storybook at work with TypeScript/React and we've used the custom webpack.config to get things working to our liking. I wonder as well in a scenario like this, would you consider a default setup for say TypeScript/React or TypeScript/Angular?

Daniel Duan • Jul 26 '18 • Edited

A big advantage to Storybook is that we support many different frameworks and configurations. It is also a lot of work and time to develop, test, and support the full customization of every configuration possible on every platform.

We've definitely discussed this and the solution is perhaps allow some less popular combinations of frameworks and configurations to owned and maintained by the community. There are some work we have to do to modularize these configs to enable this.

shilman • Jul 26 '18

Arunoda is full-time at Zeit, but he's still a project VIP and has the most commits of any human involved in the project (and I don't think any of us are going to catch up with dependencies.io at this point):

github.com/storybooks/storybook/gr...

Nick Taylor • Jul 26 '18

He's super nice and helpful. He read over a presentation I did on Storybook a while back. If you're interested, it's at story.iamdeveloper.com. Probably a little out of date though ;)

Norbert de Langen • Jul 26 '18

So we're already kinda compatible with Preact via the method you just described.

I wonder how many preact users are there that would not be comfortable with the needed changes, do you recon it's worth the effort? (including maintenance).

One thing one of our maintainers Igor Davydkin came up with recently was the concept of 'presets' and examples you can clone to get started.

I think this would help in your use-case, as at the very least the process of adopting storybook for Preact is in that case very well documented, because there's a runnable example available.

We could add a Preact version to our CLI too. sounds like a very good first-pr, wanna help?

Nick Taylor • Sep 4 '18

I haven't had time to look into this yet, but I documented the process of how to do it for the time being by installing React first as I mentioned in another comment.

Setting up Storybook for Preact

Nick Taylor

#preact#storybook#javascript#ui

Nick Taylor • Jul 26 '18

Sure, np. Would love to help out.

Norbert de Langen • Jul 26 '18

Yes we want to make TypeScript usage with Storybook seamless soon!

Norbert de Langen • Jul 26 '18

Arunoda is still an admin on the project and stuff, but he's gone to focus on other things.

Eka • Jul 26 '18

Thank you for your hard work with Storybook and for doing this AMA!

Have you got any recommendations / example use case of using Storybook to create a single source of truth for same components in multiple language stacks (eg. React and Rails ERB or React and plain HTML)?

Norbert de Langen • Jul 26 '18

Right now you need to run multiple Storybooks if you want multiple frameworks at the same time.

We think that when we're going to work on some performance improvements in the future we can likely make it possible to load components from multiple frameworks in 1 Storybook!

The docs-view I'll be working on in the next few weeks, will definitely help as well to document all sorts of other things besides components!

shilman • Jul 26 '18

The current version of Storybook only supports one view layer at a time. So we have @storybook/react @storybook/vue @storybook/angular etc. Norbert prototyped a next-generation architecture that supports multiple view layers at once, so this may get a lot easier in the near future, but it's a pretty big change so we're taking our time to do it right.

Ben Halpern • Jul 26 '18

What’s it like developing an open source project with such a UI component itself, must have challenges that are different from the typical more headless tool.

Norbert de Langen • Jul 26 '18

Yes it's a challenge in the design-department for sure.

Storybook the app can only look boring and subtle, because the more 'distinct designed' it is, the harder it will be to combine it with whatever components storybook is supposed to show off.

And ultimately those components are the real importance to users, so storybook needs to 'lay low'.

We're looking at improving it though and also allow more customisation. I recently implemented theming, so you can now change the colours to what you want.
More customisation is coming though, soon!

For an OSS it's actually surprisingly hard to find help in the design department. Developers know opensource and so it's much easier to get software development help, then design help.

And I (personally) can use all the design help I can get.

Ben Halpern • Jul 26 '18

Yeah, I agree on those things. I asked the question because I feel like we're going to be embarking on this sort of thing in the not-to-distant future

The dev.to codebase will go open-source on August 8

Ben Halpern

#meta#opensource

I feel like customization winds up being more important in OSS because there's a shared sense of ownership, and the bugs introduced by customization hiccups are easier to deal with via the community. But definitely agree, that design help can be the hardest to come by. I find people (politely) don't want to intrude in this arena sometimes, or don't know if they have permission.

Definitely following the project for cues. It's very clear that design is part of what you do well though!!

shilman • Jul 26 '18

Fortunately Storybook is about making UI development easier, so we have Storybooks for our internal components and get a lot of testing "for free" using this setup. We should document our setup better to help other OSS projects move faster and with more confidence!

Ben Halpern • Jul 26 '18

Storybookception

Liana Felt (she/her) • Jul 26 '18

Hey all! Thanks for doing this! How did Storybook come together? What's the origin story?

Norbert de Langen • Jul 26 '18

Storybook started as an internal project in a start-up called Kadira. Supporting React and later React-Native, it became quite popular (~7k github stars).

It was mostly maintained by the 2 top engineers, but was open source and saw a community start to develop. Quite a few companies you may have heard about started to use it.

But after about a year, Kadira ended up shutting down and the 2 maintainers went to focus on other ventures, leaving the project unmaintained.

A few community members (me included) offered to help out and so the new Storybook team was created. We had some online and even offline meetings since then!

Storybook 3.0 was a community effort and we've been growing the community and project ever since, to over 26k github stars now!

We're real close to releasing 4.0 with a ton of improvements and new frameworks we'll start supporting!

Here's a origin story is a blogpost:
medium.com/storybookjs/the-storybo...

And very recently 2 of the maintainers of storybook have decided to join a start-up which is Storybook focussed and start work on storybook full time!
Truly the next chapter of the storybook epic:
medium.com/storybookjs/storybook-t...

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!

Mac Siri • Jul 26 '18

Have you guys come across an interesting use-case of storybook?

Dan Green • Jul 26 '18

Not sure if you would call it interesting, but at Wave storybook has made it really easy for designers who code to collaborate with engineers. By working in storybook they don't need to get a whole environment running (20+ docker container, etc). It also helps to promote separation of concerns by giving the immediate, tactile benefit of easily being able to work on UI components in storybook.

Dominic Nguyen • Jul 26 '18

+1 This is what we do at Chroma too. I find that it helps scale the amount of complexity a designer or dev is faced with at a given time. That makes in turn makes it much more straightforward to build UI components.

shilman • Jul 26 '18

Perfect answer. Storybook opens up the UI development process to a broader range of collaborators. Have seen lots of teams using it to do review and signoff, not just development. We plan to explore this a lot more in future iterations of the project!

Chandler Roth • Jul 26 '18

+1 For sure — we do this at Enok as well. Our team collaborates with a lot of startups + mid-size companies that need to maintain large repositories of components, and Storybook has been the best "component library browser" we've used.

Right now we're exploring integrations with React Storybook + Sketch and other product design tools. Really want to tighten up Design System automation + component reuse. Might do a blog post about those results soon.

Mac Siri • Jul 26 '18

Oh that's definitely interesting. Anything to lower the barrier of entry is a big 👍.

shilman • Jul 26 '18

Storybook's "stories" are pretty general-purpose, and I like to see people overloading it with whatever they find useful. A lot of Storybooks jam a styleguide into a set of stories, for example Lonely Planet's storybook:

lonelyplanet.github.io/backpack-ui...

I've also done weirder stuff, like use Storybook to document a web scraper on an internal project. Have not seen other people doing stuff like this in the wild yet, but expect to see more weird stuff as the tool gets more popular.

Mandar Badve • Jul 26 '18

Can we extend / customize Storybook components? How easy it is?

Norbert de Langen • Jul 26 '18

You can theme the Storybook UI, and you can extend storybook using addons!

Both of those things are super easy!

Customising the manager to the degree of changing the components in the UI isn't possible right now. I will focus on making more extention points, so more addons can do all sorts of crazy stuff!

Mandar Badve • Jul 26 '18

Thanks for information

Ben Wolman • Jul 26 '18

Hello! Thanks for your time.

What commonly-used web development tools or processes is Storybook intended to replace, if any?

Norbert de Langen • Jul 26 '18

For me personally it replaces a TON of developing inside the App itself. It's will not replace that workflow ever I think, but it's a great companion.

Your App often is just not well suited for exploring components and developing them.

That being said, a lot of people use Storybook for documentation.
So it can replace a whole bunch of documentation tools. In fact this is one area I want to expand Storybook in the coming weeks.

I'll be working full-time and make a fantastic docs-view inside storybook itself!

Daniel Duan • Jul 26 '18 • Edited

I think the exciting thing about Storybook is that it doesn't really replace any one thing.

As frontend architecture gets more and more complicated and modularized, there has been a need to develop components independently and perhaps publish and demo as a reusable NPM package.

Component package maintainers previously had to spend time to setup their own development environment, mess with webpack, and structure the app to display different components in a meaningful way. They then have to figure out a way to create a static build to create a demo.

Storybook is able to provide all those features without starting from scratch, saving developers time and effort.

Dan Green • Jul 26 '18

For Wave, we have many important components that are only visible in the middle of a process that is short lived and time consuming to reproduce (i.e. a loading screen that only shows while a user is having their payment account setup). Before storybook, we didn't have a good way to work on these components and were forced to temporary hacks in order to make them visible. Now, with storybook we have an isolated place to easily work on them, which has the bonus feature of being easily accessible for designers and PMs. It also makes it really easy for us to show of these states in sprint demos.

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.

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!

Jess Lee • Jul 26 '18

What are common pitfalls devs are currently experiencing with storybook?

Daniel Duan • Jul 26 '18 • Edited

I think there are a few scenarios where people experience frustrations with Storybook

New to Storybook:

Setup: Getting started can get quite complex when it comes to webpack and babel config, especially for users who have components in an existing codebase. Adding support for things like LESS, TypeScript, etc. can be pretty complicated to someone who isn't familiar with frontend build systems. We've been discussing ways to mitigate this, through better documentation, presets, etc.

Advanced users:

Documentation - Storybook has been designed as a development environment first and a playground second. I've been experiencing an increasing need for Storybook to play the role of documentation as well. It makes a lot of sense to keep documentation and code as close as possible, and using Storybook to do this has been a point of discussion during our roadmap meeting for a while.

Customization - We recognize the need to customize the Storybook layout, theme, and everything in between. Storybook can be a branding or component playground for many organizations, and it makes a lot of sense for the rest of the Storybook interface to have the same feel and experience. The theme feature coming in 4.0 is a good first step towards that.

Norbert de Langen • Jul 26 '18

One pitfall I hear about is that people think you need to start using storybook right from the start.
That's not true, it's very much possible to start using storybook long after the start of your project, and gradually start using it for new components.

Then apply boy-scout rule and whenever you solve an issue in an components write a component-story for it, so it becomes visible / reviewable.

TIP: deploy your storybook on every commit / PR or use Chromatic!

Jess Lee • Jul 26 '18

Fav editor? 😁

Norbert de Langen • Jul 26 '18

VS Code with some addons:

code --list-extensions | xargs -L 1 echo code --install-extension

code --install-extension IBM.output-colorizer
code --install-extension PeterJausovec.vscode-docker
code --install-extension asvetliakov.snapshot-tools
code --install-extension ban.spellright
code --install-extension bungcip.better-toml
code --install-extension buster.marko-beautify
code --install-extension christian-kohler.npm-intellisense
code --install-extension christian-kohler.path-intellisense
code --install-extension codezombiech.gitignore
code --install-extension CoenraadS.bracket-pair-colorizer
code --install-extension dbaeumer.vscode-eslint
code --install-extension donjayamanne.githistory
code --install-extension dzannotti.vscode-babel-coloring
code --install-extension eamodio.gitlens
code --install-extension esbenp.prettier-vscode
code --install-extension file-icons.file-icons
code --install-extension flowtype.flow-for-vscode
code --install-extension formulahendry.auto-close-tag
code --install-extension formulahendry.auto-rename-tag
code --install-extension glen-84.sass-lint
code --install-extension HookyQR.beautify
code --install-extension kamikillerto.vscode-colorize
code --install-extension mathiasfrohlich.Kotlin
code --install-extension mikestead.dotenv
code --install-extension mitchdenny.ecdc
code --install-extension ms-python.python
code --install-extension ms-vscode.Go
code --install-extension octref.vetur
code --install-extension paulmolluzzo.convert-css-in-js
code --install-extension pcanella.marko
code --install-extension rbbit.typescript-hero
code --install-extension richie5um2.vscode-sort-json
code --install-extension robertohuertasm.vscode-icons
code --install-extension ryu1kn.partial-diff
code --install-extension Shan.code-settings-sync
code --install-extension shinnn.stylelint
code --install-extension SonarSource.sonarlint-vscode
code --install-extension WallabyJs.quokka-vscode
code --install-extension wayou.vscode-todo-highlight
code --install-extension zhuangtongfa.Material-theme

Daniel Duan • Jul 26 '18 • Edited

punch cards and hole puncher.

Norbert de Langen • Jul 26 '18

yes yes, pretty standard stuff for react-native right?

Gytis Vinclovas • Jul 26 '18

You get lucky if you can work with such advanced technologies when working with React Native.

Igor • Jul 26 '18

WebStorm is da real MVP

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

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.

K • Jul 26 '18

This sounds very cool. If you need any help with this, I would be interested :)

Norbert de Langen • Jul 26 '18

Are you using Chromatic by any chance?

If you already have Visual Regression is place, you can have addon-storyshots make screenshots of all component-stories for you too!

K • Jul 26 '18

No, I don't have anything in place. I just cry myself to sleep after every React-Native update :(

Norbert de Langen • Jul 26 '18

Ow noo! That's sad...

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!

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!

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.

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!

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!

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

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!

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.

Liana Felt (she/her) • Jul 26 '18

What's the coolest thing people are doing?

shilman • Jul 26 '18

Norbert is starting work on a docs view for Storybook that will allow people to integrate stories more tightly with the rest of their documentation. This is going to change how people use Storybook--not just for component development and testing but also for showing them off beautifully!

I'm also really psyched about this change for Storybook for React Native:

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

It's a big departure for the project, since currently all of the web view layers share a lot of the same infrastructure, and this pulls RN even further out of the fold. But it's what a lot of RN users (at Artsy, Reactotron, Wix, Squarespace?) are doing anyway, so I think it will be really cool once we figure out how to get it integrated cleanly.

Norbert de Langen • Jul 26 '18

An old one, but I merged about 20 repos into 1, and it looked something like this:

thepracticaldev.s3.amazonaws.com/i...

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?

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