A djangster story on Storybook

import React from 'react'import { Popover } from './Popover'export default {
title: 'Popover',
component: Popover
const Template = (args) => (
<Popover {...args}>
export const Default = Template.bind({})export const Focused = Template.bind({})
Focused.args = {
autoFocus: true

Increased Productivity

At first blush it seems counter intuitive that adding an extra step to the development process would increase productivity but that’s pretty much what we saw. Most of the components we built have an accompanying story or two. This allowed us to get the client involved early and as a result the iteration period was remarkably fast. Writing stories was relatively painless and we actually made it way faster by using IDE templates to create boilerplate stories that only needed small tweaks and updates to the arguments.

Improved testing

Storybook also allowed us to introduce loki for visual regression testing. Visual tests are a mixed bag, and while they can catch a lot of unintended changes they also have a couple of downsides, such as increased maintenance cost. But we’ll probably talk more in another post down the road.

How the story is displayed in the browser, including interactive component elements such as popovers. A great example of how powerful Storybook can be can be seen at https://react.ui.audi.


When building an app that will be seen by millions of people on various devices responsiveness is super important. Storybook allowed us to define our target breakpoints and switch between them quickly which sped up development considerably. Loki also allowed us to define these breakpoints and have our visual tests check on mobile, tablet and desktop all with a single command.


While the setup was trivial, there were some issues we ran into that I feel I should mention.

  • Make sure that the app and Storybook use the same version of webpack because bad things will happen if they do not.
  • MSW, which stands for Mock Service Worker, but could be Magic Sea Weed (jury is still out), is your friend and will make testing components that call APIs a breeze

Client perspective

As mentioned before, our client was initially sceptical about our choice to use Storybook but that changed when we were able to demo different components for them in record time. They could see how the new homepage was shaping up and our QA team had a pretty easy time testing without needing to know anything about how to set up the whole system.


All things considered, we had a better time with Storybook than without it. It increased our productivity and forced us to be more deliberate with our component designs and testing. It also made the client more involved, put a spotlight on the visual aspects of the project early and inadvertently improved the way our visual specifications are handled.




djangsters are human-friendly IT professionals, who develop web applications, tailored to the individual needs of their customers. https://www.djangsters.de

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

A Tour to implement Lazy Loading …

Data Fetching with React Hooks

Testing or Tylenol for Future Headaches

Animation Made Easy: An Introduction to Framer Motion

Part 4 : ES6 JavaScript : Class in JavaScript | Inheritance |Getter & Setter

How I created a typing effect using JS

Typescript — functions

Lessons Learned at React Conf 2018

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


djangsters are human-friendly IT professionals, who develop web applications, tailored to the individual needs of their customers. https://www.djangsters.de

More from Medium

Using ResizeObserver and transitions for animating container with dynamic content

How to Code Swaying Bamboo with CSS🎋

5 Articles every WebDev should read this week (#01)

Why I Unit Test My Sass: Mixins 🧪