How we use webcomponents to build a better (looking) product
by Tiago Santos
One of our company’s goals is to make payroll and HR as simple as possible for our users so they spend less time on technicalities and more time focused on their employees: the heart of the business. That isn’t fulfilled only through the features we provide. We also need to ensure our interface looks comprehensive and straightforward (even in such a complex context as payroll).
We can achieve this by keeping up to date with the web’s latest UI and UX patterns, but also by ensuring consistency across all features/components of the product. Two factors have enabled us to greatly improve not only the product but also its development. First, we’ve added two UX Designers to our team. They define what patterns we should be following and why and design the look and behaviour of all the UI components to be used, which takes me to the main topic. The second factor was the adoption of Web Components. It gave us the boost we needed in development while also ensuring consistency across the product.
What are web components?
Web components are a web standard to build reusable user-defined HTML elements that can have all their functionality encapsulated from all the rest of the page’s code. The functionally is not only its own scope, but it is also possible to encapsulate its style as well. This assures us that no matter where we use them, they will always function and look accurately.
This is made possible by 3 main features:
- Custom elements: Allowing us to define unique and expressive custom HTML element tags
- Shadow Dom: This specification is what defines who the encapsulation of style and markup code works like mentioned above
- HTML Templates: Defines how we can turn a piece of HTML code into a document fragment embedded in the page once as document fragments and allowing its reuse
In short, by combining these three great features into what the web components are, we were able to create all sorts of reusable components that we need. From the most simple badge to a highly complex table by simply adding a
<nmbrs-badge type=”success” text=”Success”></nmbrs-badge>
or
<nmbrs-single-table></nmbrs-single-table>
(and setting the data inside it after)
What led us to web components
Before the web components, to build custom elements, we had a set of javascript helpers that, from an HTML native element, would generate a “replacement” element. The new element would bind its value to the value of the original one. So changes in one would reflect in another. The new element would have a complex HTML structure sometimes and relied on generally available CSS to look as intended.
It didn’t take long for this to become an issue. Sometimes a class would conflict with another, or the HTML tree would be in such a way that the new element would render inconsistently.
Furthermore, since external code usually interacted with the component it was prone to break if it wasn’t handled the correct way (something that happened often).
Web components became a clear solution for these issues. We wanted full control over our UI components in a way that it would be difficult to mess with them, layout and functionally wise. Only then could we trust it would always work. The three features mentioned above provided that for us.
How do we use them
We started with a simple button as proof of concept which is the component that is more widely messed with. Its style is often adjusted to a particular case (in a lot of cases using inline CSS) for no apparent reason. It was the perfect pilot.
After a successful POC, we started to build up our library, which currently covers almost all our needs across the entire application. From lists and tables for nicely displayed data to input elements — including forms and steppers — that allow users to input all kinds of information in a structured way. All these components are featured with examples in a demo application so that developers can visualise them and have documentation to follow.
As for the building itself, we picked LitElement as our backbone. It is a solid library to build web components with a clear and comprehensive API.
Testing wise, we use a couple of tools/frameworks to ensure the components behave and look as expected. The tests check the structure (snapshot testing) and the functionality of each component by simulating user interactions.
Karma is our main testing framework, and we use Chai, together with its plugins, to build the tests. All of this comes together in a coverage report with the help of Istanbul to increase the confidence that we are covering all our corners.
Finally, the best thing about all of this process is that we can develop everything independently and update the web components across the whole application with a click of a button and no external constraints regarding the main product release cycle. This is possible due to the way we are distributing a Webpack generated bundle into the main application.
Final thoughts
Going with the choice of web components has proven to be the right decision for us. Not only are we ensuring we follow every UI/UX guideline that the design cycle defines, but we can also easily change and adapt the single look of every UI component on-demand and independently.
Furthermore, we have made development much easier for the whole company by providing a handful of (almost) plug and play components to our developers. It allows them to focus more on the inner workings of a feature instead of on how it should look and how to make it so.
To close this article I will leave you with a picture from one of the pages of our product where all that is visible is a web component.
About Tiago
I’m a Lisbon based Software Engineer working at Nmbrs for almost 3 years. During my time at Nmbrs, I have been part of multiple squads and involved in different projects. From the microservice architecture inner workings (my academic background) to, most recently, the UI facing web components, my goal is to always push tech forward in a clear and understandable way to everyone after me.
