After years of development, we decided to standardize the UI 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.

We settled on Tailwind CSS. Why?

• Pure CSS (no JS runtime) – good for performance
• Tends to generate smaller CSS files (after purging) – also good for performance
• No switching between a CSS file and your javascript file while developing new components
• No time wasted trying to find good names for classes
• Helps promote UI consistency
• Allows you to define a collection of spacings and colors that map well to design tokens (a “Restricted Palette”)

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 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 techniques, such as tagged literals and interpolation, to shorten the length of our strings. Then we simplified the usage of the classnames with ESLint, providing a better DX with two tools:

• An ESLint plugin, because there was no official ESLint-Tailwind plugin at the time. 
• A Visual Studio Code extension to simplify the usage by providing intellisense of Tailwind’s many classes. The official ESLint VS extension didn’t work for us because it expected a tailwind.config.js to be present in the project, while we had used a prebuilt version at the time.

That’s more or less the background. Now let’s get into the implementation.

Tailwind – classnames are good, but can get complex

Classnames are good

Tailwind comes with a large set of pre-existing 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. Therefore, with the help of Tailwind’s classnames, we created a consistent set of colors, spacing, fonts – essentially, all things CSS – and rolled out an easy-to-implement design system. 

But Tailwind classes can get complex

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 classes like the following:

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:

Finally, we wanted more readability. So we added:

• Separate lines for more readability and grouping of common elements
• Interpolation with inline tagged template literals 
• Conditions for more powerful and adaptive styling

The result is an elegant piece of (CSS) code:

ESLint – effortlessly correcting human error

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: 

Can you spot the errors?

• Switching letters (felx for flex)
• Incomplete or non-existent classes (space-between)
• American vs British spelling (gray)

ESLint to the rescue – creating an ESLint plugin

We needed to verify that the classes that people used were the correct ones. So we used ESLint to parse the code, analyze it, and report errors. We created an ESLint plugin 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:

• The TemplateElement 

• The 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!

Proposing suggestions with our ESLint VisualStudio extension

The last tool we created was an extension in Visual Studio Code. Using the same logic as in our plugin, ESLint suggests 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 by improving the DX in implementing them.