React Storybook

React Storybook Powerful tool for designing/testing a single component's functionality without worrying about the entire environment

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.

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.

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.

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.

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.

We used Zeplin and React Storybook together to speed up development and collaboration across the company when building Stack Decisions. #StackDecisionsLaunch

We used Zeplin to handoff designs and style guides from the design team to engineering. Because Zeplin automatically generates accurate specs, assets and code snippets from designs we were able to stay on the same page as a team and save time in development. Additionally the friction in communication between the design and development teams is greatly reduced as Zeplin will notify us when designs are updated.

We used React Storybook in a similar fashion to create a library of shared components. It allows us to organize our components into a library, view the different states of each component, and interactively develop and test components. Because React Storybook runs outside of our main application it allows us to develop UI components in isolation, which can improve component reuse, testability, and development speed. We were able to build quickly without having to worry about application-specific dependencies.

We use React Storybook for documenting our components in library format. It's great for interacting with a component in its isolated state. Creating the component in Storybook first before adding it to our feature set helps me think of it as a decoupled and standalone entity. We have three sections in our Storybook:

• Features: for feature-specific components such as Feed
• Library: for shared components like buttons, popups, etc
• Style: for constants in typography, colors, etc

I find these Storybook add-ons useful:

• Knobs: Change props on the component to see how it responds
• Action Logger: See events being fired as you trigger them
• Notes: Document your component in more detail

#StackDecisionsLaunch

https://auth0.com/blog/our-engineering-experience-with-react-and-storybook/

This is Auth0's overview of how they use React Storybook and React to create modular and reusable components that can be shared across projects by building a component library. A very similar approach to how we do it at StackShare!

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.