Recently, shadcn launched [Themes](https://ui.shadcn.com/themes), a new feature for the highly popular shadcn/ui library.

The new themes let you pick a primary color, a border radius and a typography to make your app more unique:

![](https://cdn.sanity.io/images/knx644y7/production/a44508fc87a9c6d6e5116cfae049b42df516bec7-2730x2054.jpg?w=450)

It's all implemented with CSS variables and "theme scopes", precisely like what we're learning in the ["Multi-Theme Strategy" Pro Tailwind workshop](https://www.protailwind.com/workshops/multi-theme-strategy).

If you've taken the workshop and wanted to see a real-world example of what you could build with your new superpowers, shadcn/ui's themes are a great one!

Matter of fact, about a month ago I recorded a YouTube video where I wrap shadcn/ui's theming strategy inside a Tailwind plugin, for re-use across multiple projects:

<YouTube videoId="QJlTWj30krw" />

Recently, shadcn launched "Themes", a new feature for the highly popular shadcn/ui library. The new themes let you pick a primary color, a border radius and a typography to make your app more unique.

Theming strategy: shadcn/ui's new Themes

You've probably been in this situation before: you're using a UI component that contains its own style, but for some specific reason you _need_ to tweak some styles on a specific instance.

Say you want give a React `<Button>` component a "pill" shape with the `rounded-full` Tailwind class:

```tsx
<Button className="rounded-full" />
```

Depending on how the `<Button>` component is implemented, a few unwanted things may happen:

1. Nothing changes. No pill shape 😢
2. The `rounded-full` class is applied, but **all** the other classes are wiped out 🤔

This has to do with how the `className` attribute is being handled on the `<Button>` component, and whether the `{...restProps}` are being spread _before_ or _after_ that `className` attribute.

Ideally, we don't want to _replace_ the `<Button>` classes with other classes. 

We want to compose those classes together. Or even better: **merge** them without conflicts.

And this is where the [Tailwind Merge library](https://github.com/dcastil/tailwind-merge) is super useful. It can save you from many subtle and often undiagnosed UI bugs that have to do with how the CSS cascade works, and the Tailwind CSS output source order.

I've made a video to highlight those tricky UI bugs you can create when composing conflicting Tailwind classes, and how Tailwind Merge makes those bugs go away.

The video was added to the [official Tailwind Merge documentation README](https://github.com/dcastil/tailwind-merge/blob/v1.14.0/docs/what-is-it-for.md), and you can watch it here:

<YouTube videoId="tfgLd5ZSNPc" />

Let me know what you think!

Trying to pass Tailwind classes to a UI components that already defines its own classes? Tailwind-merge might save you from sneaky UI bugs!

You've probably been in this situation before: you're using a UI component that contains its own style, but for some specific reason you *need* to tweak some styles on a specific instance...

Merge styles without conflicts with the Tailwind Merge library

Designers and developers, even in great teams, can accidentally find themselves working in separate silos.

Designers are busy crafting visually stunning layouts and interfaces, while developers focus on implementing functionality and bringing those designs to life.

And the collaboration between these two essential roles? Well, it can be challenging at times.

Tailwind CSS plays a great "glue role" here, and can truly bridge the gap between designers and devs with its design-first approach 🌉

Let's dive into how Tailwind CSS helps designers and developers work together more seamlessly, thanks to its constraint-based design system, rapid prototyping capabilities, and utility-first nature.

**Spoiler alert**: it creates a unified language that both parties can understand and appreciate 🤝

## Constraint-Based Design System 📏

Tailwind CSS's constraint-based design system pushes design discussions and decisions right to the very start of a project. 💡

By **defining a set of design tokens** in the Tailwind configuration file, designers can create a shared language for design attributes like colors, font sizes, and spacing values. This system aligns beautifully with **how designers think**, offering a clear structure for organizing and applying design attributes consistently across a project.

## Designing in the Browser with Rapid Prototyping 🚀

Tailwind CSS's utility-first approach empowers both designers and developers to rapidly prototype and iterate on their designs.

Using predefined utility classes, designers can quickly create mockups and wireframes, while developers can efficiently turn those concepts into functional, responsive web pages 🖥️

This shared workflow speeds up the design and development process and fosters a more collaborative environment.

Plus, Tailwind CSS brings the concept of "designing in the browser" to life. Almost like **Figma for the browser** 🎨

Designers with basic HTML/CSS skills can contribute to the codebase way more easily than with other CSS methodologies. Mainly because **changes only affect one specific piece of UI they're working** on and can't break other parts of the project.

This low complexity reduces the risk of accidental damage on a site while working on UI tweaks, allowing designers to make adjustments with confidence 🦸‍♂️

## Empowering Designers and Developers Alike 💪

With Tailwind CSS, designers can define their design system without feeling constrained by predefined styles or components. Developers can trust that customizations will translate seamlessly into code, ensuring the final product is an accurate representation of the original design 🎯

It's a win-win, really.

The constraint-based design approach and rapid prototyping capabilities make it a breeze for designers and developers to collaborate effectively and efficiently, resulting in better web experiences for users.

## Wrap-up 🌯

Tailwind CSS is a game-changer for bridging the gap between designers and developers, thanks to its design-first approach, constraint-based design system, and utility-first nature. By fostering a shared language and streamlining the design and development process, Tailwind CSS enables both parties to work together more effectively, ultimately creating better web experiences for users 🌟

So, whether you're a designer or a developer, it's time to embrace Tailwind CSS and unlock the full potential of your collaborative efforts! 🚀

Let's dive into how Tailwind CSS helps designers and developers work together more seamlessly.

Bridging the Gap: How Tailwind CSS Unites Designers and Developers

### Improving the DX with TypeScript

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 `Button`.

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

Sure, we could add `prop-types` 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?

And get a warning _before saving_ 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 `Button` component file has a `.tsx` extension.

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

We could use `Enums` 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 `variant` and `size` props very well already!

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

This will generate a Type that represents _each key_ of our lookup objects.

Check this out:

```typescript
type ButtonVariant = keyof typeof variantsLookup
type ButtonSize = keyof typeof sizesLookup
```

<Video url="https://res.cloudinary.com/pro-tailwind/video/upload/v1659354701/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-2/typeof_v1t8j5.mov" title="typeof" />



Whoaaa 🙌

Now let’s combine those two Types together in an `interface` to use for our button props:

```typescript
interface ButtonProps {
  variant: ButtonVariant
	size: ButtonSize
}
```

### The `<button>` element has its own Type, too!

Technically, our `Button` has more props than just `variant` and `size`.

Think of all other attributes a button can have, like `disabled`, `type`, etc.

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

We’ll `import type { ComponentProps } from 'react'` at the top of your file.

Then, we can do this:

```typescript
interface ButtonProps extends ComponentProps<'button'> {
  variant: ButtonVariant
  size: ButtonSize
}
```

Now, we can use this `ButtonProps` interface on our Button component’s props:

```tsx
export const Button = (props: ButtonProps) => {
  const { variant, size, ...rest } = props
  return <button {...rest} className={...} />
}
```

And we’re good to go!

## What did we gain by doing this?

Let’s try to consume our `Button` component one more time to find out!

Again, make sure the file where you consume the component has the `.tsx` extension.

Without having to import anything type-related, here’s what happens when I try to add a `variant` prop to my button:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1659354792/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-2/using-variant-prop-on-button-component_frxbt3.png)

Boom! A list of accepted values the `variant` 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:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1659354922/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-2/passing-an-invalid-value-to-variant-prop-on-button_cn514f.png)

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

Now let’s try adding a `size` prop.

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

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1659355003/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-2/prop-suggestions-on-button-component_jrkplb.png)

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

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1659355065/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-2/available-values-for-size-prop_jhebap.png)

This is super rad!

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:

```tsx
import type { ComponentProps } from 'react'

const baseClasses = 'rounded-md font-medium focus:outline-none'

const variantsLookup = {
  primary: 'bg-cyan-500 text-white shadow-lg hover:bg-cyan-400 focus:bg-cyan-400 focus:ring-cyan-500',
  secondary: 'bg-slate-200 text-slate-800 shadow hover:bg-slate-300 focus:bg-slate-300 focus:ring-slate-500',
  danger: 'bg-red-500 text-white shadow-lg uppercase tracking-wider hover:bg-red-400 focus:bg-red-400 focus:ring-red-500',
  text: 'text-slate-700 uppercase underline hover:text-slate-600 hover:bg-slate-900/5 focus:text-slate-600 focus:ring-slate-500',
}

const sizesLookup = {
  small: 'px-3 py-1.5 text-sm focus:ring-2 focus:ring-offset-1',
  medium: 'px-5 py-3 focus:ring-2 focus:ring-offset-2',
  large: 'px-8 py-4 text-lg focus:ring focus:ring-offset-2',
}

type ButtonVariant = keyof typeof variantsLookup
type ButtonSize = keyof typeof sizesLookup

interface ButtonProps extends ComponentProps<'button'> {
  variant: ButtonVariant
  size: ButtonSize
}

export const Button = (props: ButtonProps) => {
  const { variant, size, ...rest } = props
  return <button {...rest} className={`${baseClasses} ${variantsLookup[variant]} ${sizesLookup[size]}`} />
}

Button.defaultProps = {
  variant: 'primary',
  size: 'medium',
}
```

That still reads really nicely!

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 👍

## One more thing...

Our `Button` component is in a pretty good place now.

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

### Can I add a className attribute on the `Button` component to override or tweak the button styles?

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

Try it! 😅

```tsx
<Button className="uppercase">Make the text uppercase</Button>
```

Doing this will do... _nothing_.

And it’s by design!

### Huh?

If you look at our `Button` implementation, we spread the `...rest` props on the button **before** the className attribute:

```tsx
<button {...rest} className={`${baseClasses} ${variantsLookup[variant]} ${sizesLookup[size]}`} />
```

We do that intentionally to ensure that even if a `className` attribute is passed to the `Button` (like we just tried), that `className` will be overridden by the `Button`'s internal `className` prop.

### But... why?

If we had the `className` attribute before spreading the rest of the props, adding a `className` attribute when using the `Button` component would **completely override** all of our beautiful styles carefully defined in our lookup objects.

🙀

If you used the component like that...

```tsx
<Button className="uppercase">Make the text uppercase</Button>
```

... the button would look like that:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1659355117/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-2/make-the-text-uppercase_zo3lur.png)

That’s an `HTML` button with a single Tailwind utility class: `uppercase`.

All the rest of the styles are wiped.

Whoops!

### OK, but how about _merging_ both `className` attributes?

There’s indeed the possibility to merge both `className` attributes together.

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

But there be dragons.

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.

Maintenance might become complicated.

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

Think about one of the main reasons you’ve considered creating a `Button` component with multiple variants.

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 _tweaks_ to each button instance.

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?

Surely, adding `mt-4` won’t hurt!

You’ve got a few solutions here:

1. Use another element like a `<div>` to apply the appropriate margin before your button
2. Add additional offset/spacing props to your `Button` component
3. 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.

Also, adding props to support more and more features often leads to a confusing component that can receive 34 different props trying to do too many things.

This is my personal opinion, but honestly I think option #1 is a very valid approach here:

```tsx
<div className="mt-4">
  <Button onClick={() => alert('Hooray!')}>I have some spacing on top of me</Button>
</div>
```

The extra `<div>` in your markup is a good value trade-off against the headaches of creating (and maintaining) multiple custom props for everything.

Think about why you love Tailwind CSS.

Instead of a confusing, large CSS class that does many things, you together compose small, single concern utilities.

In the end, use the approach that works best for you and makes you happy! 🤗

## Warning - we’ve created a silent “bug” here

So, we’re throwing away the developer’s `className` intent. The problem is, we’re doing it silently.

There’s nothing in place to warn our poor developer that that `className` will have no effect.

I have myself restarted my dev server and googled stuff too many times before realizing why a specific prop was not having any effect on a given component.

Let’s avoid this round trip for our fellow consumers of our component.

## TypeScript can help here. Once again

Since we’re already using TypeScript, let’s use a bit more of it to add some warnings when someone tries to add a `className` attribute to their `Button`.

Right now, the `className` prop is part of our `<ComponentProps<'button'>` Type, which is why TypeScript is not complaining about anything when a `className` is passed.

What we can do is _remove_ this particular property in our `ButtonProps` interface.

We can do that with TypeScript’s `Omit` utility Type.

In our `interface` declaration, we’ll `Omit` the `className` attribute, like so:

```tsx
interface ButtonProps extends Omit<ComponentProps<'button'>, 'className'> {
  variant: ButtonVariant
  size: ButtonSize
}
```

We’re telling our `ButtonProps` to take all the attributes of the HTML button element, **except** the `className` attribute.

```tsx
Omit<ComponentProps<'button'>, 'className'>
```

Now, here’s what we get when trying to add a `className` attribute to our `Button`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1659355221/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-2/adding-classname-attribute-to-a-button-component_ughlc4.png)

We’re being told the `className` property does not exist on our `ButtonProps` type.

In... some sort of cryptic way, it’s not super easy to read for a human.

Let’s do a fun little workaround.

We’re going to add a `className` optional property in our `ButtonProps` type, and set the expected value to be a human sentence:

```tsx
interface ButtonProps extends Omit<ComponentProps<'button'>, 'className'> {
  variant: ButtonVariant
  size: ButtonSize
  className?: `Hey, sorry but you can't pass classes to the Button component - Design System decision 🤷️`
}
```

We’re setting the type of our `className` prop to a particular string.

It’s doubtful that a user would try to pass this exact string in the `className` attribute.

And even if they did, nothing wrong would happen.

So, it’s a nice little trade-off since we’re trying to improve the developer experience.

TypeScript is not making it to the browser - it’s just a tool for development. We’re not going to introduce any bug with this, so I think it’s an acceptable “hack”.

What does it do?

Here’s what the error message looks like now when a `className` attribute is added to the `Button`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1659355553/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-2/new-error-message-when-adding-a-classname-attribute-to-the-button_bvc7ki.png)

Nice!

I _bet_ this is more useful to the developer trying to use our component!

Of course, you could be more descriptive with the message and explain _why_ the design decision was made.

But you get the idea!

Our little effort in TypeScript has greatly improved the experience of developers using our `Button`.

We’re saving them a few google searches, and source code detectives work.

Maybe even a computer restart 😅

## The Final (v2.0-final.updated.zip) version of our code

Ok, this time, we’re officially done!

Here’s the final (yea right!) version of our `Button` component’s code:



```tsx
import type { ComponentProps } from 'react'

const baseClasses = 'rounded-md font-medium focus:outline-none'

const variantsLookup = {
  primary: 'bg-cyan-500 text-white shadow-lg hover:bg-cyan-400 focus:bg-cyan-400 focus:ring-cyan-500',
  secondary: 'bg-slate-200 text-slate-800 shadow hover:bg-slate-300 focus:bg-slate-300 focus:ring-slate-500',
  danger: 'bg-red-500 text-white shadow-lg uppercase tracking-wider hover:bg-red-400 focus:bg-red-400 focus:ring-red-500',
  text: 'text-slate-700 uppercase underline hover:text-slate-600 hover:bg-slate-900/5 focus:text-slate-600 focus:ring-slate-500',
}

const sizesLookup = {
  small: 'px-3 py-1.5 text-sm focus:ring-2 focus:ring-offset-1',
  medium: 'px-5 py-3 focus:ring-2 focus:ring-offset-2',
  large: 'px-8 py-4 text-lg focus:ring focus:ring-offset-2',
}

type ButtonVariant = keyof typeof variantsLookup
type ButtonSize = keyof typeof sizesLookup

interface ButtonProps extends Omit<ComponentProps<'button'>, 'className'> {
  variant: ButtonVariant
  size: ButtonSize
  className?: `Hey, sorry but you can't pass classes to the Button component - Design System decision 🤷‍♀️`
}

export const Button = (props: ButtonProps) => {
  const { variant, size, ...rest } = props
  return <button {...rest} className={`${baseClasses} ${variantsLookup[variant]} ${sizesLookup[size]}`} />
}

Button.defaultProps = {
  variant: 'primary',
  size: 'medium',
}
```

And here’s what it looks like in the browser:

### 

<Video url="https://res.cloudinary.com/pro-tailwind/video/upload/v1659355606/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-2/button-variants_i7eqys.mov" title="button variants" />

## You did it! You made it to the end of the tutorial.

Well done, champion 🎉

Ok, so we built a simple Button component.

Now, what if we...

* Added Storybook to our project to work on that `Button` with an easy preview of different states and scenarios?
* Created a monorepo setup, so we can build multiple, separate websites and web apps that consume our `Button` component without the need to publish it on `npm`?
* Added support for multiple _themes_ using CSS variables and Tailwind’s Plugin API?
* Create a more complex component that bakes in JavaScript behavior, keyboard navigation, and accessibility?

Well, that’s exactly what we’ll be doing in the **Pro Tailwind** course.

I hope you’re looking forward to it!

Have a great rest of your day! 🤗

Autocomplete suggestions and error messages with lightweight TypeScript

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

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.

Here’s a simplified example:

```jsx
// Component use
<Text color="purple" size="lg">I should be purple and large text.</Text>


// Component implementation
export function Text({color, size, children}) {
  return (
		<p className={`text-${color}-700 text-${size} ...`}>
			{children}
		<p>
	)
}
```

We’re creating dynamic classes by interpolating the `color` and `size` prop values, which may sound like a good idea.

But **it won’t work** with Tailwind CSS.

Unless the `text-purple-700` and `text-lg` classes are present somewhere else in our markup, **these classes will not be generated, and the expected styles will not be applied**.

Damn. But _why_?

Great question.

To answer this, let’s talk about Tailwind’s _Just-in-Time_ engine.

---

### Just-in-Time compilation

Tailwind CSS v3 generates styles _on demand_, 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?

No problem.

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 _a lot_ of cumulated permutations 😅

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

This is **awesome**.

But, how exactly does the JIT engine determine _what_ classes are actually used?

## How Tailwind looks at your code

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:

1. You need to tell Tailwind _where_ to look in your config’s `content` option
2. Tailwind will only find classes that exist in a _full, uninterrupted string_ in the files it’s looking at.

That second principle is the reason our `<Text />` example is not working properly.

When writing a `text-${color}-700` template string in JavaScript, we expect the outcome to be `text-purple-700`, given a `color` prop of `purple`.

Matter of fact - if you’ve tried this and inspected the `<p>` tag generated in your browser, you will _see_ that exact class, `text-purple-700`, applied to the paragraph tag.

It’s there, in the browser.

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.

Just like if everything was a `.txt` file.

Fun fact, the following code _will_ generate the `text-purple-700` class:

`<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 🤷‍♀️

## So... I can’t use dynamic style?

Wait, no – of course, you can!

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!

Let’s build a relatively simple `Button` component. That component will support multiple style variants in a way that works great with Tailwind’s JIT engine _on-demand_ generation strategy 🎉

Let’s go!

## A JIT-friendly, multi-style Button component

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

* **4 `variant` visual styles:** `primary`, `secondary`, `danger` and `text`
* **3 `size` options:** `small`, `medium`, `large`

Here’s what our button variants will look like:

<Video url="https://res.cloudinary.com/pro-tailwind/video/upload/v1659348018/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-1/button-variants_1_qquqrv.mov" title="Button Variants" />



Let’s start by scaffolding the Button component.

We’ll accept two props, `variant` and `size`, and set some default values for those, to make those optional:

```jsx
export const Button = (props) => {
	const { variant, size, ...rest } = props
  return <button {...rest} className="" />
}

Button.defaultProps = {
	variant: 'primary',
	size: 'medium'
}
```

Note that our `className` attribute is currently empty for now.

We will use the `variant` and `size` 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, _somewhere_, 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 `variant` prop:

```jsx
const variantsLookup = {
  primary: 'bg-cyan-500 text-white shadow-lg ...',
  secondary: 'bg-slate-200 text-slate-800 shadow ...',
  danger: 'bg-red-500 text-white shadow-lg ...',
  text: 'text-slate-700 uppercase underline ...',
}
```

Same deal for the `size` prop:

```jsx
const sizesLookup = {
	small: 'px-3 py-1.5 text-sm ...',
  medium: 'px-5 py-3 ...',
  large: 'px-8 py-4 text-lg ...',
}
```

## Tailwind will definitely look at these lookup tables 👀

The whole idea behind this approach is to ensure that _every single class_ 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.

### You will enjoy looking at those too!

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 `className` attribute! 😅

## 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 _every_ style variant, regardless of the permutation of props.

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

These could stay in the Button’s `className` 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 `Button` component case.

Here’s what it looks like:

```jsx
const baseClasses = 'rounded-md font-medium focus:outline-none'
```

That’s it.

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

### Beware of competing classes _between_ different variant types!

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

For example, you may have:

1. the `text-lg` class in `variant.primary`
2. the `text-sm` class in `size.small`

Situations like this could lead to sneaky and unexpected results.

It’s worth spending some time thinking about splitting the style _concerns_ of each style variant.

And make sure you have a clean separation between those.

## Our styles inventory

In the case of our `Button`, here’s what our complete styles inventory - our lookup objects - look like:

```jsx
const baseClasses = 'rounded-md font-medium focus:outline-none'

const variantsLookup = {
  primary: 'bg-cyan-500 text-white shadow-lg hover:bg-cyan-400 focus:bg-cyan-400 focus:ring-cyan-500',
  secondary: 'bg-slate-200 text-slate-800 shadow hover:bg-slate-300 focus:bg-slate-300 focus:ring-slate-500',
  danger: 'bg-red-500 text-white shadow-lg uppercase tracking-wider hover:bg-red-400 focus:bg-red-400 focus:ring-red-500',
  text: 'text-slate-700 uppercase underline hover:text-slate-600 hover:bg-slate-900/5 focus:text-slate-600 focus:ring-slate-500',
}

const sizesLookup = {
  small: 'px-3 py-1.5 text-sm focus:ring-2 focus:ring-offset-1',
  medium: 'px-5 py-3 focus:ring-2 focus:ring-offset-2',
  large: 'px-8 py-4 text-lg focus:ring focus:ring-offset-2',
}
```

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

All in plain text.

**100% JIT-friendly ⚡️**

All we need to do now is _correctly compose_ those styles together in our `Button`’s `className` attribute.

## Composing style variants together

This step is relatively straightforward.

Essentially, we want to “merge” Tailwind classes from our `baseClasses` with the appropriate `variant` and `size` classes from our lookup objects.

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

That means we can use our `variant` and `size` prop value to reach for the correct key in both those lookup objects, like so:

1. `variantsLookup[variant]`
2. `sizesLookup[size]`

We want to merge these two strings of classes with our `baseClasses`.

We’re combining three strings together, so we can do this in a template string:

```jsx
`${baseClasses} ${variantsLookup[variant]} ${sizesLookup[size]}`
```

That’s it! This combined string of class will dynamically adjust to the props passed to our component. This will take care of applying the right styles for any permutation of these props 🎉

Let’s put that string in our `Button`'s `className` attribute:

```jsx
export const Button = (props) => {
  const { variant, size, ...rest } = props
  return <button {...rest} className={`${baseClasses} ${variantsLookup[variant]} ${sizesLookup[size]}`} />
}
```

Annnd... voila! Our `Button` component now supports the styles for all the different variants.

Here’s the entire code for our component:

```jsx
const baseClasses = 'rounded-md font-medium focus:outline-none'

const variantsLookup = {
  primary: 'bg-cyan-500 text-white shadow-lg hover:bg-cyan-400 focus:bg-cyan-400 focus:ring-cyan-500',
  secondary: 'bg-slate-200 text-slate-800 shadow hover:bg-slate-300 focus:bg-slate-300 focus:ring-slate-500',
  danger: 'bg-red-500 text-white shadow-lg uppercase tracking-wider hover:bg-red-400 focus:bg-red-400 focus:ring-red-500',
  text: 'text-slate-700 uppercase underline hover:text-slate-600 hover:bg-slate-900/5 focus:text-slate-600 focus:ring-slate-500',
}

const sizesLookup = {
  small: 'px-3 py-1.5 text-sm focus:ring-2 focus:ring-offset-1',
  medium: 'px-5 py-3 focus:ring-2 focus:ring-offset-2',
  large: 'px-8 py-4 text-lg focus:ring focus:ring-offset-2',
}

export const Button = (props) => {
  const { variant, size, ...rest } = props
  return <button {...rest} className={`${baseClasses} ${variantsLookup[variant]} ${sizesLookup[size]}`} />
}

Button.defaultProps = {
  variant: 'primary',
  size: 'medium',
}
```

## On the other side, what does it look like when “consuming” the component?

Here’s what actually using this component feels like for the developer:

```jsx
import { Button } from 'path/to/button'

export default function Page() {
  return (
		<>
			<Button variant="secondary" size="small">Small, secondary button</Button>
			<Button>Medium, primary button</Button>
			<Button variant="danger" size="large">Large, danger button!</Button>
		</>
  )
}
```

Notice the second `Button` has no props at all.

Here’s what these three buttons look like in our browser:

<Video url="https://res.cloudinary.com/pro-tailwind/video/upload/v1659354248/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-1/3-buttons_zvr9zd.mov" title="3 buttons" />



Nice!

Since we have set `defaultProps`, it will use the `primary` variant if no variant prop is passed. And if no `size` prop is passed, it will use the `medium` size.

Nifty!

## Where are the docs, though?

Our `Button` component is nice and all, but where can developers read about what props are available and what values are expected for each props?

Should we create a documentation website?

Add `prop-types`?

What about TypeScript?

What would you do to improve the situation and give the consumer of our component a few more hints on how to use our `Button`?

Here’s a link to the code representing where we’re right now:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1659376522/articles/just-in-time-friendly-style-variants-in-tailwind-css-ui-components/part-1/articles-JIT-friendly-buttons-github_uzblxq.png)

[https://github.com/pro-tailwind/JIT-friendly-buttons/tree/main/part-1](https://github.com/pro-tailwind/JIT-friendly-buttons/tree/main/part-1)

Why don’t you play with it and see if you can improve the prop documentation situation?

Tailwind Articles