After years of development, we decided to standardize the user interface of one of our most important products – our multi-application dashboard. We did this for our customers and internal users (ease of use) as well as our product team (easier design process, decision-making, and coding). We also needed to align more consistently with our company’s branding.
For this, we built an internal design system, called Satellite. In developing Satellite, we looked at different CSS solutions for the UI library, all with their pros and cons: Saas, css modules, css-in-js.
After considering frameworks similar to Bootstrap, we settled on the CSS framework Tailwind CSS. Why?
However… there was a downside to Tailwind: the readability of complex components. The soup of Tailwind can be hard to digest when you’re not used to its classnames. In our case, it was made worse because we had to use a prefixed versions of the CSS classes (stl-
) to avoid conflicts with our legacy CSS, adding even more noise and length to our classname strings.
This article shows how we mitigated the readability problem. For starters, we used several web development techniques, such as tagged literals and interpolation, to shorten the length of our strings. Then we simplified the usage of the classnames with the linter tool ESLint, providing a better DX with two tools:
tailwind.config.js
) to be present in the project, while we had used a prebuilt version at the time. Among other tasks, we needed VS to work with our config file.That’s more or less the background. Now let’s get into the implementation.
A utility-first CSS framework like Tailwind comes with a large set of pre-existing utility classes that you can use directly in your HTML and JavaScript. These classes enable consistency across the code. And they are entirely configurable: with the same classnames, we could easily brand our application with variants. Therefore, using Tailwind CSS classnames enabled us to create a consistent set of colors, spacing, fonts – essentially, all things CSS – and rolled out an easy-to-implement design system.
We wanted to simplify our usage of Tailwind’s classes. For this, we used techniques such as tagged template literals, interpolation, and conditions.
We started with a long string of CSS classes like the following:
const className = 'stl-inline-flex stl-items-center stl-justify-center stl-rounded-full stl-h-10 stl-w-10 stl-bg-blue-100';
But we soon realized that this was not easy to read. Additionally, it contained unnecessary noise, such as the prefix stl-
, used to avoid clashes with other classes. So we enlisted the help of tagged template literals to remove the prefix from the string. We created an stl
tag:
const className = stl 'inline-flex items-center justify-center rounded-full h-10 w-10 bq-blue-100';
Finally, we wanted more readability. So we added:
The result is an elegant piece of (CSS) code:
const className = stl ' inline-flex items-center justify-center h-10 w-10 ${round && 'rounded-full'} ${iscool ? 'bg-blue-100' : 'bq-red-100'} ;
Elegance is one thing. Correct is another. It’s easy to misspell classes, especially when there are many classes to initially learn about in Tailwind.
Here’s an example of what can go wrong:
cost className = stl 'felx space-between text-gray-200’;
Can you spot the errors?
We needed to verify that the classes that people used were the correct ones. So we used the linter tool ESLint to parse the code, analyze it, and report errors. We created an ESLint plugin for code quality and to report errors on class names that didn’t exist.
Here’s the central ESLint code that does the validation:
ESLint uses an abstract syntax tree (AST) that gives access to individual lines of code. The AST essentially converts the strings of the code into nodes, which you can parse as collections and elements.
Here’s the breakdown of how ESLint parses the code. The whole expression is a node
of type VariableDeclataion
:
We want to parse the expression on the right side, the TaggedTemplateExpression
. As you can see, there’s a callback that handles this kind of expression:
In the TaggedTemplateExpression
callback, we collect all the strings in that template. For example:
TemplateElement
Literals
Once the collecting is done, there’s another registered callback that loops through the collected class names and confirms whether they exist. It does this with the collection, validClassNames
:
That’s it. We knew right away that creating this validation plugin was the right thing to do, because we actually found a few misspellings in our system, as well as in the existing dashboard codebase!
The last tool we created was an extension in Visual Studio Code. Using the same logic as in our plugin, ESLint suggests typescript classes as a developer types. This intellisense keeps the developers from guessing or having to go to the Tailwind website to search for and find the correct classes.
As you can see in the GIF, it not only proposes class names, it also displays the colors or useful icons for each suggestion.
With Tailwind CSS and ESLint, we’ve been able to enforce our standards (accessible internally on Github) by improving the DX in implementing them.
Peter Villani
Sr. Tech & Business WriterPowered by Algolia AI Recommendations
Clément Sauvage
Software Engineer, FreelanceChuck Meyer
Sr. Developer Relations EngineerTim Carry