What is React Storybook?
Who uses React Storybook?
React Storybook Integrations
Here are some stack decisions, common use cases and reviews by members of with React Storybook in their tech stack.
Here are some stack decisions, common use cases and reviews by companies and developers who chose React Storybook in their tech stack.
React Storybook is one of the most favorite tools in our #Frontend team. When we start a new frontend part, we install storybook at first and create visual React components based on our design with usage stories in Storybook. So, we get a live version of design quickly and can sync with designers before developing of whole app and configure Webpack.
The tool we use for editing UI is React Storybook. It is the perfect place to make sure your work aligns with designs to the pixel across breakpoints. You get fast hot module reloading and a couple checkboxes to enable/disable browser features like Flexbox.
The only tricks I apply to Storybook are loading the stories with the mock data we’ve extracted from the API. If your mock data really covers all the various various possible states for your UI, you are good to go. Beyond that, if you have alternative states you want to account for, perhaps loading or error states, you can add them in manually.
This is the crux of the matter for Storybook. This file is entirely generated from Yeoman (discussed below), and it delivers the examples from the Alps Journey by default. getSectionsFromJourney() just filters the sections.
One other hack you’ll notice is that I added a pair of divs to bookend my component vertically, since Storybook renders with whitespace around the component. That is fine for buttons or UI with borders, but it’s hard to tell precisely where your component starts and ends, so I hacked them in there.
Since we are talking about how all these fabulous tools work so well together to help you be productive, can I just say what a delight it is to work on UI with Zeplin or Figma side by side with Storybook. Digging into UI in this abstract way takes all the chaos of this madcap world away one breakpoint at a time, and in that quiet realm, you are good down to the pixel every time.
To supply Storybook and our unit tests with realistic mock data, we want to extract the mock data directly from our Shared Development Environment. As with codegen, even a small change in a query fragment should also trigger many small changes in mock data. And here, similarly, the hard part is tackled entirely by Apollo CLI, and you can stitch it together with your own code in no time.
Coming back to Zeplin and Figma briefly, they're both built to allow engineers to extract content directly to facilitate product development.
Extracting the copy for an entire paragraph is as simple as selecting the content in Zeplin and clicking the “copy” icon in the Content section of the sidebar. In the case of Zeplin, images can be extracted by selecting and clicking the “download” icon in the Assets section of the sidebar.ReactDesignStack #StorybookStack #StorybookDesignStack
Our front-end team decided to use React Storybook for our primary React development environment. It allows us to write components in isolation without the need to fire up our Rails stack. When writing components in isolation; you can focus on styling, behaviour and prop design. It forces you to think about how your component is going to be used by others. React Storybook uses webpack and hot module reloading under the hood. This allows us to write components very quickly since it hot reloads in the browser as you code!
The knobs add-on is great for testing different edge cases for the component props. There is even an add-on that will auto-render and snapshot your components with every prop permutation allows by your defined knobs. These snapshots can then be part of your CI testing.
We have a step in our build process that publishes a static React Storybook site on our production server. This allows our entire team to interactively test components before they are integrated into larger features. Once we are happy with our components in isolation, we integrate them into connected feature components which are wired up to Apollo and GraphQL to provide the data and state.
There are heaps of React Storybook add-ons to checkout. If you aren't using it, you should be.
Happo.io is a straight up life-saver. It is the only screenshot testing tool I’ve ever used, so I would not be sophisticated enough to compare it to alternatives, if there are any, but the essential idea is that you push code, and it goes off and renders all the components in your PR, comparing it with the version on master.
This means if you edit a component like
<Input /> it will show you the impact on components that use Input, including the Search Bar you accidentally modified. It. Is. Fabulous.
How many times did you think your change was contained only to discover that ten other teams started using what you built, and your change breaks three of the ten? Without Happo, you might not know.
Until lately, the only downside with Happo was that our React Storybook variations (the input to the screenshot testing process) did not always reflect reliable data adequately. Now that Storybook is leveraging API data, we can feel much more confident. Plus, as our demo explores, it is automatic. If you add a field to the query and then the component, Happo will automatically post the diff to your PR, letting the engineers, designers, and product managers sitting next to you see the visual consequences of the change you have made.
We use Jest because when we rebooted our "front end" stack earlier last year, we need to have a testing solution (we didn't have any front-end tests before that!). Jest is fast and convenient and it has plenty of community support behind it. It let's us run our unit tests with Enzyme and snapshot tests.
This is an area that we are constantly reviewing to see what can be improved, both in terms of developer needs, accuracy, test maintainability, and coverage.
I'm currently exploring using React Storybook to be the record of snapshot tests and using some online services, such as Happo.io and Percy in our CI pipeline.
Earlier this year, we started developing a new app to help our runners deliver groceries to our customers. We chose React Native over a native app or a PWA and are really happy with it. So far, we really like what we are seeing. Development speed is fast and the tooling is awesome. The “learn once, write anywhere”-promise is really fulfilled and when we ran our project for the first time on iOS after a few weeks of development, we were excited to see how well it worked and what it looked like.
Read our blog post to learn more about how we use React Native, TypeScript, Redux.js, RxJS, CodePush, styled-components, React Storybook, Jest, and Prettier to develop this app, as well as our thought of what else we will do with it at Picnic.
React Storybook's Features
- Isolated environment for your components (with the use of various iframe tactics).
- Hot module reloading (even for functional stateless components).
- Works with any app (whether it's Redux, Relay or Meteor).
- Support for CSS (whether it's plain old CSS, CSS modules or something fancy).
- Clean and fast user interface.
- Runs inside your project (so, it uses your app's NPM modules and babel configurations out of the box).
- Serves static files (if you host static files inside your app).
- Deploy the whole storybook as a static app.
- Extendable as necessary (support for custom webpack loaders and plugins).