Simplifying Tailwind CSS with ESLint tools, tagged template literals, and a lot more

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?

• Pure CSS (no JS runtime) – good for performance
• Tends to generate smaller CSS stylesheet files (after purging) – also good for performance
• No switching between a CSS file and your javascript code while developing new components
• No time wasted trying to find good names for utility 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 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:

• 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 configuration file (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.

Tailwind – classnames are good, but can get complex

Classnames are good

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. 

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 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:

• 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:

const className = stl '
inline-flex items-center justify-center
h-10 w-10
${round && 'rounded-full'}
${iscool ? 'bg-blue-100' : 'bq-red-100'}
;

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: 

cost className = stl 'felx space-between text-gray-200’;

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 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:

• 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 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.