React Component Development Studio

November 10, 2019

It’s easier for developers to work on their new component in isolation. We have some UI elements where, if you want to see the “real” version on the site, then you have to do a bunch of steps (like log in, pick this option, go to this step, etc etc). That gets annoying when you have to repeat the process to test every single change. Much faster to just look at Storybook which shows the component in every possible state.

Doing so encourages better code quality, like components that are well encapsulated. Without Storybook, we saw more devs writing React components that were not very reusable. (one example, I saw a React component that was directly using instead of taking that as a prop). If devs write the component in Storybook first, then that tends to make it more reusable.

That being said, if you’re a solo developer, I don’t know if it’s really worth the extra time investment to do something like this in the first place. However, it is a fulfilling process to complete if you’ve got a project you’re really passionate about.

I’d like to go over a few choices I investigated when trying to plan a component development solution of my own.


I initially started out building my own, but I quickly realized it was like developing another application just to manage the components for your actual application. It felt like it would get me a little bit of progress up front, but eventually would become unmaintainable and I’d stop using the tool.

Lots of smart developers, and even companies, have created sandbox environments for this. Why not just use them, and just leverage the time and knowledge that’s gone into them and use that to create better components that are easier to maintain?

Possible Component Development Process

  • Add new documentation
  • Add/update sandbox
  • Build the sandbox
  • Test your sandbox


  • Lots of control
  • Not dependent on other developers or buggy code or hacky implementations


  • Need to wire up components to sandbox manually
  • Create separate build and deployment system
  • Create sandbox app/page — Webpack? — Static HTML — Node server?
  • Its another you have to test
  • Its another you have to maintain and fix when it breaks
  • Too much control?


React Styleguidist is a React component development environment with a living style guide. It provides a hot reloaded dev server and a living style guide that lists component propTypes and shows editable usage examples based on .md files. It supports ES6, Flow and TypeScript and works with Create React App out of the box. The auto-generated usage docs can help Styleguidist function as a documentation portal for your team’s different components.

I ultimately didn’t really use Styleguidist that much, it was really just something I switched to after I couldn’t get Storybook to work right away due to NFS issues I would later come back to solve.

Possible Component Development Process


  • The automatic documentation creation was a huge plus for me. I might go back to Styleguidist if I can find a way to bridge some of the features Storybook does.
  • Easy component search functionality


  • I could not get Hot Module Reload to work at all over NFS, especially after finding this trick for Storybook.


Storybook is another playground for developing components and their behavior. It also serves as documentation for your component library, which you’ll have to create in your stories. You can showcase your components and their different alterations that are linked to props. While working with React for my project, it also supports other JavaScript frameworks like Angular or Vue.

The big cool thing is it allows you to browse a component library, view the different states of each component, and interactively develop and test components. When building a library, StoryBook is a neat way to visualize and document components and different addons, making it easier to integrate into your different tools and workflows. You can even reuse stories in unit-tests to confirm nuanced functionality.

Possible Component Development Process


  • Webpack is configured out of the gate, with no additional configuration on the part of the developer
  • Hot Module Reload support
  • Automatically detect your component and load stories
  • Easy component search functionality


  • Lots of headaches and issues configuring HMR when using files hosted over NFS mounts (such as when using Vagrant). I had to setup polling for Webpack in order to detect file system changes and trigger HMR.
  • Have to create documentation yourself
  • It takes a little extra time to write the “story” pages in addition to doing the page itself. I didn’t find this to be much of a hinderance, but it’s definitely something to think about.

Steven Wright

Written by Steven Wright who lives and works in Sacramento building useful things.