5 reasons for using pattern library in your next project
Being a front-end developer today is much enjoyable then it was 10 years ago. The whole ecosystem exploded, and in recent years a lot of tooling, previously unimaginable, made its own way into our everyday lives.
Our stacks become mightier, features become easier to deliver and yet we still make the same mistakes over and over again.
Whether we are building the next big thing app or just juggling with our client work, there are common problems occurring in both of those cases.
Developer teams are mostly focused on delivering the projects in less time and with fewer bumps and bruises possible. That keep smiles on a lot of faces and our sanity healthy.
We all strive towards that perfect project state, where everything is aligned properly and every feature is functioning flawlessly.
But sooner or later, we still end up in a messy state where everything seems to fall apart.
What if there is a cure for that? The bright light at the end of the tunnel!
What is a Pattern library?
Style guides or pattern libraries are terms that recently emerged from design and moved into the development ecosystem.
On the design side, they represent a set of design rules describing the brand characteristics and on the development side, a set of common component and UI patterns.
https://fractal.build/
Why do we need them?
We usually spend our time on things like tooling, clean code patterns, and common development techniques. Rarely on stuff that comes at the very end. Like maintenance or even documentation.
The closer we are to the actual project end the more we are focused on features and delivery. In the process, we tent to leave code/functionality for later refactor and/or removal, which never happens.
There are a lot of cases where pattern library can bring additional value to the project, but I found out that the majority of projects benefit from following.
Developer Onboarding
The closer we are to the actual production deployment we can expect business to throw in a new developer to give us an extra energy boost.
In that process, we need to spend some time on the onboarding process for them.
Having nicely documented common patterns and components can do a lot of this work on its own. They reduce the time we need to put in to help our co-workers catch-up with us.
Technical Debt
Every time we develop a new feature, we tend to briefly take a look for similar components to reuse. If we don’t find what we want, we end up developing a new one.
That way we are creating a technical debt that is hard to clean later in the project and it’s invisible to the team until it starts to pile issues.
Pattern libraries do a great job of presenting a component in a much cleaner way. Which on the long run reduces a lot of maintenance time.
https://storybook.js.org/
Lack of Documentation
In my opinion, one of the major problems almost every project has is the lack of documentation. Sometimes that’s better than having one which is outdated.
In cases when we need to refresh our memory with functionality from the very beginning of the project, we tent to go back a dig thru templates to figure out how that thing works.
Usually, that’s not enough, and we start experimenting until we don’t have something solid to use.
One of the good things with having pattern library is that we can create a real component scenario in different situations and see it behavior in real time.
That means we can create fully responsive UI component, with a lot of scenarios which we can reuse then anytime.
Unified Workflow & Coding style
The more developers, the more workflows/coding styles we have. Usually, that’s the story with almost all projects that include a large group of people.
Of course, tools like linters can help but they are usually applied only for some specific cases. Like linting CSS for formatting and JavaScript for common patterns and best practices But having a lot of those can make an impact on actual developer experience.
By forcing everyone into one workflow/coding style, we are ensuring that each time we develop a functionality, we go thru the same processes.
Usually those workflows include all parties; designers, front-end and back end developers.
It’s not unusual for developers come and go, but, the project is one that always suffers.
https://patternlab.io/
Environment free Development
Having the ability to develop actual functionality far from the environment is one of my favorite features. Too many times I had to perform a set of steps just to be able to develop a simple component.
Things like going to the specific step in the secure checkout form to adjust padding on some dropdowns, or logging in few times to test if radio buttons properly trigger validation. Which unfortunately is restarted once we refresh our browser.
Even then I wasn’t completely focused on actual feature development, which resulted in going back and forth during the actual feature implementation. Not to mention how time-consuming that was.
Conclusion
Patterns libraries have many advantages that can enhance team performance. Many of them have impacts far beyond the developer experience.
Like reduced development time and time that is spent on managing the team during a feature development.
Usually, we can expect to extend our feature development time in the beginning of the project, but once we are all onboarded, we can expect our project to be more stable.
On the other side, the implementation of the pattern library can cause some turbulence in your current workflow. But that’s nothing relative to the actual benefits you get on the long run.
Where to start?
Currently, there are some major players in the pattern library field, depending on the technical stack your project is using.
In case you are using popular tools such as React, JS VueJS, EmberJS or Angular, you can check Storybook.js.io. They went thru a major redesign lately.
For projects that are built with custom solutions, you have Fractal.build and patternlab.io that can be easily integrated with your build process.
Take a look on some examples: