Building a component library it’s not an easy task, notably when it fulfills the purpose of being used by multiple projects and requirements are continually changing. Given these challenges, we have a set of principles that guide us through the process of creating reliable components.
API design is foundational: We take this field seriously.
- Don’t start writing any code until the specification document is done and evaluated by the team.
- Design from restricted API then relax based on valid use cases.
- Create a deterministic API that doesn’t allow you to do the same thing in two different ways.
-
Defer it as long as possible. The best way of reducing the impact of breaking changes is to avoid them in the first place.
Until you have the information necessary, you are just guessing at what is needed and your success is determined largely by luck. I also believe you may be grossly underestimating the costs of speculation. — WayneMack
Generalization process is the key to avoid breaking changes. Avoid generalizing your component too early but keep in mind that the new API shouldn’t compromise generalize when new use cases arrive. I wrote more about this interesting topic here.
First-class Testing: Our components are test infected. There isn’t software improvement without refactoring and there isn’t refactoring without tests.
Internationalization: We design each component with i18n in mind. Any new component or feature has to be able to work fully in different locales.
react-rainbow-components wouldn’t be possible without the support of engineers from around the world. Thus, building a component library with internationalization is a requirement, not a nice to have.
Accessibility: It’s part of our definition of done. It’s a must-have for each component.
Documentation: It’s critical to the success of any project. There is no adoption without good documentation.
I know you have your own set of principles, let us know if ours make sense to you, we are eager to learn from you. Comment below.
Top comments (0)