Imagine that you’re building a UI component with React and Tailwind CSS.

That component needs to support multiple style variants.

A fairly common instinct here would be to construct dynamic classes based on properties passed to the component.

We’re creating dynamic classes by interpolating the 

 prop values, which may sound like a good idea.

 classes are present somewhere else in our markup, 

these classes will not be generated, and the expected styles will not be applied

To answer this, let’s talk about Tailwind’s 

, based on what classes are being detected in your templates.

This ensures that even during development, you never deal with more CSS than you need to.

That translates to very fast build times and opens doors for many cool features that would simply not be possible if all permutations of utility classes were built upfront in a giant CSS file.

Want to add a bunch of new colors? A few extra breakpoints? Maybe add some custom variants to your config file?

Tailwind only generates the CSS for the classes you’re using in your project.

The Just-in-Time engine (JIT) is why all colors, variants, and dark mode are enabled out of the box in Tailwind CSS v3.

Oh, and these variants can all be stacked together, too. That’s 

But that’s totally fine – there is no need to ever worry about a bloated CSS output.

But, how exactly does the JIT engine determine 

The way the JIT engine scans your project to figure out what CSS classes to generate is intentionally simple and relies on two key principles:

Tailwind will only find classes that exist in a 

 template string in JavaScript, we expect the outcome to be 

Matter of fact - if you’ve tried this and inspected the 

 tag generated in your browser, you will 

But it’s not anywhere, as far as Tailwind’s JIT engine is concerned.

Tailwind doesn’t evaluate your JavaScript code. It looks at everything as plain text, no matter what programming language the file is written in.

<p>My favorite class in Tailwind is text-purple-700, I love it.</p>

The class is there, in its entirety, in plain text. Therefore, it will get generated.

And that’s the one and only rule the JIT engine lives by.

Can I find this Tailwind class in a full string as plain text? 👀 If yes, I’ll generate the CSS for it 👍 If not, I won’t 🤷‍♀️

You just have to be a little creative and find ways to provide dynamic styles in a JIT-friendly way.

Good news: that’s what we’re going to do now!

 component. That component will support multiple style variants in a way that works great with Tailwind’s JIT engine 

A JIT-friendly, multi-style Button component

We’ll keep things relatively simple. Our Button will support the following style variants:

Here’s what our button variants will look like:

Button Variants

Let’s start by scaffolding the Button component.

, and set some default values for those, to make those optional:

 prop values to decide what Tailwind classes should go in there.

Remember: we need to make sure every single Tailwind class we’re using is present, 

, as a full text string for the JIT engine to find.

There are many ways to achieve this, but one approach I particularly enjoy is to use “lookup” objects.

They’re just JavaScript objects where the keys represent the different possible prop variants.

The values represent a string of composed Tailwind utility classes that achieve the desired styles for that particular variant.

Here’s what such a lookup object would look like for the 

Tailwind will definitely look at these lookup tables 👀

The whole idea behind this approach is to ensure that 

 you use for your different variants is listed somewhere as a plain text string.

These lookup objects are sort of an inventory of every class you’re using across every possible style permutation.

From a developer standpoint, lookup objects are also great: you can “see” at a glance, in a clutter-free way, what every style variant will look like.

That’s much easier than trying to read through a series of ternary operators or other conditional logic JavaScript inside your 

But what about common styles between all variants?

No matter what component you’re building, you’ll inevitably have some classes that need to be applied to 

 style variant, regardless of the permutation of props.

It’s a good idea to identify those classes and abstract them away.

 attribute directly, but it’s kinda nice to store them in their own variable, sort of a “mini lookup” of its own, so everything style-related is colocated.

There aren’t many common styles to all variants in our 

We’ll handle focus styles in each variant, so it makes sense to opt-out of the default focus outline in our 

One thing to look out for is that you don’t have competing styles between different variant types.

Situations like this could lead to sneaky and unexpected results.

It’s worth spending some time thinking about splitting the style 

And make sure you have a clean separation between those.

, here’s what our complete styles inventory - our lookup objects - look like:

100% of the Tailwind classes used to build these buttons are present in this inventory.

Essentially, we want to “merge” Tailwind classes from our 

Our lookup objects represent each possible value for both these props.

The art of writing dynamic styles that play nice with Tailwind’s Just-in-Time engine

Just-in-Time friendly style variants in Tailwind CSS UI components (Part 1)

Right now, the developer using our component doesn’t really have any information or hints on what variants and sizes options are available for this 

We’d need to write some documentation, or they’d need to read the source code of our component to figure that out.

 to our component, but wouldn’t it be nice to have to autocomplete suggestions in the code editor about what props and prop values are available?

 if an incorrect prop or value is passed to the component?

I feel like this would be a great developer experience upgrade.

We can do this with relatively minimal effort here, using TypeScript.

This is not a course about TypeScript and how to set it up. Let’s assume we’ve got the environment to work with TS, and our 

I’ll show you how a couple of lines of code can really improve the developer experience when using our component.

Using our lookup objects for documentation and Type checking

 here to define our prop values. They’re pretty powerful.

But think about it: our lookup objects, in fact, communicate the available options for the 

We can take a lighter approach here and use these lookup objects to generate Types directly, using TypeScript’s 

This will generate a Type that represents 

typeof

Now let’s combine those two Types together in an 

Think of all other attributes a button can have, like 

Let’s update our interface to extend HTML buttons’ native props.

import type { ComponentProps } from 'react'

 interface on our Button component’s props:

Again, make sure the file where you consume the component has the 

Without having to import anything type-related, here’s what happens when I try to add a 

 prop can receive shows as autocomplete suggestions.

If I pass an invalid value (say I make a typo), TypeScript will let me know something’s wrong:

Whoops, thanks for that, TypeScript! Let’s fix the typo.

As soon as I start typing the prop name, here comes a suggestion:

Once again, the available values are listed for me to pick from:

I’m new to TypeScript myself, but this stuff gets me really excited 🎉

I think that was well worth the small effort. We only added a few lines of TypeScript in our source code, and the developer experience is significantly nicer now.

Here’s the full code for our Button component now, Types included:

For those not very familiar with TypeScript (count me in that group 👋), adding Types can sometimes feel invasive and confusing, making the code hard to read.

I think the “footprint” TypeScript leaves on our code is very minimal in this particular case.

It’s a lightweight implementation, and I’d say it’s definitely worth the effort for the autocomplete and error warning goodness it provides on the other end for the consumer of the component 👍

 component is in a pretty good place now.

I just want to touch on a tiny but crucial last detail.

 component to override or tweak the button styles?

Right now, as we’ve set things up, you cannot.

We do that intentionally to ensure that even if a 

 attribute before spreading the rest of the props, adding a 

 all of our beautiful styles carefully defined in our lookup objects.

 button with a single Tailwind utility class: 

There’s indeed the possibility to merge both 

It will feel very useful and look like it works well.

There will soon be a situation where one particular class you pass to the component is not working. It turns out it’s conflicting with the classes applied on the Button internally.

You’ll also realize your project may be drifting towards design inconsistencies.

Because the opportunity to tweak styles on buttons is there, folks will take that opportunity.

Why did you create a Button component in the first place?

Think about one of the main reasons you’ve considered creating a 

Likely, you’re hoping to provide design consistency throughout your project.

You want to make the work upstream of designing and defining a few button variants.

And allow the same component to be used everywhere.

So... consider the value of allowing to merge style 

It sure is tempting to allow it, but it’s arguably not the best solution.

What if I just want some margin top on my button?

 to apply the appropriate margin before your button

Add additional offset/spacing props to your 

Create another component responsible for handling spacing. Spacer GIF 😅

I like to think that spacing around an element is not the concern of the element itself.

So, I don’t personally recommend option #2.

Tailwind Articles

Just-in-Time friendly style variants in Tailwind CSS UI components (Part 1)

The art of writing dynamic styles that play nice with Tailwind’s Just-in-Time engine

Just-in-Time friendly style variants in Tailwind CSS UI components (Part 2)

Autocomplete suggestions and error messages with lightweight TypeScript