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.
Oldest comments (92)
Hey all! Thanks for doing this! How did Storybook come together? What's the origin story?
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...
What are common pitfalls devs are currently experiencing with storybook?
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.
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!
Have you guys come across an interesting use-case of storybook?
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.
+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.
Oh that's definitely interesting. Anything to lower the barrier of entry is a big 👍.
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!
+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.
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.
Hello! Thanks for your time.
What commonly-used web development tools or processes is Storybook intended to replace, if any?
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.
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!
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.
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.
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.
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
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!!
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!
Storybookception
Can we extend / customize Storybook components? How easy it is?
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!
Thanks for information
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!
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!
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.
My career in Storybook began from adding a hierarchy feature =) I think it was a life-changing moment in my professional growth =D
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.
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)?
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!
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.
Fav editor? 😁
VS Code with some addons:
code --list-extensions | xargs -L 1 echo code --install-extensionpunch cards and hole puncher.
yes yes, pretty standard stuff for react-native right?
You get lucky if you can work with such advanced technologies when working with React Native.
WebStorm is da real MVP
What's the hardest/worst part about maintaining OSS? How will that change with going full-time?
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.
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.
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.
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...
What's the coolest thing people are doing?
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.
An old one, but I merged about 20 repos into 1, and it looked something like this:
thepracticaldev.s3.amazonaws.com/i...
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?
Arunoda is still an admin on the project and stuff, but he's gone to focus on other things.
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.
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...
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 ;)
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?
Sure, np. Would love to help out.
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
Yes we want to make TypeScript usage with Storybook seamless soon!
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.
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!
No, I don't have anything in place. I just cry myself to sleep after every React-Native update :(
Ow noo! That's sad...
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.
This sounds very cool. If you need any help with this, I would be interested :)
How do people typically “get buy-in” on their team for Storybook, from what you’ve seen?
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.
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!
It improves your code.
What are some common misconceptions about UI development?
"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.
Great answer!