Within the vast realm of software development, numerous companies and individuals have contributed remarkable component libraries, generously shared and readily available on GitHub. These repositories stand as testament to the collaborative nature of our industry and the collective pursuit of excellence. In this article, however, our focus is to delve deeper into the concept of component libraries. We aim to provide comprehensive guidance to those who aspire to embark on their own journey of creating and curating a component library. By exploring this topic in greater detail, we will uncover the underlying principles, best practices, and valuable insights that will empower you to build your own library with confidence. Join us on this enlightening expedition as we unlock the power of component libraries and pave the way for a more efficient, scalable, and collaborative software development landscape. Let’s embark on this enriching journey together.
Before you start
About this post:
- 5 – 10 min average reading time
- Suitable for beginner’s through to advanced
What you will gain reading this post:
- A guide to help you determine which approach is best to use
- An explanation of the technologies I used for creating a component library
What you can do to help support:
- Like, comment and share this article
- Follow this blog to receive notifications of new postings
Now, let’s get started.
How do you know you need a component library?
While I recommend the use of a component library, I understand that venturing into creating a component library can be quite costly in regards to time and investment.
Therefore I recommend that you seriously consider the below categories to help evaluate if you really need one or not.
What is your business model?
Is your model an agency or product model?
Agency – A company or individual that does “work for hire” by receiving client requirements and delivering to those exact requirements.
The agency business model typically is less flexible in having control over what you can standardise and may not result in any added benefit of having a component library and in-fact exaggerate the problem you are trying to solve such as speed to market, reusability, maintainability and cost, I would recommend an investment in analysis to determine the similarities of your clients before diving into a solution of a component library.
Product – A company or individual that does “it’s own solutions” and approaches the clients with a pre-defined product they have or will have.
The product business model typically is much more flexible in having control over what you can standardise and may benefit you greatly by having a component library, with a component library you could present to the client a solution to suit their requirement as well as providing a level of security through component and patterns that you have tested and proven to be successful in the market, you can add a level of customisation through theming while benefiting in an increase speed to market, reusability, maintainability and cost.
I would recommend this as a good candidate for a component library.
What are you trying to solve?
It is really important to understand what you are trying to solve when exploring the path of developing a component library, there are many great reasons and benefits, but as with anything there are also a few trade-offs.
- Increase speed to market
- Increase reusability
- Decrease maintenance
- Decrease cost
- Establish standardisation
Has design been considered?
How many UX standards are you trying to support?
A standard in this context refers to a set of components and patterns that only differ in theming. If you are required to support more than a single UX standard, I have the following recommendations:
- Have a single component library per standard, this will help ensure you are not creating a polluted environment that will eventually result in a maintenance nightmare.
- Don’t rush into a component library, create the components and patterns in each project, you will then have enough knowledge to determine commonalities and will be able to then break that component or pattern into a component library.
- Do the components differ only through theming or are they semantically different?
If the component or pattern across your solutions are only different through theming then you have a great candidate to be included in an component library, however if you have the same component or pattern that needs to be created, because it requires slightly different semantic markup to support design decisions or business requirements, this is a flag that what you are creating is not a candidate for a component library but a project specific component.
Should theming be customisable for everything?
Short answer NO.
You should work with your designers to determine what you want to be themed, you will have a couple different types of theming considerations:
- Themes that are required to enable the components or patterns to behave functionally, an example of this would be a custom checkbox or custom radio button, typically this involves hiding the native control the shows if the component has been selected or not, resulting in an theme to be added to recreate that native behaviour. These functional themes I would not recommend to be customisable.
- Themes that will give your components a different “look and feel”, while technically you can make everything customisable, I would advise against this, I would work with your designers to help determine what you will require to be different, as a base I would recommend typography, borders and colours to be customisable and then expand on that as required ensuring to test various combination in your theming as you can end up with some funny and unexpected behaviours, I would also not recommend trying to customise native behaviours where possible as this can have significant consequences when trying to support multiple devices and browsers, with great power comes great responsibility…
What won’t a component library solve?
- If you have different API’s that you need to pass the data through to, this typically may require a level of data transformation that will live in the project that is consuming the component library.
- Customisation outside of what it was designed for.
My technology choices at the time of writing this article
At the time of writing this article, there are the technology choices that I chose to write a react component library, as the time goes on and those in the front end space know this very well what is the best technology choice changes very quickly and you should research what is the best for you now.
React with Typescript
This is a library created for component development and combined with the TypeScript language will have strong typing at compile time.
Please see via GitHub React & TypeScript
Styled Components
This is a library that allows you to style your components using javascript while utilising css and pre-processor syntax support.
Please see via GitHub Styled-Components
For an alternative that is very similar to Styled-Component, check out Glamorous Glamorous
Styleguist
This is a library that can be integrated into the component library and bring your component visually to life, it has built in state management to easily demonstrate the full power of your component library.
Please see via GitHub Styleguist
Travis CI
This is a fantastic continuous integration service that you configure in your project to perform build and deployments without the need to maintain your own instance or hardware (or you can if you wish), it allows for an configurable environment that support many languages and has integration with third party tools.
Please feel free to read and see my usage via a previous blog Publish your documentation with Github Pages and Travis CI
Please see via Site Travis CI
Tips
- Create the components and composite components (patterns) as simple, stateless / dumb as possible
- Don’t try to over engineer and with a purpose in mind.
- Have your component library only make use of internal state when required, this then allows any state management to be used with your components and patterns
- If you require speed to market, abstract your state management and validations into a seperate library, that will wrap your component library so you can consume that in your projects
- You can also create a layout system such as a grid and even go as far as a page
- Have a style guide to demonstrate your components
- Also a sample project to consume your components to ensure that they actually work in a real environment.
Did this help?
- Like, comment and share this article
- Follow this blog to receive notifications of new postings