I eventually got to work on a large scale ui component library for a customer, and I have to say, developing atomic components just made me a far better developer. Storybook together with react helped me realize important things.
Obviously we all want to create a accessible website. It's our one goal, to create every single atomic pixel accessible. When the designer gives the handover if the new Facebook, you probably have a goal, to create a nice replication of the initial design (even pixel perfect or what not).
What one usually forget is to ask the critical questions, such as "what should the focus implementation of this button be, if the button is not disabled?".
As a senior front end developer you would ask questions like:
"How does the element look when it's hovered"
"How does the element look when it's disabled"
"How does the element look when it's focused"
"How does the element look when the element is given input"
Those are all questions of creating accessible components!
Using storybook you have no choice, you create valid documentation as per component, and the various input to a given component. Documentation is done with the concept of stories. You can choose to create many stories per component.
You can create a story per size of Your button. You can create a story per theme of a button or Even a story per functionality of a sidebar navigation component.
Storybook is useless if you have no stories, the thing is, stories are self-documented and the examples you write is automatically documented via a sweet syntax highlighted document.
Storybook has made me a better developer because:
- Components is documented
- Separation of concern
- Focusing on details is easier
- add react and react-dom as peer dependencies
- Keep your UI in a separate repo to avoid mixing business logic