Simon Vrachliotis

Welcome to the multi-style Tailwind component workshop!

Together, we're going to learn strategies and patterns to handle multiple style variants with Tailwind CSS.

Think of a button that with different props that change its style.

For example:

* A `size` prop that changes the button size
* A `look` prop that changes the colors
* A `shape` prop that will change the border radius

The combination of those props brings some styling complexity, especially when factoring in how Tailwind's just-in-time engine works.

Speaking of buttons, let's jump into our first workshop section!

Learn strategies and patterns for handling multiple style variants with ease in the Multi-Style Tailwind Components workshop!

Multi-Style Components Workshop Welcome

In this section, we'll work with a series of buttons that have multiple variants.

You can see an `impact` variant that changes the color or intensity of the button, a `size` variant, and a `shape` variant:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814226/workshops/multi-style-tailwind-components/images-multi-style_components_02-01-01.mp4/multi-style_components_02-01-01_4_00-13280-we-also-have-a-size-variant-and-a-shape-variant.png)

The way these buttons are currently implemented is not ideal. They're just hard-coded HTML button elements, with a lot of Tailwind classes repeated over and over.

Here's an excerpt from `hardcoded-buttons.astro` that shows the repeated classes:

```typescript

<GroupDisplay title="Impact">
  <button
    class="rounded-md bg-indigo-500 px-5 py-2 font-semibold text-white shadow-md hover:bg-indigo-600 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-indigo-500 focus-visible:ring-offset-2 active:translate-y-px disabled:pointer-events-none disabled:opacity-50 disabled:shadow-none"
  >
    Bold
  </button>
  <button
    class="rounded-md bg-indigo-100 px-5 py-2 font-semibold text-indigo-700 hover:bg-indigo-200 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-indigo-500 focus-visible:ring-offset-2 active:translate-y-px disabled:pointer-events-none disabled:opacity-50"
  >
    Light
  </button>
  ...
```

Instead of repeating the Tailwind classes on each button, we want to dynamically generate the right composition of Tailwind classes for any given variant combination.

Here's how we want these button components to be used to generate the same buttons as the example we've just looked at:

```typescript
<GroupDisplay title="Impact">
  <Button>Bold</Button>
  <Button impact="light">Light</Button>
  <Button impact="none">None</Button>
</GroupDisplay>

<GroupDisplay title="Size">
  <Button size="large">Large</Button>
  <Button>Medium</Button>
  <Button size="small">Small</Button>
</GroupDisplay>

<GroupDisplay title="Shape">
  <Button shape="square">Square</Button>
  <Button>Rounded</Button>
  <Button shape="pill">Pill button</Button>
</GroupDisplay>
```

There are a few rules and gotchas around what you should and shouldn't do when working with Tailwind's Just-in-Time engine.

For example, dynamically creating classes with interpolation won't work!

```typescript
// this won't work
<div class={`bg-${props.color}`}>
```

Throughout this workshop, you'll learn patterns and techniques that will help us work around these Just-in-Time requirements.

Dynamically generating Tailwind classes is much more flexible and maintainable than hard-coding them, as we'll see when we create different button variants.



Creating Dynamic Button Variants with Tailwind CSS

In this challenge, you will start by extracting the common Tailwind classes from the hardcoded buttons with different variants for Impact, Size, and Shape.

Here’s an example of the code for the Impact variant:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814236/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-01.mp4/multi-style_components_02-02-01_4_00-10800-and-heres-the-code-for-it.png)

The code for each of the button variants shows a lot of repeated classes, which is not ideal.

## Challenge

Your challenge is to identify and extract all the common Tailwind classes and store them in the `baseClasses` variable in the Button component.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814238/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-01.mp4/multi-style_components_02-02-01_16_00-49840-and-then-once-youve-done-that-.png)

The `Button` component already has props for `impact`, `size`, and `shape`, but no style is currently being applied.

After adding the extracted `baseClasses` variable to the `Button` component, the buttons will not look finished, but they should have some common traits shared with the hardcoded buttons.

Identifying and extracting common base Tailwind CSS classes is the first step in creating a more efficient styling process.

The first step to solving this challenge is to looks at all of the hardcoded buttons to identify common classes.

Looking at the first button, it seems that classes like `rounded-md` probably won't be common since it has to do with shape.

Similarly, classes with `bg-` will probably be for `impact` props, the padding classes will probably be for sizes, etc.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814238/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-02.mp4/multi-style_components_02-02-02_3_00-08280-which-is-this-one-here-.png)

It does look like every button has the same font weight class `font-semibold`.

In VS Code, highlighting `font-semibold` will highlight all other instances. This makes it easy to reference the other buttons at a glance.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814243/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-02.mp4/multi-style_components_02-02-02_10_00-38600-it-highlights-the-other-instances-of-that.png)

Let's add `font-semibold` to the `baseClasses` inside of `button.tsx`:

```typescript
const baseClasses = 'font-semibold
```

Going back to the hardcoded buttons, the text color, shadow, hover and background color are very specific to `impact`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814242/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-02.mp4/multi-style_components_02-02-02_15_00-59680-seem-very-specific-to-impact.png)

However every button has very similar focus styles that use the `ring` utilities, so we can add these to the `baseClasses`.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814241/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-02.mp4/multi-style_components_02-02-02_21_01-28960-and-then-we-have-these-active-styles-and-disabled-styles.png)

```typescript
const baseClasses =
  'font-semibold focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-indigo-500 focus-visible:ring-offset-2'
```

There are also `active` and `disabled` styles.

All of the buttons have a little spring effect going down by one pixel when we click or hit the space bar when focused. This comes from the `translate-y-px` class.

Let's add all of these styles to our `baseClasses`:

```typescript
const baseClasses =
  'font-semibold focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-indigo-500 focus-visible:ring-offset-2 active:translate-y-px disabled:pointer-events-none disabled:opacity-50'
```

With our common `baseClasses` pulled out, we can update the classnames attribute for the Multi-style `Button` Component:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814240/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-02.mp4/multi-style_components_02-02-02_33_02-23000-so-not-looking-great-just-yet-.png)

Notice that our new buttons have changed a bit.

They have the the same font weight, a little translate when active, and a blue outline ring when focused.

The buttons don't look great just yet, but this is just the starting point.

Next let's move on to implementing the individual styles based on each variant.

Learn how to simplify button styling by identifying common classes and creating a base style for Multi-style Button Component.

Identifying Common Classes

Extract Common Base Classes

You might take this for granted, but did you notice that the [Tailwind IntelliSense Plugin for VS Code](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss) working on the `baseClasses` variable?

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814242/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-03.mp4/multi-style_components_02-02-03_6_00-16580-we-have-these-hover-information-panels-.png)

We can hover and see information about the classes, and see color swatches.

There is also autocomplete suggestions when typing class names:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814244/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-03.mp4/multi-style_components_02-02-03_8_00-24360-you-can-see-we-have-the-auto-complete-suggestion.png)

But this isn't a lucky accident.

This works because I've opted into using a specific naming convention.

Note that renaming `baseClasses` to the singular `baseClass` will remove all of the IntelliSense goodness:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814244/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-03.mp4/multi-style_components_02-02-03_12_00-39200-i-dont-have-any-hover-information-.png)

No more hovers or color swatches. Even `ctrl+space` for autocomplete suggestions won't work!

## Customizing Tailwind IntelliSense

In order to bring it back, open VS Code's settings UI and search for Tailwind.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814243/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-03.mp4/multi-style_components_02-02-03_18_01-07320-and-we-have-this-class-attributes-option.png)

Look at the Tailwind CSS Class Attributes section.

By default the extension is set up for `class`, `className`, and `ngClass` to support HTML, React, and Angular, but we can add custom rules.

I've added a `.*Classes.*` rule.

What this says is that anything with some characters followed by "Classes" and then some characters will be a scope where Tailwind IntelliSense works.

Changing our `baseClasses` variable back to being plural will bring the color swatch and other helpful features back to our list.

### Going Deeper

The plugin also features a setting called Experimental Class Regex that can be edited inside of `settings.json`.

Inside of the JSON this section will take an array of arrays, each with two values. The first one is the container that wraps the scope where Tailwind IntelliSense should work. The second is a class list matching pattern.

Here I've tried an approach where I can add `tw` comments before and after something where I want IntelliSense support.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814242/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-03.mp4/multi-style_components_02-02-03_35_02-12440-the-first-one-is-the-container-that-wraps-the-scope.png)

It's a nice strategy, but does leave some strange comments in your code:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814244/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-03.mp4/multi-style_components_02-02-03_41_02-28480-so-thats-a-nice-opt-in-strategy-.png)

I've also created support for a `cx()` function that will be used throughout these challenges:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814242/workshops/multi-style-tailwind-components/images-multi-style_components_02-02-03.mp4/multi-style_components_02-02-03_43_02-36520-that-well-use-throughout-these-challenges.png)

The `cx` function can be found in the `utils` folder of the project.

To use this function, create a variable with some Tailwind classes then wrap it in a call to `cx()`:

```typescript
// no IntelliSense
const otherThing = 'text-green-300 text-4xl'

// IntelliSense works!
const otherThing = cx('text-green-300 text-4xl')
```

Adding these customizations to Tailwind IntelliSense really extends the surface area for where it is helpful.

This will be very valuable for us in the upcoming challenges!

Customizing the Tailwind IntelliSense Plugin for VS Code enables helpful features for your Tailwind CSS workflow.

Customizing the Tailwind IntelliSense Plugin for VS Code

We've extracted common classes to all of our buttons.

Now we're going to tackle the `impact` variant of the button and handle styles for all possible variations.

The `impact` variant has three distinctive styles: `bold`, `light`, and `none`.

Inside of `ButtonProps` we can see the `impact` prop reflects these three possible values:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814244/workshops/multi-style-tailwind-components/images-multi-style_components_02-03-01.mp4/multi-style_components_02-03-01_2_00-18480-and-the-impact-prop-reflects-these-three-possible-values.png)

We want to store the different possible class combinations for the `impact` prop in a lookup directory.

Instead of doing complicated ternary logic in the `className` attribute, what we want to do is have a lookup object that has a key for each possible prop variant, and then stores a string of the classes we want to apply for that variant.

The `impactClasses` variable has already been created. It is a TypeScript Record, which is a series of key-value pairs:

```typescript
const impactClasses = Record<ButtonProps['impact'], strings = {}>
```

In case you aren't familiar with TypeScript, don't worry! Here's what's going on.

The `Record` will make an object using each key from `ButtonProp['impact']`.

Hovering over that will show us each possible key:

```typescript
(property) impact?: "bold" | "light" | "none" 
```

Then the values will be strings with a series of Tailwind classes.

Using a `Record` ensures that we have one key for every possible prop variant.

## Challenge

Your challenge is to identify which classes are specific to the `impact` prop, then organize them for the `bold`, `light`, and `none` variants accordingly.

The `cx` function has been imported at the top of the file, which allows you to pass in multiple comma-separated classes.

Then the multi-styled `Button` component should be able to accept the `impactClasses` as well as the base classes.

Creating a lookup object of every possible variant saves us from adding complicated ternary logic in our component's className.

Like before, the first thing to do is look at the hardcoded buttons to identify the classes that should be applied for each variant.

The primary concern of the `impact` variant in terms of visual styles is color.

We have a dark background and white text for the bold variants, a light background and dark text for the light variants, and a transparent or very light background on hover for the non-variant.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814247/workshops/multi-style-tailwind-components/images-multi-style_components_02-03-02.mp4/multi-style_components_02-03-02_4_00-13500-its-quite-clear-that-the-primary-concern.png)

Looking at the classes, we can identify the `bg-indigo-500` background color, the `text-white`, and the `hover:bg-indigo-600`.

So the classes for background color, text color, and background hover color are the main three that are shared between the variants.

It might be hard to see, but the `bold` variant adds a subtle shadow below the button which the other variants do not have. This comes from the `shadow-md` class which is undone when the button is disabled.

## Extract Common Classes

Let's add the common classes to the `impactClasses` TypeScript `Record`, which works the same as creating a JavaScript object.

First we'll work on the `bold` variant classes.

Add the `bold` key to `impactClasses` and paste the classes for background and text colors as well as `shadow-md`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814245/workshops/multi-style-tailwind-components/images-multi-style_components_02-03-02.mp4/multi-style_components_02-03-02_25_01-45140-the-shadow-that-is-specific-to-the-bold-variants.png)

Next we will add classes for the `light` variant:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814247/workshops/multi-style-tailwind-components/images-multi-style_components_02-03-02.mp4/multi-style_components_02-03-02_28_02-06540-and-well-do-that-one-more-time-.png)

One of the really nice things about using a TypeScript `Record` is that we can hit `ctrl+space` to use VS Code autocomplete and see that we only have the `none` key left to implement.

Time time we'll have `bg-transparent`, `text-indigo-700` and `hover:bg-indigo-50`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814245/workshops/multi-style-tailwind-components/images-multi-style_components_02-03-02.mp4/multi-style_components_02-03-02_41_03-01180-so-that-is-our-impact-classes-object-complete.png)

## Combine Classes with `cx()`

With the `impact` variant classes extracted, it's time to use the `cx` function to combine them with the `baseClasses`.

The first thing to try is passing `baseClasses` and `impactClasses` into `cx()` like this:

```typescript
// inside button
className = {cx(baseClasses, impactClasses)}
```

However, this won't work because `impactClasses` is an entire object.

Specifying `bold` will work, but it will apply to each of the buttons:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814247/workshops/multi-style-tailwind-components/images-multi-style_components_02-03-02.mp4/multi-style_components_02-03-02_47_03-31700-you-can-see-that-now-all-our-buttons-have-the-bold-variant.png)

What we want instead is for each of the keys to be reached dynamically based on the prop that is being passed into the button.

To do that, we can leverage the same TypeScript magic from the `Record` and specify the key of `impact` without quotes:

```typescript
// inside button
className = {cx(baseClasses, impactClasses[impact])}
```

Now that the `impact` variants have been successfully implemented, we can continue the process with the other variants to complete our button!

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814245/workshops/multi-style-tailwind-components/images-multi-style_components_02-03-02.mp4/multi-style_components_02-03-02_53_04-04020-we-have-successfully-implemented-the-impact-variant-styles.png)

Learn to extract and combine classes in React buttons for the Impact variant using TypeScript Records and the cx() function.

Dynamic Styling with the cx() Function 

Simplify Button Styling for All Possible Variants

Now that you're comfortable with this approach of creating a styles lookup object that holds a key for each possible prop value, it's time to recreate the same process for the other two props.

## Challenge

Your challenge is to repeat the same process we followed for `impactClasses` variant to create `sizeClasses` and `shapeClasses` variants.

Once you have created these objects and added them to the `className` attributes with the `cx()` function, you should have the dynamic buttons look exactly like the hardcoded buttons at the top.



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814246/workshops/multi-style-tailwind-components/images-multi-style_components_02-04-01.mp4/multi-style_components_02-04-01_7_00-36420-look-exactly-like-the-buttons-at-the-top.png)

Style lookup objects can be created for every possible variant of your components.

Let's start this time by defining the shape of the objects that we want to create.

Taking advantage of the autocomplete that using TypeScript gives us, we can create these objects quickly.

```typescript
const sizeClasses: Record<ButtonProps['size'], string> = {}
const shapeClasses: Record<ButtonProps['shape'], string> = {}
```

For `size` we'll need classes for `large`, `medium`, and `small` variants.

For `shape` we'll need `square`, `rounded`, and `pill`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814249/workshops/multi-style-tailwind-components/images-multi-style_components_02-04-02.mp4/multi-style_components_02-04-02_3_00-25760-so-you-can-see-that-without-having-to-refer.png)

## Extracting the Size Variant Classes

Let's look at the size variants to identify the common classes.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814248/workshops/multi-style-tailwind-components/images-multi-style_components_02-04-02.mp4/multi-style_components_02-04-02_6_00-42520-and-so-whats-affecting-the-size-here.png)

The likely classes here are the font size and the padding values.

For the `large` variant we have `text-lg`, `px-7`, and `py-2`.

```typescript
const sizeClasses: Record<ButtonProps['size'], string> = {
  large: 'px-7 py-2 text-lg',
  medium: '',
  small: ''
}
```

The `medium` variant has padding classes `px-5` and `py-2`. However, it doesn't have a font size class so it will use `text-base` by default.

When creating that variant, I'll explicitly specify `text-base` to not only communicate intent but also reset the font size in case it ends up being set by a parent element.

```typescript
const sizeClasses: Record<ButtonProps['size'], string> = {
  large: 'px-7 py-2 text-lg',
  medium: 'px-5 py-2 text-base',
  small: ''
}
```

The `small` variant uses `px-3`, `py-1`, and `text-small`:

```typescript
const sizeClasses: Record<ButtonProps['size'], string> = {
  large: 'px-7 py-2 text-lg',
  medium: 'px-5 py-2 text-base',
  small: 'px-3 py-1 text-small'
}
```

Now when we combine the `sizeClasses` with `baseClasses` in the `className` attribute we can see that the dynamic sizes have taken effect:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814249/workshops/multi-style-tailwind-components/images-multi-style_components_02-04-02.mp4/multi-style_components_02-04-02_16_01-54880-we-can-see-the-different-sizes-here-working.png)

## Implementing Shape Variants

Looking at the `shape` variants, the classes seem to be related to having rounded corners.

In this case the `square` variant doesn't have any shape classes, but we'll specify `rounded-none` to be more explicit in our intent.

The `rounded` variant uses `rounded-md` and the `pill` variant uses `rounded-full`:

```typescript
const shapeClasses: Record<ButtonProps['shape'], string> = {
  square: 'rounded-none',
  rounded: 'rounded-md',
  pill: 'rounded-full',
}
```

Now when we add `shapeClasses[shape]` to the `classNames`, all of the Multi-style Button Component variants look like their hardcoded counterparts:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814248/workshops/multi-style-tailwind-components/images-multi-style_components_02-04-02.mp4/multi-style_components_02-04-02_37_04-06480-once-we-have-all-these-styles-lookup-objects-put-together-.png)

## Recapping Our Work

We started with a series of hardcoded buttons with a lot of repeated class names, then essentially organized them into different style constants.

Then we composed those parts together dynamically inside the `className` attributes, which allows us to organize dynamic styles in a really elegant and organized way.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814249/workshops/multi-style-tailwind-components/images-multi-style_components_02-04-02.mp4/multi-style_components_02-04-02_39_04-29360-instead--we-have-all-our-styles-organized-in-one-place.png)

The `baseClasses` is a string that stores every utility class applied to all of our buttons, then can be further customized with different variants thanks to the `impactClasses`, `sizeClasses`, and `shapeClasses` we specified as TypeScript `Record`s.

These Tailwind lookup directory objects put all of the classes in one place, and works really well with the Just-in-Time engine.

We have full autocomplete support for the variants, and have the option to add additional classes as well.

All nine of these buttons are displayed with only 15 lines of code, which is much more pleasant and easier to maintain than hard-coding all the Tailwind classes.

Hopefully this gives you a good idea of how to organize and compose multiple style constants together!

Next we'll move on to working with style lookup directories in more complex scenarios.

Creating Dynamic Style Variants 

Implement Size and Shape Variants

Just as we finished organizing our button classes within different style lookup objects, here comes the product manager with new requests that are out of scope!

We need to implement support for a new `tone` prop, which is responsible for changing the tone of the button from `default` to `danger` or `success`.

This `tone` prop clearly impacts the colors of the button:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814226/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-01.mp4/multi-style_components_02-05-01_3_00-20360-this-tone-prop-clearly-impacts-the-colors-of-the-button.png)

Up until now, we were using the `impact` prop to handle the styling concern of colors.

Revisiting the `impact` variants, it seems like `bold`, `light` and `none` might be more of an "intensity" concern.

For example, `bold` would have an intense dark color and bright text, `light` would have a subtle background and dark text, and `none` would have virtually no background except on hover:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814227/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-01.mp4/multi-style_components_02-05-01_6_00-48660-and-if-we-look-at-the-different-tones-.png)

## Challenge

The Button concerns need properly split so the `tone` prop will be responsible for the actual color, and the `impact` prop will be responsible for the intensity of the shade.

The `impactClasses` object has now changed its type to be a nested `Record` that uses the `tone` and `impact` props together.

Currently there is a red line error from TypeScript because the existing classes do not respect the new shape:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814249/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-01.mp4/multi-style_components_02-05-01_12_01-30580-because-this-is-not-respecting-the-new-shape.png)

Your job is to update the class names to work as a nested object that will separate the concerns between intensity of the color and the actual color.

Changes in scope to modify existing variants and creating new ones becomes much easier with the right process in place.




Let's make the `tone` prop and the `impact` prop work together.

The new `tone` prop has three values: `default`, `danger`, and `success`.

We want to combine this with the `impact` variants for `bold`, `light`, or `none`.

The `default` tone should take the same color as the current one, which is `indigo`. The `danger` would have `reds` with the same number of shades, and `success` will have `green` with the same number of shades.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814230/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-02.mp4/multi-style_components_02-05-02_5_00-24780-and-then-the-danger-would-have-reds.png)

We want to satisfy our new `impactClasses` shape, which is a `Record` where the keys are the `tone` props (default, danger, success) and the values are a new `Record` key value pair, where each key is the `impact`:

Here's the starting point of this shape:

```typescript
const impactClasses: Record<ButtonProps['tone'], Record<ButtonProps['impact'], string>> = {

}
```

Because TypeScript allows for autocompletion, hitting `ctrl+space` will show us the different `tone` keys we need to implement:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814229/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-02.mp4/multi-style_components_02-05-02_10_00-52540-so-we-would-have-default-and-then-nested-inside-of-this-.png)

We'll start by implementing the `default` prop.

The values for the `default` object will be a nested object with the different `impact` props of `bold`, `light`, and `none` that we can copy from `impactClasses`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814226/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-02.mp4/multi-style_components_02-05-02_14_01-06040-and-then-i-can-copy-that-a-couple-of-times.png)

Then we can copy the `default` set for `danger` and `success` variants, changing the `indigo` color for `red` and `green` accordingly:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814227/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-02.mp4/multi-style_components_02-05-02_16_01-39400-as-you-can-see--its-not-working.png)

We've swapped out colors, but broken the styles.

Can you see why?

In the `Button` where we have the `className` attribute combining classes with `cx()`, we are reaching for `impact` directly:

```typescript
// inside Button
className={cx(
  baseClasses,
  impactClasses[impact],
  ...
```

Remember that `impact` can be `bold`, `light`, or `none`, but with our changes `impactClasses` no longer has these as primary keys. Instead, they are nested inside of the different `tone` values.

To fix this, we need to first grab the `tone` then the `impact`:

```typescript
// inside Button
className={cx(
  baseClasses,
  impactClasses[tone][impact],
  ...
```

With this change we can now see colors and impact variants on our dynamic buttons:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814226/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-02.mp4/multi-style_components_02-05-02_23_02-23120-check-this-out.png)

However, we're not done yet.

Tabbing through the hardcoded buttons, notice that the different buttons have specific ring colors but our dynamic buttons all have the indigo ring color still:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814227/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-02.mp4/multi-style_components_02-05-02_28_02-45680-so-weve-got-to-fix-that.png)

To fix this, we need to take out the focus ring color from `baseClasses`, and implement it in our `impactClasses`.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814230/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-02.mp4/multi-style_components_02-05-02_31_02-54600-the-focus-colors-using-the-indigo-class-here.png)

There are a couple of options for applying the focus ring color to the three possible `impact` variants.

You could come up with a `baseImpactClass` string that could be composed with all of the others, but in this case I don't mind copying and pasting the same focus ring color three times is that big of a deal.

It's all about finding what works for your specific requirements!

For each of the variants I'll paste in the `focus-visible:ring-indigo-500` then edit the values to be red for `danger` and `green` for `success`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814230/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-02.mp4/multi-style_components_02-05-02_40_03-53840-and-finally-for-success--i-will-change-this-to-green.png)

Now tabbing through the dynamic buttons will show us the correct ring color!

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814228/workshops/multi-style-tailwind-components/images-multi-style_components_02-05-02.mp4/multi-style_components_02-05-02_41_04-01760-so-there-you-have-it.png)

So there you have it. We now have a button components that compose four different style variants together.

The `Button` component's `className` attribute is composed together without complexity.

It's easy to read and reason about, because all of our styles are in a lookup directory in a single location as full strings that work with Tailwind's Just-in-Time engine.

```typescript
// inside button

className={cx(
  baseClasses,
  impactClasses[tone][impact],
  sizeClasses[size],
  shapeClasses[shape]
```

Learn how to make dynamic buttons with different colors and impact styles by combining the tone prop with the impact variants, using TS and TailwindCSS.





Implementing Dynamic Tone & Intensity Styles

Separating Tone & Intensity Concerns

In this section, we'll take a naive basic modal component and progressively make it robust, flexible, and reusable.

First, we'll leverage Headless UI to drastically improve the usability and accessibility story.

We'll then implement multiple style variants, making options available for the modal's size, tone, and sliding animation direction.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814230/workshops/multi-style-tailwind-components/images-multi-style_components_03-01-01.mp4/multi-style-components-03-01-01-modal.jpg)

The Headless UI component library gives as an accessible base for building a modal with multiple style variants for size, tone, and animated transitions.



Improve Accessibility and Usability with Headless UI

Let's take a look at the basic model component we're starting with.

Here's an in-page example:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814233/workshops/multi-style-tailwind-components/images-multi-style_components_03-02-01.mp4/multi-style_components_03-02-01_3_00-07420-if-i-click-the-button--the-model-will-show.png)

If I click the button, the modal will show and then I can cancel or confirm to close the modal.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814231/workshops/multi-style-tailwind-components/images-multi-style_components_03-02-01.mp4/multi-style_components_03-02-01_7_00-41760-you-can-see-that-it-scrolls-freely.png)

The way it's currently set up on the page, we have an `isOpen` piece of state and then we conditionally display the model if the `isOpen` prop is `true`.

Below that, is some page content to bring some context and use to discuss some of the shortcomings of the current implementation.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814230/workshops/multi-style-tailwind-components/images-multi-style_components_03-02-01.mp4/multi-style_components_03-02-01_5_00-20200-below-that--ive-added-some-page-content.png)

Right now, the model component looks pretty good, but it's lacking some really important features in terms of accessibility and usability.

When the modal is open, it should technically freeze the background and prevent the body from scrolling. But right now, it scrolls freely.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814232/workshops/multi-style-tailwind-components/images-multi-style_components_03-02-01.mp4/multi-style_components_03-02-01_9_00-58040-and-thats-not-what-we-want.png)

Our current implementation also has issues with focus trapping, keyboard navigation, and closing behavior.

Right now, if you hit the tab key, you can see that the focus will go on the first link and then first and second button. But if you keep tabbing, the focus will end up in the focusable elements in the background page, which is not what we want.

The only way to close the model is by clicking one of the buttons, and you can't click outside or hit the escape key.

All of this behavior is essential to a model component, so let's use Headless UI to improve the usability and accessibility before we implement multiple style variants.

## Challenge

Your challenge is to update our existing modal implementation to use the `Dialog` component from Headless UI.

You should also use the `<Dialog.Panel>` and `<Dialog.Title>` components.

Check out [the Headless UI Dialog docs](https://headlessui.com/react/dialog) for help!

The current modal has accessibility and usability issues. Refactoring it to use Headless UI's Dialog component is the first step of this workshop section.

The first step is to replace the parent most div of the `Modal` to use the `Dialog` component, and pass the `open` and `onClose` props.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814234/workshops/multi-style-tailwind-components/images-multi-style_components_03-02-02.mp4/multi-style_components_03-02-02_3_00-28260-i-promise-you-i-am-scrolling-on-that-wheel-.png)

With just this change, the background scrolling has been prevented, the focus remains in the modal, and we can close it with the escape key.

We can simplify our implementation even further.

We can get rid of the `isOpen` check because now the component can decide for itself whether or not it should be showing.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814236/workshops/multi-style-tailwind-components/images-multi-style_components_03-02-02.mp4/multi-style_components_03-02-02_12_01-08960-we-can-get-rid-of-this-is-open-check.png)

After saving, everything works still works perfectly.

However, when we open the dialogue and try to close it by clicking outside the model, nothing happens. Let's implement that feature.

Scrolling through the Modal code there is a comment for the Modal Panel.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814236/workshops/multi-style-tailwind-components/images-multi-style_components_03-02-02.mp4/multi-style_components_03-02-02_20_01-39160-you-can-see-the-model-panel--which-is-this-panel.png)

The `div` corresponding to the panel can be replaced with `Dialog.Panel`.

This change enables clicking outside of the Modal to close it, since Headless UI knows what's in and out of the panel.

The last update to make is to replace the `h2` with the `Dialog.Title`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814239/workshops/multi-style-tailwind-components/images-multi-style_components_03-02-02.mp4/multi-style_components_03-02-02_25_01-59120-you-can-see-right-now-were-using-a-simple-h2-tag.png)

No visual changes will happen after this change, but looking at the Modal in DevTools will show us that the `h2` now has additional attributes including an `id`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814238/workshops/multi-style-tailwind-components/images-multi-style_components_03-02-02.mp4/multi-style_components_03-02-02_29_02-13640-but-we-also-have-extra-attributes-like-an-id-here.png)

This `id` for the title is pointed to by the `aria-labeled-by` attribute of the Modal wrapper, making this an accessibility win.

Without much effort we've been able to make the modal accessible and more usable.

Now that we have a solid foundation, we can start working on implementing multiple style variants with Tailwind CSS!

Refactoring to use Headless UI

Convert a Modal to a Headless UI Dialog

Currently the Modal's title, body, and actions are all hardcoded.

Before we implement multiple style variants to our modal, let's update the Modal to support dynamic content.

A `ModalProps` type has been provided that includes the `open` and `onClose` props that have been used before. There are new props for the `title` and the `children` which is how content is passed in.

The `actions` prop which gives the modal the `confirm` and optional `cancel` buttons, each accepting their own `label`:

```typescript
type ModalProps = {
  open: boolean
  onClose: () => void
  /*
    ------------------------------
    We've added new props for our Modal title, 
    body (children) and action buttons.
    ------------------------------
  */
  title: string
  children: React.ReactNode
  actions: {
    cancel?: {
      label: string
      action: () => void
    }
    confirm: {
      label: string
      action: () => void
    }
  }
}
```

## Challenge

Your challenge is to update the `<Modal/>` component to accept all of the `ModalProps` when it is called inside of `index.tsx`:

```typescript
// existing code in index.tsx
// add the additional props here!
<Modal open={isOpen} onClose={() => setIsOpen(false)} />
```

You will also need to remove the hardcoded title, body, and actions from the Modal's implementation inside of `modal.tsx` and have it consume the passed in props instead.

Currently the modal has hardcoded contents. In this challenge, you'll update the modal to support dynamic content & buttons, paving the way for multiple styles.

Let's take this conversion step-by-step, starting with the `title` prop.

Inside of `index.tsx` let's add the `title` prop with a string of "hellooooooo":

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814238/workshops/multi-style-tailwind-components/images-multi-style_components_03-03-02.mp4/multi-style_components_03-03-02_3_00-17460-before-it-works--i-need-to-actually-implement-that.png)

In order to make it show up, over in `modal.tsx` we need to replace the hardcoded text with the `title` prop:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814240/workshops/multi-style-tailwind-components/images-multi-style_components_03-03-02.mp4/multi-style_components_03-03-02_4_00-26460-nice--ill-change-this-to-confirm-subscription.png)

That worked, but for the sake of realism I'll update the title to say "Confirm subscription".

Next we can copy the whole Modal body `div` out since we'll be using it for the `children` prop:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814238/workshops/multi-style-tailwind-components/images-multi-style_components_03-03-02.mp4/multi-style_components_03-03-02_9_00-39700-and-here-we-would-use-the-children-prop.png)

Back over in `index.tsx` we need to update the `<Modal/>` component to have open and closing tags.Then we can paste in the body `div` between them:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814241/workshops/multi-style-tailwind-components/images-multi-style_components_03-03-02.mp4/multi-style_components_03-03-02_14_01-00060-the-last-piece-of-the-puzzle-is-our-actions-here.png)

At this point all that's left is the `actions` prop, which TypeScript is pointing out that we are missing.

The first button is for the `confirm` action.

Taking advantage of autocomplete, we can get `actions.confirm.label` without having to type. Let's label it as "Yes please!".

Then for the `onClick` instead of just `onClose` we'll have `actions.confirm.action`.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814240/workshops/multi-style-tailwind-components/images-multi-style_components_03-03-02.mp4/multi-style_components_03-03-02_26_02-07580-you-can-see-that-now-the-button-says-yes--please.png)

Setting up the `cancel` action will work pretty much the same way.

The difference here is that we only want to show the button if `actions.cancel` is present.

To do this we'll add logic to conditionally render it:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678814239/workshops/multi-style-tailwind-components/images-multi-style_components_03-03-02.mp4/multi-style_components_03-03-02_31_02-45380-this-is-awesome.png)

With these changes our Modal supports dynamic content!

Now that we've got an accessible modal working, it's time to start implementing multiple style variants.

Add a dynamic title and actions to a Modal component using props and conditional rendering in TypeScript

Refactoring for Dynamic Modal Contents

Update the Modal to Support Dynamic Contents

In this challenge, we'll add support for a size prop to our modal component. We have three toggle buttons: small, medium, and large. Currently, they all display the same modal size.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997228/workshops/multi-style-tailwind-components/images-multi-style_components_03-04-01.mp4/multi-style_components_03-04-01-00currentmodal.jpg)

Challenge Your challenge is to implement new modal size variants:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997227/workshops/multi-style-tailwind-components/images-multi-style_components_03-04-01.mp4/multi-style_components_03-04-01-00targetsizes.jpg)

In our modal component, we've added a new prop called size, which can receive small, medium, or large.

We also have a sizeClasses object, typed as a record using the size prop.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997225/workshops/multi-style-tailwind-components/images-multi-style_components_03-04-01.mp4/multi-style_components_03-04-01_4_00-30760-we-have-this-size-classes-object-here-.png)

Your job is to populate the sizeClasses object with the appropriate classes so that our three modals are displayed at the correct size.

Add support for different modal sizes by implementing new size variants using a size prop and sizeClasses object

We have a new `size` prop for the `Modal` component that can be `small`, `medium`, or `large`.

Our goal is to dynamically apply the appropriate max width container class depending on the prop value.

The `Dialog.Panel` inside of the `Modal` component is where we'll be applying the max width container:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997226/workshops/multi-style-tailwind-components/images-multi-style_components_03-04-02.mp4/multi-style_components_03-04-02_7_00-27700-and-to-me--this-is-the-class-that-we-need-to-make-dynamic.png)

Notice that `sm:max-w-lg` tells us that there is no max width container by default. It's only applied from the small breakpoint and up.

This is what we will replace with our size props.

Now that we know where our changes will take place, we'll populate the `sizeClasses` object using the different max widths:

```typescript
const sizeClasses: Record<ModalProps['size'], string> = {
  small: 'sm:max-w-sm',
  medium: 'sm:max-w-lg',
  large: 'sm:max-w-2xl',
}
```

Next we'll make the entire `className` for the `Dialog.Panel` dynamic by adding the `cx()` function with `sizeClasses[size]` and deleting the hardcoded `sm:max-w-lg` class:

```typescript
<Dialog.Panel
  className={cx(
    'relative w-full overflow-hidden rounded-lg bg-white text-left shadow-xl sm:my-8',
    sizeClasses[size]
  )}
>
  ...
```

With these changes in place, let's verify the results:

**Small modal: **

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678999659/workshops/multi-style-tailwind-components/images-multi-style_components_03-04-02.mp4/multi-style_components_03-04-02-small.jpg)

**Medium modal: **

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678999659/workshops/multi-style-tailwind-components/images-multi-style_components_03-04-02.mp4/multi-style_components_03-04-02-medium.jpg)

**Large modal: **

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678999659/workshops/multi-style-tailwind-components/images-multi-style_components_03-04-02.mp4/multi-style_components_03-04-02-large.jpg)

Everything is working as expected!

Use the size prop to dynamically apply max width container class to the Modal component based on small, medium, or large values

Dynamic Modal Sizes

Add Multiple Modal Sizes

In this section, we'll be implementing a `tone` prop for our buttons that will change the color of the `Modal` background.

Here are three buttons that suggest different tones:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997227/workshops/multi-style-tailwind-components/images-multi-style_components_03-05-01.mp4/multi-style_components_03-05-01_2_00-08300-this-is-the-default-tone.png)

Currently, all of them launch a modal with the default tone:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997228/workshops/multi-style-tailwind-components/images-multi-style_components_03-05-01.mp4/multi-style_components_03-05-01_4_00-14020-what-we-want-them-to-look-like-is-like-so.png)

We want the `default` tone to stay as it is now, but add a red tint for `danger` and a green tint for `success`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997228/workshops/multi-style-tailwind-components/images-multi-style_components_03-05-01.mp4/multi-style_components_03-05-01_6_00-22660-and-the-success-tone-has-this-green.png)

The `tone` prop for the buttons is now being used by the `Modal`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997227/workshops/multi-style-tailwind-components/images-multi-style_components_03-05-01.mp4/multi-style_components_03-05-01_10_00-45700-you-can-see-at-the-top-of-the-file-here-.png)

## Challenge

Your task is to populate this new `toneClasses` object:

```typescript
/* 
  ------------------------------
  TODO: Populate the `toneClasses` object below with 
  the appropriate keys. Figure out where to use
  these dynamic classes, so the modal shows
  the correct `tone` styles.
  ------------------------------
*/
const toneClasses: Record<ModalProps['tone'], string> = {}
```

You'll also need to figure out where in the `Modal` to add the `toneClasses`.

The modal can be updated to allow for different background tint colors.

We need to change the background overlay color as well as the button colors.

First, let's examine the markup for the `Modal` and focus on the background overlay.

The `bg-indigo-300` class should be updated to be dynamic.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997230/workshops/multi-style-tailwind-components/images-multi-style_components_03-05-02.mp4/multi-style_components_03-05-02_4_00-15180-so-here-it-is--and-this-class-here--bgindigo300-.png)

Next, we'll modify the `tone` classes object:

The `default` will be `bg-indigo-300`, `danger` will be `bg-red-300`, and `success` will be `bg-green-300`:

```typescript
const toneClasses: Record<ModalProps['tone'], string> = {
  default: 'bg-indigo-300',
  danger: 'bg-red-300',
  success: 'bg-green-300',
}
```

Now in the background overlay section we'll replace the hard-coded `className` with the `cx` function and pass along the `tone` class with `toneClasses[tone]`:

```typescript
// inside the Modal
<Dialog open={open} onClose={onClose} className="relative z-10">
  {/* Background overlay */}
  <div
    className={cx('fixed inset-0 bg-opacity-75 transition-opacity', toneClasses[tone])}
  ></div>
  ...
```

The `Modal` now has a dynamic background overlay color depending on the `tone`, but the buttons are still using the default tone:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997229/workshops/multi-style-tailwind-components/images-multi-style_components_03-05-02.mp4/multi-style_components_03-05-02_11_01-06660-and-here-you-might-start-thinking-.png)

But remember, the button component has a `tone` prop!

This means that instead of passing classes to style the buttons, we can pass the `tone` prop to the button component.

Let's pass the `tone` prop to the action buttons:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997229/workshops/multi-style-tailwind-components/images-multi-style_components_03-05-02.mp4/multi-style_components_03-05-02_button-tone.jpg)

Now, our modals have dynamic background overlays and button colors:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997229/workshops/multi-style-tailwind-components/images-multi-style_components_03-05-02.mp4/multi-style_components_03-05-02_success.jpg)

Everything works great!

Add Modal Background Color Support

Implement Modal Background Tints

Let's make our modal appear and disappear more smoothly by using Headless UI's transition components.

There are two different animations that will enhance the Modal:

1. A fade-in for the background overlay
2. A subtle slide-in from the bottom for the modal panel

## Challenge

Your challenge is to implement these animations using Headless UI's `Transition` component, which has already been imported.

Enter and leave transitions will need to be added for both the background overlay and the dialogue panel.

The background overlay should fade in on enter and fade out on leave, while the Dialog panel should slide in from the bottom and fade out on leave.

To orchestrate both animations, you'll need to use a `Transition.Root` component.

Check out [the ,`Transition`, docs](https://headlessui.com/react/transition) for help!

Use Headless UI's Transition component to create fade-in and slide-in animations for modals on enter and leave. Challenge yourself!

The first step is to wrap the `Dialog` component in a `<Transition.Root>`, along with a `show` prop that will be equal to `open`:

With this change we can remove `open` from the `Dialog` since the `Transition.Root` will track it:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997231/workshops/multi-style-tailwind-components/images-multi-style_components_03-06-02.mp4/multi-style_components_03-06-02_6_00-37040-that-information-from-the-transition-component.png)

Here's what the code looks like:

```typescript
{/* Background overlay */}
<Transition.Child
  enter="transition ease-out"
  enterFrom="opacity-0"
  enterTo="opacity-100"
  leave="transition ease-in"
  leaveFrom="opacity-100"
  leaveTo="opacity-0"
>
```

The modal still opens and closes, so we can start adding animations starting with the background overlay.

## Animating the Background Overlay

The background overlay `div` will be wrapped in a `<Transition.Child>`, which takes several props that set the animation options: `enter`, `enterFrom`, `enterTo`, `leave`, `leaveFrom`, and `leaveTo`.

Each of the animation prompts will take in Tailwind classes that will be present during the entire lifecycle:

* `enter` will have `transition` and `ease-out`
* `enterFrom` will have `opacity-0`
* `enterTo` will have `opacity-100`.

With these changes the background fades in slowly when opening the modal, but then disappears instantly.

This means that the `leave` classes will be essentially the opposite of enter:

* `leave` will have `transition` and `ease-in`
* `leaveFrom` will have `opacity-100`
* `leaveTo` will have `opacity-0`

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997233/workshops/multi-style-tailwind-components/images-multi-style_components_03-06-02.mp4/multi-style_components_03-06-02_20_02-06560-that-feels-a-little-bit-odd--especially-on-leave-.png)

Now the background overlay animates well, but the panel appears and disappears abruptly which feels odd in contrast.

## Animating the Modal Dialog Panel

The steps to animate the panel are similar to the background.

First we need to wrap the modal panel with `<Transition.Child>`, which we can copy and paste from the background overlay to save time.

In order to make the panel slide in from the bottom, we'll need to change the enter props:

* `enter` will still have `transition` and `ease-out`
* `enterFrom` will have `translate-y-8`
* `enterTo` will have `translate-y-0`

To add some delight to the leave animation, we can have it scale down in size by adjusting the props:

* `leave` will still have `transition` and `ease-in`
* `leaveFrom` will have `opacity-100` and `scale-100`
* `leaveTo` will have `scale-95`

Here's the changes for the modal panel:

```typescript
{/* Modal panel */}
<Transition.Child
  enter="transition ease-out"
  enterFrom="opacity-0 translate-y-8"
  enterTo="opacity-100 translate-y-0"
  leave="transition ease-in"
  leaveFrom="opacity-100 scale-100"
  leaveTo="opacity-0 scale-95"
>
```

As a result of these changes, the background overlay fades in and out, while the dialogue panel slides in from the bottom and scales down on leave.

It looks great!

Learn how to use Headless UI's Transition component to animate a modal's background overlay and dialog panel on open and close.

Animating Customize  Modals

Transitioning Modals with Headless UI

Now we want to provide more control over the slide-in animation for the modal panel.

Users should be able to decide if the panel comes in from the bottom, the right, the top, or the left.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997230/workshops/multi-style-tailwind-components/images-multi-style_components_03-07-01.mp4/multi-style_components_03-07-01_2_00-26000-in-our-model-components--you-know-the-drill--there-is-now-a-new-slide-from-prop-.png)

Currently, we have four model toggles, but as of now only the "from bottom" is honoring the `slideFrom` prop-- everything comes in from the bottom.

Over in the code the Modal component has a new `slideFrom` prop, which can be set to `top`, `right`, `bottom`, or `left`:

```typescript
slideFrom?: 'top' | 'right' | 'bottom' | 'left' 
```

There is also a style object called `slideFromClasses` that needs to be populated.

The `slideFromClasses` object is a record with an object shape of `from` and `to` classes:

```typescript
const slideFromClasses: Record<ModalProps['slideFrom'], { from: string, to: string }> = {}
```

## Challenge

Your task is to fill in the `slideFromClasses` object with the appropriate Tailwind classes to make the slide-in animations work as expected.

Good luck!

Learn how to customize the slide-in animation direction of your modal panel using the slideFrom prop and slideFromClasses object in Tailwind CSS.

In order to populate the `slideFromClasses` object, we need to figure out which elements to apply Tailwind classes to.

We can find these in the second `<Transition.Child>`, which is the modal panel.

The "slide from" concern lives in the `enterFrom` and `enterTo` attributes, specifically in the `translate` classes.

Our current behavior has the panel coming in from the bottom, which uses `translate-y-8`.

So if we add a `-` in front to make it `-translate-y-8`, the translate will come from the top.

Using `translate-x-8` will come in from the right, so `-translate-x-8` will come from the left.

In all cases, the `to` value should be `0`.

Let's fill out the `slideFromClasses` going clockwise:

```typescript
const slideFromClasses: Record<ModalProps['slideFrom'], { from: string; to: string }> = {
  top: {
    from: '-translate-y-8',
    to: 'translate-y-0',
  },
  right: {
    from: 'translate-x-8',
    to: 'translate-x-0',
  },
  bottom: {
    from: 'translate-y-8',
    to: 'translate-y-0',
  },
  left: {
    from: '-translate-x-8',
    to: 'translate-x-0',
  },
}
```

In order to have these changes take effect, we'll update the modal panel's `<Transition.Child>` to use the `cx` function to combine the `slideFromClasses`.

For the `enterFrom` we will need to access the nested `from` property from the `slideFromClasses`, and do the same for the `to` classes.

Here's what the changes look like all together:

```typescript
{/* Modal panel */}
<Transition.Child
  enter="transition ease-out"
  enterFrom={cx('opacity-0', slideFromClasses[slideFrom].from)}
  enterTo={cx('opacity-100', slideFromClasses[slideFrom].to)}
  leave="transition ease-in"
  leaveFrom="opacity-100 scale-100"
  leaveTo="opacity-0 scale-95"
>
```

Now we can verify from our buttons each "from" variation slides from the direction we expect!

Populating slideFromClasses with -translate-y-8, translate-x-8 or translate-y-8 to slide modal from top, left or bottom.

Animate Modal Panel Slide-In

Customizing Modal Slide-In Animation

Now we're going to add support for asynchronous tasks in our modal component.

A new `isLoading` prop has been added to the modal:

```typescript
isLoading?: boolean 
```

This prop is a Boolean that indicates whether a loading spinner should be displayed or not.

Note that the modal component is not responsible for handling the loading logic-- it just will receive the `isLoading` prop which can be true or false.

The `LoadingSpinner` component is a rotating svg that has been added at the bottom of `modal.tsx`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997232/workshops/multi-style-tailwind-components/images-multi-style_components_03-08-01.mp4/multi-style_components_03-08-01_3_00-26200-so-heres-the-model-were-working-with-.png)

We have a new dialog that simulates deleting an account. When the user clicks the confirm action button, the `LoadingSpinner` should be displayed to simulate the action happening, but it's currently not wired up.



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997231/workshops/multi-style-tailwind-components/images-multi-style_components_03-08-01.mp4/multi-style_components_03-08-01_5_00-35060-currently--nothing-happens--and-were-going-to-wire-that-all-up.png)

## Challenge

Your challenge is to update the modal to display the `LoadingSpinner` component inside of the Confirm button when `isLoading` is `true`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997232/workshops/multi-style-tailwind-components/images-multi-style_components_03-08-01.mp4/multi-style_components_03-08-01_7_00-47300-and-youll-then-need-to-go-in-the-index-page-where-were-consuming-the-model-component.png)

The `isLoading` state has been added inside of `index.tsx` where we consume the `Modal` component.

The `action` for the confirm button has also been updated to be a `handleConfirm` function:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997232/workshops/multi-style-tailwind-components/images-multi-style_components_03-08-01.mp4/multi-style_components_03-08-01_10_01-00100-you-can-see-here-were-calling-handleconfirm.png)

You will need to write out the body of the `handleConfirm` function.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997232/workshops/multi-style-tailwind-components/images-multi-style_components_03-08-01.mp4/multi-style_components_03-08-01_11_01-05400-so-your-job-is-to-use-that-isloading-piece-of-state-inside-the-handleconfirm-function.png)

Use the `isLoading` state inside of `handleConfirm` to display the `LoadingSpinner` accordingly. A `setTimeout` has already been added to simulate a two second async operation.

When everything is wired up correctly, clicking the "Yes, delete my account" button should display a loading spinner for two seconds before closing the modal.

Adding an animated loading spinner that is conditionally displayed during a simulated async brings a nice touch to the modal interaction.

Let's start by displaying the `<LoadingSpinner>` component in the action button just to see how it looks.

We can upload the code to add the component to the button:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997233/workshops/multi-style-tailwind-components/images-multi-style_components_03-08-02.mp4/multi-style_components_03-08-02_4_00-20980-lets-take-a-look.png)

Then see it rendered in our page view:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997232/workshops/multi-style-tailwind-components/images-multi-style_components_03-08-02.mp4/multi-style_components_03-08-02_7_00-27460-and-it-should-only-show-up.png)

Since we want the spinner to show only when the `isLoading` state is true, we'll add logic to conditionally display it:

```html
{isLoading && <LoadingSpinner />} 
```

In order to wire up the component, we need to pass the `isLoading` state to our modal component:

```html
<ModalComponent
  // other props
  isLoading={isLoading}
  ...
/>
```

Now let's move on to the `handleConfirm` function.

When we click the `confirm` button, we want to set the `isLoading` state to be true.

The we will simulate an asynchronous operation for 2 seconds, and then close the modal.

In order to make sure the loading spinner goes away, we'll also have to set `isLoading` to `false` at the end of the async function.

Here's what the function looks like all together:

```typescript
  function handleConfirm() {
    setIsLoading(true)

    setTimeout(() => {
      setIsLoading(false)
      setIsOpen(false)
    }, 2000)
  }
```

With these changes the operation mostly works, but there's a glitch where the spinner disappears before the modal finishes closing.

We get this glitch because of the transitions we have that fade out the modal slowly instead of disappearing abruptly.

Ideally what we would want is to set `isLoading` to false after the transition has happened.

It just so happens that Headless UI's `Transition` component has an `afterLeave` prop which can be used for this exact scenario!

Conditionally Display a Loading Animation 

Add Support for Async Tasks in the Modal

We want the loading spinner to persist until the modal completely disappears.

In order to achieve this, we will use the `afterLeave` lifecycle event prop for Headless UI's `Transition` component.

The `afterLeave` prop is a perfect fit for our use case, as it allows running code at the end of the leave transition when the modal completely disappears.

However, it's important that the modal component does not handle the logic of whether it should be loading or not. Remember, it receives an `isLoading` prop.

```typescript
// We don't want to use `afterLeave` like this
<Transition.Root show={open} afterLeave={() => setLoading(false)}>
```

In order to handle the loading logic, we want to emit a signal back to the parent component.

We can do this by creating a sister event called `onCloseComplete` that is similar to the existing `onClose` event, but will be marked as optional.

For now we'll give it a default value of a function that returns an empty object:

```typescript
type ModalProps = {
  open: boolean
  onClose: () => void
  onCloseComplete?: () => {};
  ...
}
```

Now for the `<Transition.Root>` we can use `onCloseComplete` as our event emission to the parent, and set it as the callback for `afterLeave`:

```typescript
<Transition.Root show={open} afterLeave={onCloseComplete}>
```

Back in our `index.tsx` file, we can remove the `setIsLoading(false)` from the `handleConfirm` function and pass a new `onCloseComplete` function where `setIsLoading` will be called from instead:

```typescript
<Modal
  // other props
  onCloseComplete={() => setIsLoading(false)}
/>
```

Now, when we click the button, the loading spinner will persist until the end, and `isLoading` will be set back to false after the modal's close transition is complete.

This provides a much smoother user experience!

The Headless UI Transition component supports lifecycle event props that allow for state updates when a transition is completed.

Updating State After a Transition

Our modal looks good, but it still has some issues.

First, if a user triggers the async action then cancels it immediately, if they reopen the modal within the two-second timeout, it will unexpectedly closes again.

Another issue is that users can close the modal during the async action by clicking outside or hitting the escape key, which causes confusion about whether the action was performed.

## Challenge

Your challenge is to resolve these issues by implementing the following improvements:

First, disable the action buttons while the `isLoading` state is true in order to prevent multiple clicks on the action.

Next, you'll need to lock or freeze the modal while it's in its loading state by disabling the ability to close it by clicking outside or hitting the escape key.

Both changes will take place inside the code for the modal.

Currently the modal can be exited during the async operation, which could cause confusion. Disabling this functionality will make for a better UX

Let's start by disabling buttons and prevent the modal from closing when the `isLoading` state is true.

Inside of the modal we'll add the `disabled` attribute to both buttons, and set its value to the `isLoading` prop:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997226/workshops/multi-style-tailwind-components/images-multi-style_components_03-09-02.mp4/multi-style_components_03-09-02_3_00-20160-which-seems-to-be-exactly-what-we-want.png)

We can confirm they aren't clickable by opening the modal:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997226/workshops/multi-style-tailwind-components/images-multi-style_components_03-09-02.mp4/multi-style_components_03-09-02_4_00-24000-and-yeah--you-can-see-theyre-disabled.png)

Next we'll prevent closing the modal when clicking outside or pressing the escape key while `isLoading` is true.

Inside of the `Dialog` component inside the modal, the `onClose` prop is triggered when clicking outside or pressing the escape key.

As a test, we can set `onClose` to an empty function in oder to completely disable closing the modal:

```html
<Dialog
  onClose={() => {}}
  /...
>
```

Since we only want to disable this functionality when `isLoading` is true, we can use a ternary operator to conditionally provide the `onClose` function:

```html
<Dialog onClose={isLoading ? () => {} : onClose}>
```

Now, if the modal is not loading, you can close it by clicking outside or pressing the escape key. But while it's loading, these actions won't close the modal.

These two quick fixes help us to prevent users from encountering unwanted scenarios.

Disabling Buttons and Modal Exits While Loading

Improve Modal Behavior During Async Operation

To wrap up this section, let's discuss state management patterns in relation to the modal component.

In our current implementation, we have two boolean props `open` and `isLoading`.



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997226/workshops/multi-style-tailwind-components/images-multi-style_components_03-10-01.mp4/multi-style_components_03-10-01_5_00-19640-we-literally-have-an-ease-open-piece-of-state-and-an-ease-loading-piece-of-state.png)

These props are managed independently, but both determine the modal's state.

This can potentially lead to broken or unexpected states, such as a "closed but loading" modal.

When complexity creeps in, it may become necessary to add more states. Also, working with multiple booleans can be limiting and may result in strange behavior like we saw previously.

A better approach would be to use a single property like an enum to represent all possible modal states. This would provide a finite and predictable list of states, with only one at a time able to be active.

This would replace the `open` and `isLoading` properties.

For example, we could have a `status` prop that would be open, closed, or loading:

```typescript
status: 'OPEN' | 'CLOSED' | 'LOADING' 
```

The `'OPEN'` status would be the same as `open=true` and `isLoading=false`.

The `'CLOSED'` status would be `open=false` and `isLoading=false`

And the `'LOADING'` status would be `open=true` and `isLoading=true`.

This approach eliminates the risk of having a closed but loading modal and makes the component more scalable and future-proof.

It also allows for handling additional scenarios, such as error states or a stalled state when the loading takes longer than expected.

State management has implications not only on an application's functionality, but also on its styling.

In the next section we will refactor some messy, complext code that uses multiple boolean props for styling.

There are multiple possible states for the modal to be in, each with its own associated styling. 

Modal State Management Patterns

To wrap up the workshop, we'll work on refactoring the calendar app built with multi-theme support and multiple style patterns.

There are a lot of styles here including background stripes, corner ribbons, and more.

The calendar days display these differently based on their availability, selection, and disabled state.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997226/workshops/multi-style-tailwind-components/images-multi-style_components_04-01-01.mp4/multi-style_components_04-01-01_7_00-26120-is-this-calendar-here.png)

The initial approach to styling the calendar days involved identifying common classes for all variants, then applying dynamic classes based on the state of the calendar day.

However, the complexity increased when trying to account for all possible edge scenarios, making the code difficult to manage and maintain.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997226/workshops/multi-style-tailwind-components/images-multi-style_components_04-01-01.mp4/multi-style_components_04-01-01_16_01-18720-i-started-to-find-all-these-edge-scenarios.png)

The main reason for this complexity is that a calendar day can be in more than one state simultaneously, which leads to conflicting styles and unpredictable behavior.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997228/workshops/multi-style-tailwind-components/images-multi-style_components_04-01-01.mp4/multi-style_components_04-01-01_31_02-06440-theres-one-major-reason.png)

In this section we will take a similar approach to what we did with the modal, but this time defining a single `status` variant for each calendar day that will apply styles appropriately.

This section of the workshop applies what we've learned toward refactoring how styles are managed and applied to the Multi-Theme Calendar Demo App.

Calendar Style Complexity

Here is an example of two of the calendar components side by side.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997227/workshops/multi-style-tailwind-components/images-multi-style_components_04-02-01.mp4/multi-style_components_04-02-01_6_00-21160-whereas-the-one-on-the-right-has-availabilities-today.png)

## Challenge

For this challenge, you need to identify the possible visual states for a calendar day. Two calendar instances are provided, differing only in availability for the current date.

Play around with the calendars and take note of different visual styles for each day.

For example, the "selected" state is one visual state a calendar day can have.

The calendar on the left has availability for December 12, but the calendar on the right does not.

Based on your observations, you will create a list of possible visual states. In the code, a new type called `Status` has been created with the "selected" state already added. Your task is to complete the list by adding other visual states you identify from the calendars.

Here's the starting point inside `calendar-day.tsx`:

```typescript
type Status = 'SELECTEDT '| 'STATUS_TWO' | '...' 
```

Explore the calendars and add the remaining visual states to the `Status` type based on your findings.

Identifying the possible states for a calendar day is the first step in managing multiple style variants.

There are five different statuses for calendar days that I have come up with to visually differentiate the days:

1. **Selected**: This status indicates the day that is currently selected by the user.
2. **Disabled**: Days in the past or out-of-range days that cannot be selected by the user are considered disabled.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997227/workshops/multi-style-tailwind-components/images-multi-style_components_04-02-02.mp4/multi-style_components_04-02-02_6_00-23940-and-these--you-can-see--i-cannot-select.png)

1. **Vacancy**: Days with availability are given the vacancy status. This status is applied even if the day is today, as long as there is availability.
2. **No Vacancy**: This status is assigned to days that do not have any availability.
3. **Today No Vacancy**: This special status is applied to the current day when there's no vacancy. It is styled differently compared to other no vacancy days. In this screenshot, the 12th matches this status:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997227/workshops/multi-style-tailwind-components/images-multi-style_components_04-02-02.mp4/multi-style_components_04-02-02_16_01-04680-you-can-see-that-its-styled-differently.png)

These five statuses should cover most scenarios for visually styling calendar days.

It is important to note that a calendar day can only have one status at a time!

Listing the Calendar States

Identify Possible Calendar States

Here we have a table for properly displaying the different day status styles for disabled, vacancy, no vacancy, selected, and today.



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997229/workshops/multi-style-tailwind-components/images-multi-style_components_04-03-01.mp4/multi-style_components_04-03-01_4_00-17400-whereas-the-table-on-the-left.png)

The reference table on the right has all the styles hard-coded for every calendar day.

The table on the left is set up to use dynamic classes, but it is currently missing styles.

## Challenge

Your challenge is to update the code for the calendar on the left so its styles display properly.

The `Status` type has been brought over, and we have our `baseClasses` in place:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997229/workshops/multi-style-tailwind-components/images-multi-style_components_04-03-01.mp4/multi-style_components_04-03-01_10_00-36200-that-weve-created-in-the-previous-lesson.png)

Your job is to populate the `statusClasses` object that uses the `Status` type, porting over classes from the `dynamicClasses`.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997229/workshops/multi-style-tailwind-components/images-multi-style_components_04-03-01.mp4/multi-style_components_04-03-01_17_00-59140-and-so-your-job-is-to-populate-this-object.png)

The table has already been set up to compose classes with `cx()` and the `statusClasses`, so you won't need to touch that markup:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997229/workshops/multi-style-tailwind-components/images-multi-style_components_04-03-01.mp4/multi-style_components_04-03-01_21_01-10520-these-status-classes-that-do-not-exist-yet.png)

Once you fill in the `statusClasses` object, the table on the left will match the reference table on the right.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997228/workshops/multi-style-tailwind-components/images-multi-style_components_04-03-01.mp4/multi-style_components_04-03-01_26_01-23160-the-status-classes-lookup-object-correctly-good-luck.png)

Creating a lookup object containing the specific states and their associated Tailwind CSS classes will keep code organized.

Let's start by adding the correct keys in the `statusClasses` object and update the styles accordingly.

We'll start by initializing the keys with empty strings:

```typescript
const statusClasses: Record<Status, string> = {
  SELECTED: '',
  DISABLED: '',
  VACANCY: '',
  NO_VACANCY: '',
  TODAY_NO_VACANCY: ''
};
```

Next, we will copy the styles from the dynamic classes object to the corresponding keys:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997231/workshops/multi-style-tailwind-components/images-multi-style_components_04-03-02.mp4/multi-style_components_04-03-02_16_01-34660-and-with-a-bit-of-luck--because-as-youve-seen-.png)

After updating the styles, let's check the reference tables to make sure everything is working properly:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997230/workshops/multi-style-tailwind-components/images-multi-style_components_04-03-02.mp4/multi-style_components_04-03-02_19_01-43960-so-this-is-great.png)

Now that our styles are working, we can proceed with implementing the logic to determine which status a day should be in.

Create Styles for the Unique States

Porting Dynamic Styles to Specific States

The original `statusClasses` object did not have mutually exclusive variants, which led to some messy logic.

But now that we have a list of finite and mutually exclusive status style variants, which should help us reduce the complexity.

Now we need to determine the status of a given calendar day.

Previously in the workshop when working with buttons and the modal, we had clear distinctions between each variant. A component would receive a prop, and we could match it with the variant styles.

For the calendar, we're likely going to need to use conditional logic.

We already have our `styles` lookup object, so we just need to know which one to reach for.

Writing a `getStatus` function that returns one of the possible status variants would work well in this case.

Our `Status` type and `baseClasses` are in place:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997234/workshops/multi-style-tailwind-components/images-multi-style_components_04-04-01.mp4/multi-style_components_04-04-01_15_01-16240-youll-see-that-we-have-our-status-type.png)

We also have the `statusClasses` we created:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997234/workshops/multi-style-tailwind-components/images-multi-style_components_04-04-01.mp4/multi-style_components_04-04-01_16_01-24960-but-we-also-have-the-new-status-classes-weve-worked-on.png)

In the UI, we have a reference calendar showing how the styled calendar should look, and another calendar rendered by the code we just looked at, which only has the base classes for every calendar day.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997230/workshops/multi-style-tailwind-components/images-multi-style_components_04-04-01.mp4/multi-style_components_04-04-01_21_01-35860-and-on-the-left--this-is-the-calendar-rendered.png)

## Challenge

Your challenge is to determine the status of any given day.

Once you have the status, you'll be able to replace the complex logic in the `className` attribute with a simplified call to `cx()` to combine the `baseClasses` with the correct `statusClasses[status]` classes.

Hint: here's how to define the `getStatus` function in TypeScript:

```typescript
const getStatus: () => Status = () => { } 
```

Writing a helper function for determining the current calendar state removes the need for conditional className logic

Let's create a `getStatus` function to handle the calendar day statuses in the app.

We'll define the function like so:

```typescript
const getStatus: () => Status = () => { } 
```

We know that there are five possible statuses: `SELECTED`, `DISABLED`, `VACANCY`, `NO_VACANCY`, and `TODAY_NO_VACANCY`.

Looking at the `CalendarDay` component we can see how the styles are determined.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997234/workshops/multi-style-tailwind-components/images-multi-style_components_04-04-02.mp4/multi-style_components_04-04-02_23_01-37160-and-so-these-are-going-to-make-our-job-easy.png)

The `isSelected` and `isDisabled` variables show us how to take care of these two statuses, and the `hasAvailability` variable matches with `VACANCY`.

Therefore, to determine our last state we can check `isCurrentDay` then conditionally return the appropriate status for no `NO_VACANCY`.

Here's what the function looks like all together:

```typescript
  const getStatus: () => Status = () => {
    if (isSelected) return 'SELECTED'
    if (isDisabled) return 'DISABLED'
    if (hasAvailability) return 'VACANCY'
    return isCurrentDay ? 'TODAY_NO_VACANCY' : 'NO_VACANCY'
  }
```

Now, we can use the `getStatus` function to get the correct status for each calendar day:

```javascript
const status: Status = getStatus(); 
```

With this `status` variable, we can simplify our calendar day component by applying the appropriate styles from the `statusClasses` object:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997235/workshops/multi-style-tailwind-components/images-multi-style_components_04-04-02.mp4/multi-style_components_04-04-02_60_04-43340-whereas-the-calendar-on-the-left.png)

Checking the calendar, we can see that everything is working as expected!

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1678997233/workshops/multi-style-tailwind-components/images-multi-style_components_04-04-02.mp4/multi-style_components_04-04-02_64_05-00540-and-so-now-that-everything-is-working-.png)

This approach makes our calendar day component much cleaner and more manageable, and we are able to remove several lines of old conditional logic.

The `getStatus` function handles the complexity of determining the correct status, while the `statusClasses` object allows us to easily apply the correct styles.

This technique is scalable, flexible, and can be used for a variety of use cases.

Implementing the getStyles Function

Apply Styles for a Specific State

Congratulations, you've reached the end of this Multi-Style Tailwind components module!

You can now carry this style lookup directory approach to your specific projects using reusable components styled with Tailwind CSS.

You are now prepared to handle just about any multi-style variants challenges you can think of!

Thank you for your support, and I hope you have a great day!

The style lookup object approach practiced in this workshop can be applied to any of your future Tailwind CSS projects.

Multi-Style Tailwind Components

Professional Workshop

Welcome to the Multi-Theme Strategy Workshop!

In this workshop, we are going to combine two superpowers:

1. CSS Custom Properties, aka CSS Variables  
2. Tailwind's JavaScript Plugin API

These are the two key ingredients that will let us build a comprehensive CSS-only theming strategy.

We'll start with a little primer on CSS variables, and then jump right into building our theming implementation.

Let's have some fun!

In this workshop, we will learn how to use CSS Custom Properties and Tailwind's JavaScript Plugin API to build a comprehensive CSS-only theming strategy.

Intro to the Multi-Theme Strategy Workshop

In this workshop, we're going to start simple and build upon our foundation step by step.

We are going to do a lot of copy-pasting of repetitive code, and the first passes will be naive implementations.

But don’t worry!

The idea is to keep things intentionally simple to start. We'll be improving our code for re-usability as we go.

There won’t be any clever loops or recursion before they're needed, but trust me, they're coming!

This workshop's approach is to start with the basics and gradually build upon them, focusing on fundamental concepts before moving to more robust approaches.

Incrementally Introducing Complexity

We start by looking at `themes.cjs`.

This file exports a `theme` object with three sets of colors: `base`, `rainforest`, and `candy`:

```tsx
module.exports = {
  base: {
    50: "#eef2ff",
    // ...
    900: "#272173",
  },
  rainforest: {
    50: "#ecfdf4",
    // ...
    900: "#003422",
  },
  candy: {
    50: "#fdf2f8",
    // ...
    900: "#590028",
  },
}
```

Note that we are sticking to Tailwind's `50` to `900` color shade naming strategy.

It's not required, but since we want to implement the multi-theme strategy to an existing app, it will make it easier to swap colors using the same names.

## Hue Tone

To create these colors, I've used an online tool called [Hue Tone](https://huetone.ardov.me/):

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216464/workshops/multi-theme-strategy-workshop/01-01-03-starting_point_8_00-45120-so-we-have-three-colors-ranging-from-50-to-900.png.png)

We have our three colors ranging from 50 to 900. The numbers in each column are matching for each color shade.

The Accessible Perceptual Contrast Algorithm (**APCA**) contrast is displayed, which is the perceived contrast algorithm. For more details on APCA, [check out the docs](https://git.apcacontrast.com/).

By having numbers that match, colors will retain a consistent contrast when switching between themes.

## The Theme Starting Point

For now, we aren’t doing any theming at all, but we do have the three color sets extended in `tailwind.config.cjs`:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  theme: {
    extend: {
      colors: {
        base: themes.base,
        rainforest: themes.rainforest,
        candy: themes.candy,
      },
    },
  },
  plugins: [],
}
```

What we want is to be able to use the same color utility class across all themes. We should be able to find the value of the individual colors based on the current active theme.

To do this, we're going to leverage the power of CSS variables.

We start with definitions for three sets of colors that are extended in the Tailwind config, but they don’t do any theming yet.

Our App’s Tailwind Configuration Starting Point

CSS variables are essential to our theming strategy.

You can define a CSS variable with `--` + your desired variable name:

```css
:root {
  --variable-name: #6b70fc;
}
```

Note that our variable name will only be available within the scope to which it has been defined.

We're using the `root` scope, which is the entire document, so it's available everywhere.

Now use the variable by calling the `var` function with the `--variable-name` inside of it:

```css
.button {
  background-color: var(--variable-name);
}
```

A great feature of CSS variables is they can be redefined within any CSS selector.

Let's redefine the `--variable-name` to the `deeppink` color within the `.button--pink` selector:

```css
.button--pink {
  --variable-name: deeppink;
}
```

The `deeppink` `--variable-name` will only be available within the `.button--pink` selector.

So `.button` is still using the `--variable-name` value in the `root` scope.

## Challenge

We've got these two shapes here:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216493/workshops/multi-theme-strategy-workshop/01-02-01-css_primer_11_01-06160-were-defining-this-dash-dash-color-variable-at-the-root-scope-where-we-use-that-teal-color.png.png)

The first square has a `class` of `square` and the second has a `class` of `square square--pink`.

But, the second square is currently displaying a teal color.

**Your job is to make the second square pink.**

Currently, we're defining the `--color` variable at the `root` scope using a teal color:

```css
@layer base {
  :root {
    --color: #0099aa;
  }
}
```

Then, in the `.square` class below, we apply that variable to the `background-color` property:

```css
@layer components {
  .square {
    @apply h-16 w-16 rounded-lg;
    background-color: var(--color);
  }

  .square--pink {
    /* TODO: make this square deeppink */
  }
}
```

You need to redefine the `--color` variable within the `.square--pink` selector to the `deeppink` value.

CSS variables are essential for building a theming strategy. This lesson provides a brief explanation on how to define and consume variables.

The solution is pretty simple.

In the `.square--pink` class, we redefine the `--color` variable to the `deeppink` color:

```css
@layer components {
  /* ... */

  .square--pink {
    --color: deeppink;
  }
}
```

Now, the second square is pink:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216519/workshops/multi-theme-strategy-workshop/01-02-02-css_primer_-_solution_1_00-04240-the-solution-is-pretty-simple-here-all-i-had-to-do-is--in-the-square-pink-class-.png.png)



Straightforward, right?

This CSS variable scoping is a foundational piece of our theming strategy, so it’s important to make sure that we're comfortable with it.

Test your understanding of CSS variables by experimenting with different color options and see how it impacts your website design.

Redefining CSS Variables in Different Scopes

A Primer on CSS Variables

So we have these three complete color spreads here:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216541/workshops/multi-theme-strategy-workshop/01-03-01-define_css_variables_3_00-17760-and-theyre-currently-using-the-three-colors-that-we-have-extended-our-tailwind-config-with.png.png)

These spreads are currently using the three colors that we have extended our Tailwind config with:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  theme: {
    extend: {
      colors: {
        base: themes.base,
        rainforest: themes.rainforest,
        candy: themes.candy,
      },
    },
  },
  plugins: [],
}
```

In the HTML you can see that we are using the color classes `text-base`, and `bg-base`:

```html
<div
  class="grid h-16 w-16 place-items-end bg-base-400 p-1
  font-semibold leading-none text-base-900"
>
  400
</div>
```

We’re also using the classes `text-rainforest`, `bg-rainforest`, `text-candy`, and `bg-candy`.

## Challenge

Your challenge is to apply a primary color to each blank color spread without touching any of the HTML markup:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216541/workshops/multi-theme-strategy-workshop/01-03-01-define_css_variables_3_00-17760-and-theyre-currently-using-the-three-colors-that-we-have-extended-our-tailwind-config-with.png.png)

Everything is already using the `bg-primary` and `text-primary` classes.

## Tips

Here are a couple of tips to help you get started.

### Create CSS Variables

First, you'll need to create CSS variables for our primary color shades.

You can name these anywhere from `primary-50` to `primary-900`, but you should start with just `primary-500`.

For your convenience here are each of the primary `500` values:

```
- Base: #6b70fc
- Rainforest: #009268
- Candy: #e13d90
```

You will need to define each of these CSS variables within the `:root` selector.

### Extend the Colors Object

Before anything can work, you will also need to go into your Tailwind config and extend the `colors` object with a new `primary` object.

It is already there, but it is commented out:

```tsx
colors: {
  base: themes.base,
  rainforest: themes.rainforest,
  candy: themes.candy,
  // primary: {}
}
```

### Redefine the Theme Scopes

Lastly, you need to redefine the "theme scopes" CSS variable for each of the themes. You can figure out what these are by looking at the HTML.

If you've done everything correctly, the blank color spreads should now be filled with the correct primary color shades.

Remember, you can't touch the HTML markup!

One way to challenge yourself when using Tailwind CSS is to try applying colors to elements without modifying any HTML markup.

In the CSS file, we start by defining the `:root` scope variables.

We define the `@layer base` and target the `:root` selector. Inside, we'll define the `--primary-500` variable and pass in the `#6b70fc` base color value:

```css
@layer base {
  :root {
    --primary-500: #6b70fc;
  }
}
```

Now that we've defined the variable, we can consume it in our config file:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  theme: {
    extend: {
      colors: {
        base: themes.base,
        rainforest: themes.rainforest,
        candy: themes.candy,
        primary: {
          500: "var(--primary-500)",
        },
      },
    },
  },
  plugins: [],
}
```

On save, notice that the 500 shades have appeared:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216643/workshops/multi-theme-strategy-workshop/01-03-02-defining_css_variables_-_solution_8_00-54480-since-im-already-in-the-config-file--ill-replicate-this-a-couple-of-times.png.png)

Let's implement the other shades between 50 and 900 now starting with the config:

```css
primary: {
  50: "var(--primary-50)",
  100: "var(--primary-100)",
  200: "var(--primary-200)",
  300: "var(--primary-300)",
  400: "var(--primary-400)",
  500: "var(--primary-500)",
  600: "var(--primary-600)",
  700: "var(--primary-700)",
  800: "var(--primary-800)",
  900: "var(--primary-900)",
},
```

Now, define the CSS variable at the root scope here grabbing all the key-value pairs from the `base` object in `themes`:

```css
@layer base {
  :root {
    --primary-50: #eef2ff;
    --primary-100: #e0e7ff;
    --primary-200: #d0d7f7;
    --primary-300: #aab9ff;
    --primary-400: #8994ff;
    --primary-500: #6b70fc;
    --primary-600: #554fee;
    --primary-700: #453ccd;
    --primary-800: #3830a2;
    --primary-900: #272173;
  }
}
```

The variables are titled `--` + primary + `-` + the shade number.

When we hit save, we should see the entire color spread happening:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216651/workshops/multi-theme-strategy-workshop/01-03-02-defining_css_variables_-_solution_14_01-31680-look-at-this--beautiful.png.png)

The problem is that the three spreads are only using the base color, since this is the only color we've defined.

## Define Theme Scopes

We need to figure out how to define our theme scopes.

The theme scope can be any CSS selector. It can be a class name, or a data attribute.

The HTML markup we need to style has a `data-theme` attribute:

```css
<div class="flex overflow-hidden rounded-md" data-theme="base"></div> 
```

We have one for each theme, so we can use the `data-theme` attribute as the theme scope.

Let's try that in our CSS.

We'll use square brackets to target the `data-theme` attribute with a value of `"rainforest"`, and then use the values from the `rainforest` object in `themes`:

```css
[data-theme="rainforest"] {
  --primary-50: #ecfdf4;
  --primary-100: #c9f2de;
  --primary-200: #9de9c6;
  --primary-300: #56d0a0;
  --primary-400: #00b380;
  --primary-500: #009268;
  --primary-600: #007955;
  --primary-700: #006344;
  --primary-800: #005038;
  --primary-900: #003422;
}
```

Let's also duplicate this for `candy`:

```css
[data-theme="candy"] {
  --primary-50: #fdf2f8;
  --primary-100: #f7e2ee;
  --primary-200: #f8cce5;
  --primary-300: #f5a4d0;
  --primary-400: #f271b5;
  --primary-500: #e13d90;
  --primary-600: #c31667;
  --primary-700: #a1004b;
  --primary-800: #84003d;
  --primary-900: #590028;
}
```

And now we have the three color spreads:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216658/workshops/multi-theme-strategy-workshop/01-03-02-defining_css_variables_-_solution_28_02-54320-so-lets-recap-because-this-is-important.png.png)



## Recap

We are defining at the `root` scope CSS variable with a default value, our `base` theme.

Then within theme scope `rainforest` and `candy` we redefined the values for the same CSS variables.

Then, we generate new Tailwind color utilities in our config file.

By default, everywhere in the site will have the `base` theme color, even if there is no `data-attribute`!

But, if we were to opt in another theme scope, like `candy`, we would redefine the css variables to the ones of the `candy` theme.

This applies to nested elements as well:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216664/workshops/multi-theme-strategy-workshop/01-03-02-defining_css_variables_-_solution_37_03-59360-so-you-can-see-that-this-is-super-powerful-and-gives-you-a-lot-of-flexibility.png.png)

At this point, you might think that the challenge is complete, but there's a little problem.

### One Last Thing

In our CSS, we've defined the base color for the `root` scope and then `theme` scopes for `rainforest` and `candy`.

But we don't have a `theme` scope for the `base` theme, which means we can't override other themes with the `base` theme.

Let's add that now:

```css
[data-theme='base'] {
  --primary-50: #eef2ff
  --primary-100: #e0e7ff
  --primary-200: #d0d7f7
  --primary-300: #aab9ff
  --primary-400: #8994ff
  --primary-500: #6b70fc
  --primary-600: #554fee
  --primary-700: #453ccd
  --primary-800: #3830a2
  --primary-900: #272173
}
```

And now we can use `base` to override other themes:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216670/workshops/multi-theme-strategy-workshop/01-03-02-defining_css_variables_-_solution_49_05-12800-and-you-can-see-now-that-our-300-shade-has-been-overriding-the-candy-theme.png.png)

Scoping CSS variables and extending the Tailwind config file are key steps in the journey to a comprehensive theming strategy.

Creating Multiple Color Spreads with CSS Variables

Create Themable Color Shades with CSS Variables

We are creating new themable colors, but in the process we've broken support for color opacity.

We have some default Tailwind colors showing at various degrees of color opacity here:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216679/workshops/multi-theme-strategy-workshop/01-04-01-opacity_support_3_00-13120-showing-at-various-degrees-of-color-opacity-and-you-can-see-everything-look-as-it-should.png.png)

Below those proper colors, we have the same code but using our themable colors.

Things are obviously not working!

To understand why it's not working, we need to figure out how opacity is handled.

If you think about it, there is no such thing in CSS as text opacity or background opacity.

**Tailwind CSS cleverly leverages CSS variables to compose this opacity within the color.**

Hovering over a default color like `.bg-teal-600` you'll see that it sets a `--tw-bg-opacity` variable set to `1`, which is 100% opacity:

```css
.bg-teal-600 {
  --tw-bg-opacity: 1;
  background-color: rgb(13 148, 136 / var(--tw-bg-opacity));
}
```

Then the `background-color` is set and it composes the opacity in the alpha modifier.

If we look at a 70% color, it's using the exact same `.bg-teal-600` class, but it's redefining the `--tw-bg-opacity` variable to `0.7` using `bg-opacity-70`.

We see this when hovering over the `bg-opacity-70` class:

```css
.bg-opacity-70 {
  --tw-bg-opacity: 0.7;
}
```

This is the same mechanism that we've used with our colors, where we would redefine the color variable within a theme scope.

Here, the opacity variable is redefined when we apply a `bg-opacity` class.

This is super clever, and Tailwind CSS is full of these CSS variable composition techniques under the hood.

In multi-theme colors that we've implemented, let's see what happens if we hover over the primary background color:

```css
.bg-primary-600 {
  background-color: var(--primary-600);
}
```

There is no `--tw-bg-opacity` variable, It just applies the CSS variable as the background color.

The `bg-opacity` class sets the `--tw-bg-opacity` variable to `0.7`, but since `bg-primary-600` doesn't use that variable at all, it doesn't work.

Nothing is going to change when the class is applied:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216686/workshops/multi-theme-strategy-workshop/01-04-01-opacity_support_19_02-06160-variable-so-of-course--nothing-is-going-to-change-when-this-class-is-applied.png.png)

When we define colors as CSS variables, all we give Tailwind is the variable name, which is a placeholder that can contain any value:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  theme: {
    extend: {
      colors: {
        base: themes.base,
        rainforest: themes.rainforest,
        candy: themes.candy,
        primary: {
          50: "var(--primary-50)",
          // ...100-800
          900: "var(--primary-900)",
        },
      },
    },
  },
  plugins: [],
}
```

Tailwind is not able to extract the RGB channels from this.

We'll have to do this manually.

Instead of defining colors as hex values, we are going to want to convert them to `R`, `G`, and `B` channels:

```css
@layer base {
  :root {
    --primary-50: #eef2ff;
    --primary-100: #e0e7ff;
    --primary-200: #d0d7f7;
    --primary-300: #aab9ff;
    --primary-400: #8994ff;
    --primary-500: #6b70fc;
    --primary-600: #554fee;
    --primary-700: #453ccd;
    --primary-800: #3830a2;
    --primary-900: #272173;
  }
}
```

## Challenge

Your job is to transform the hex values into individual `R`, `G`, and `B` channels.

Note the extra emphasis on the `R`, `G`, and `B` channels! Literally a string of “R G B”.

Do not use the `rgb` color!

After you've done the transformation, in the config file you will be able to compose the RGB channels with Tailwind's `<alpha-value>` using the `rgb` function like so:

```css
rgb(R G B / <alpha-value>) 
```

The `<alpha-value>` is the exposed equivalent of this `--tw-opacity` variables Tailwind has internally.

The themable colors have broken support for opacity. Converting hex to RGB channels is a key step in fixing it.

## Getting RGB Channels

Let's start by converting the hex value to RGB channels.

Unless you want to do some base16 math in your head, you can use an online tool or a neat little [VS Code extension called Hex to RGBA](https://marketplace.visualstudio.com/items?itemName=dakshmiglani.hex-to-rgba) that does it for you!

By default the extension will transform the hex value to an `rgba` function call, which is not what we want but it's close:

```css
@layer base {
  :root {
    --primary-50: rgba(240, 243, 255, 1);
    /* ...100-900 */
  }
}
```

Using Hex to RGBA, we can select every hex value inside our `styles.css`, and convert them to RGBA all at once.

However, instead of the `rgba` function we want a space-separated string of the R, G and B values:

```css
@layer base {
  :root {
    --primary-50: 238 242 255;
    --primary-100: 224 231 255;
    --primary-200: 208 215 247;
    --primary-300: 170 185 255;
    --primary-400: 137 148 255;
    --primary-500: 107 112 252;
    --primary-600: 85 79 238;
    --primary-700: 69 60 205;
    --primary-800: 56 48 162;
    --primary-900: 39 33 115;
  }
}

/* All themes converted as well */
```

When we save this, it's is going to break our design because we don't have the composed color, only the channels:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216707/workshops/multi-theme-strategy-workshop/01-04-02-opacity_support_-_solution_7_00-42000-because-we-actually-dont-have-the-composed-color-.png.png)

## Compose RGB Channels with Alpha Values

The second step is to go into our Tailwind config and update the way we consume the CSS variables.

Remember that we need to use the `rgb` function, composing the channels along with the `<alpha-value>`:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  theme: {
    extend: {
      colors: {
        base: themes.base,
        rainforest: themes.rainforest,
        candy: themes.candy,
        primary: {
          50: "rgb(var(--primary-50) / <alpha-value>)",
          100: "rgb(var(--primary-100) / <alpha-value>)",
          200: "rgb(var(--primary-200) / <alpha-value>)",
          300: "rgb(var(--primary-300) / <alpha-value>)",
          400: "rgb(var(--primary-400) / <alpha-value>)",
          500: "rgb(var(--primary-500) / <alpha-value>)",
          600: "rgb(var(--primary-600) / <alpha-value>)",
          700: "rgb(var(--primary-700) / <alpha-value>)",
          800: "rgb(var(--primary-800) / <alpha-value>)",
          900: "rgb(var(--primary-900) / <alpha-value>)",
        },
      },
    },
  },
  plugins: [],
}
```

When we save this, we should have full support for opacity.

If we inspect the `.bg-primary-600` class, you can see that we are now composing the `--tw-bg-opacity` variable:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216712/workshops/multi-theme-strategy-workshop/01-04-02-opacity_support_-_solution_14_01-25920-you-can-see-that-now-we-are-composing-this-tw-bg-opacity-variable.png.png)

Explore converting a hex value into RGB channels, and how they can be composed with <alpha-value> in order to support opacity in Tailwind themes. 

Compose RGB Channels with alpha-value for Opacity Support

Implementing Color Opacity with CSS Variables

We've laid out the foundations of a theming strategy, but we can further improve the developer experience.

We're defining our CSS variables in a CSS file, and then we're generating new color utilities in the Tailwind config file.

**It would be nice if we could do both in the same file.**

What if we want to support theming in another project using Tailwind CSS? Do we repeat this process for each new project?

Surely there must be a better way.

**And that way is the Tailwind plugin API.**

With the plugin API you can author your CSS with the full power of JavaScript, and reuse functionality across your projects!

## Challenge

In our `tailwind.config.cjs` file we start with an empty plugins array:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  plugins: [],
}
```

You'll need to use the `plugin` function from `tailwindcss/plugin` to create a simple plugin that generates the following CSS:

```css
body {
  text-transform: uppercase;
}
```

Once the plugin is created, you’ll need to pass this plugin to the `plugins` array.

If the plugin is injecting styles like it should, we'll have a heading with a paragraph below that is all uppercase.

Here’s what the starting point looks like:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216723/workshops/multi-theme-strategy-workshop/01-05-01-plugin_api_12_01-00600-as-a-verification-that-the-plugin-is-working.png.png)

The Tailwind CSS plugin API allows for sharing functionality between multiple projects, making it easier to reuse code and streamline development.


The first step is to import the `plugin` function from `tailwindcss/plugin`:

```tsx
const plugin = require("tailwindcss/plugin") 
```

Now we can call this function inside our `plugins` array. This function gives us another function that allows us to access other functions such as `addBase`, `addComponents`, and `addUtilities`.

We want to inject to the `base` layer so we'll use `addBase` and target the `body` using CSS in JS syntax:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  plugins: [
    plugin(function ({ addBase }) {
      addBase({
        body: {
          // ...
        },
      })
    }),
  ],
  ]
}
```

Once we have the `body` selected we'll add the `textTransform` property and set it to `uppercase`:

```tsx
plugin(function ({ addBase }) {
  addBase({
    body: {
      textTransform: "uppercase",
    },
  })
}),
```

We can see our styles have been properly injected, which means the plugin is working:



![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216732/workshops/multi-theme-strategy-workshop/01-05-02-plugin_api_solution_8_00-47120-and-that-addbase-function-here-is-exactly-what-were-going-to-use.png.png)

The `addBase` function is exactly what we're going to use to inject our CSS variables that we've defined in previous lessons!

We will use the addBase function from Tailwind’s plugin API to inject styles into our base layer and apply our uppercase text transformation to the body.

Building an Example All Caps Plugin for Tailwind CSS

Improve Your Developer Workflow with Tailwind CSS Plugins

Now that we have the plugin working, let’s move our theming strategy into it.

## Challenge

For this challenge, you're going to take the CSS variable declarations in the CSS file here:

```css
[data-theme="base"] {
  --primary-50: 238 242 255;
  --primary-100: 224 231 255;
  --primary-200: 208 215 247;
  --primary-300: 170 185 255;
  --primary-400: 137 148 255;
  --primary-500: 107 112 252;
  --primary-600: 85 79 238;
  --primary-700: 69 60 205;
  --primary-800: 56 48 162;
  --primary-900: 39 33 115;
}

/* + rainforest and candy themes */
```

Then, you will move the declarations to the config file inside our plugin, replacing the `textTransform` plugin we made previously:

```css
plugin(function ({ addBase }) {
  /*
    ------------------------------
    Replace the "Hello World" CSS below
    with the multi-theme CSS variables
    ------------------------------
  */
  addBase({
    body: {
      textTransform: "uppercase",
    },
  })
}),

```

Remember, you need to use the [CSS in JavaScript syntax](https://cssinjs.org/?v=v10.9.2) and do a bit of formatting!

We can advance our theming strategy by taking the CSS variable declarations out of the CSS file and move them inside our plugin.

Let's take all of the CSS variable declarations from our CSS file, including the root scope and our themes:

```css
@layer base {
  :root {
    --primary-50: 238 242 255;
    --primary-100: 224 231 255;
    --primary-200: 208 215 247;
    --primary-300: 170 185 255;
    --primary-400: 137 148 255;
    --primary-500: 107 112 252;
    --primary-600: 85 79 238;
    --primary-700: 69 60 205;
    --primary-800: 56 48 162;
    --primary-900: 39 33 115;
  }
}

/* All themes converted as well */
```

Then, in our Tailwind config file, we could replace the `body` selector with the CSS variable declarations and manually convert everything into the CSS in JS syntax.

But, this is a tedious process.

Instead, we can use a handy tool called [transform.tools](https://transform.tools/) that can do all kinds of transformations.

We paste the CSS that we've copied and it will convert it all into CSS in JS syntax for us:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216793/workshops/multi-theme-strategy-workshop/01-06-02-move_css_to_plugin_solution_6_00-32640-of-this.png.png)



We don't need the `converted` variable, so just copy the `:root` selector and paste it into our `addBase` function:

```css
addBase({
  ':root': {
    '--primary-50': '238 242 255',
    '--primary-100': '224 231 255',
    '--primary-200': '208 215 247',
    '--primary-300': '170 185 255',
    '--primary-400': '137 148 255',
    '--primary-500': '107 112 252',
    '--primary-600': '85 79 238',
    '--primary-700': '69 60 205',
    '--primary-800': '56 48 162',
    '--primary-900': '39 33 115',
  },
  // ... and the rest of the themes
  }
})
```

Because we are injecting the CSS into the `base` layer, we're essentially doing exactly what the CSS file was doing.

That means in our CSS file we can remove all of the CSS variable declarations being injected into the `base` layer.

On save, you can see that everything still works:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216799/workshops/multi-theme-strategy-workshop/01-06-02-move_css_to_plugin_solution_13_01-06600-if-i-comment-out-the-add-base-declaration-here-and-save--all-the-colors-are-gone-because.png.png)

All of our work is happening in the Tailwind config file now.

Eventually, we'll move it all into its own plugin file!

Let’s move all of the CSS variable declarations being injected into our base layer from a CSS file into a Tailwind CSS plugin with help from some tools.

Transform CSS into CSS in JS for use in a Tailwind CSS Plugin

Moving CSS Variable Declarations into a Tailwind CSS Plugin

Let's move our Tailwind plugin to its own file and improve the way we define colors in our themes.

We are now importing the plugin into our Tailwind config file:

```tsx
const multiThemePlugin = require("./multi-theme-plugin.cjs") 
```

And now we can pass the plugin we've imported into the `plugins` array:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  theme: [
    // collapsed
  ]
  plugins: [multiThemePlugin],
}
```

Now if we look at the plugin file, we can see that we are defining our `themes` colors as hex values, but then we export colors as RGB channels.

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216807/workshops/multi-theme-strategy-workshop/01-07-01-hex_to_rgb_6_00-18760-there-should-be-something-bothering-you-at-this-point.png.png)

This isn’t ideal since we had to manually convert our hex values to these RGB channels.

Let's improve this by creating a function that will convert our hex values to RGB channels.

We'll create a helper function called `getRgbChannels` that takes a hex value, converts it to RGB using a library called `hex-rgb`, and then uses a template literal to format the channels into a string:

```tsx
const hexRgb = require("hex-rgb")

function getRgbChannels(hex) {
  const { red, green , blue } = hexRgb(hex)
  return `${red} ${green} ${blue}`

  // getRgbChannels("#0099aa") => "0 153 170"
}
```

## Challenge

You need to take all of the RGB channel values in our `plugin`, and replace them with calls to `getRgbChannels` with the hex values from `themes` passed in:

```tsx
// replace RGB channel strings with calls to getRgbChannels

addBase({
  ':root': {
    '--primary-50': '238 242 255',
    '--primary-100': '224 231 255',
    '--primary-200': '208 215 247',
    '--primary-300': '170 185 255',
    '--primary-400': '137 148 255',
    '--primary-500': '107 112 252',
    '--primary-600': '85 79 238',
    '--primary-700': '69 60 205',
    '--primary-800': '56 48 162',
    '--primary-900': '39 33 115',
  },
  // ... and the rest of the themes
  }
})
```

Don't worry about code duplication. We'll sort that out later.

Just focus on making the transformation from hex to RGB.

Manually creating RGB channels is tedious. Let’s create a function that converts hex to RGB channels and use that instead.

We're going to use our multi-cursor skills once again.

Start with the `:root` level variables, changing their values to calls to `getRgbChannels` passing in `themes.base` with the shade name:

```css
":root": {
  "--primary-50": getRgbChannels(themes.base["50"]),
  // ...100-800
  "--primary-900": getRgbChannels(themes.base["900"]),
}
```

Then, we'll copy and paste these lines to the other themes, `candy` and `rainforest`.

Once pasted, we'll need to change `themes.base` to `themes.candy` and `themes.rainforest` respectively.

```css
'[data-theme="rainforest"]': {
  "--primary-50": getRgbChannels(themes.rainforest["50"]),
  // ...100-800
  "--primary-900": getRgbChannels(themes.rainforest["900"]),
},
'[data-theme="candy"]': {
  "--primary-50": getRgbChannels(themes.candy["50"]),
  // ...100-800
  "--primary-900": getRgbChannels(themes.candy["900"]),
}
```

Now, all of the colors should still be correct:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216817/workshops/multi-theme-strategy-workshop/01-07-02-hex_to_rgb_solution_8_00-55320-so-obviously--theres-a-lot-of-repetition-here-.png.png)

There's a lot of repetition here, but we've done something great.

We are reading the values from the `themes` object, which gets us one step closer to having the plugin read from `themes` that users defined themselves.

We're going to use our multi-cursor skills to refactor our plugin code to use our getRgbChannels helper function to get values from our themes object.

Replacing Hardcoded RGB Channel Values with Function Calls

Convert Hex to RGB with JavaScript

Let's just do a bit of code refactoring to get rid of some duplication before we keep going.

We're reading the values of our themes object here:

```css
":root": {
  "--primary-50": getRgbChannels(themes.base["50"]),
  // ...100-800
  "--primary-900": getRgbChannels(themes.base["900"]),
}
// ...base, rainforest, and candy
```

Which is an improvement over RGB channels.

But we still hardcode the name of the themes: `base`, `rainforest`, and `candy`.

## Challenge

Your challenge is to do some refactoring to remove duplication.

We'll keep our `:root` scope as is, but for our three theme scopes you will need to iterate over the `themes` object.

Here are a couple of hints to help you get started:

* You can use the `addBase()` function multiple times
* You can use `Object.entries()` to iterate over the keys of the `themes` object

Currently, we hard-code the names of the themes in our calls to getRgbChannels. Let's refactor to iterate over the themes object instead.

We're going to use the `addBase` function multiple times, once for each theme.

Our theme is an object containing multiple keys: `base`, `rainforest`, and `candy`.

To be able to iterate over them, we're going to keep the `:root` definition _as is_, but close the `addBase` function around it.

Its role is going to be to define only the `:root` scope variables:

```tsx
addBase({
  ":root": {
    "--primary-50": getRgbChannels(themes.base["50"]),
    // ...100-800
    "--primary-900": getRgbChannels(themes.base["900"]),
  },
})
```

For our three theme scopes, let's reopen another `addBase`, just so the syntax is correct:

```tsx
addBase({
  '[data-theme="base"]': {
    "--primary-50": getRgbChannels(themes.base["50"]),
    // ...100-800
    "--primary-900": getRgbChannels(themes.base["900"]),
  },
  '[data-theme="rainforest"]': {
    "--primary-50": getRgbChannels(themes.rainforest["50"]),
    // ...100-800
    "--primary-900": getRgbChannels(themes.rainforest["900"]),
  },
  '[data-theme="candy"]': {
    "--primary-50": getRgbChannels(themes.candy["50"]),
    // ...100-800
    "--primary-900": getRgbChannels(themes.candy["900"]),
  },
})

```

Instead of doing the three declarations manually, we're going to iterate over the `themes` object.

Let's start by writing `Object.entries(themes)` with a `forEach` loop above `addBase`:

```tsx
Object.entries(themes).forEach([key, value] => {
  // ...
})
```

`Object.entries` gives us both the keys and values of an object.

Also, make sure to delete the `addBase` function with all of our themes before continuing.

Inside the `forEach` loop, we'll want to call `addBase`, and paste our `base` theme inside:

```tsx
Object.entries(themes).forEach([key, value] => {
  addBase({
   '[data-theme="base"]': {
      "--primary-50": getRgbChannels(themes.base["50"]),
      // ...100-800
      "--primary-900": getRgbChannels(themes.base["900"]),
    },
  })
})
```

This is going to set every theme to the `base` theme:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216829/workshops/multi-theme-strategy-workshop/01-08-02-loop_over_themes_solution_11_01-16440-and-sure-enough--that-works.png.png)

The `key` we get from `Object.entries` is going to be either: `base`, `rainforest`, or `candy`.

So let's use the `key` to replace our usage of `base`:

```tsx
Object.entries(themes).forEach([key, value] => {
  addBase({
   [`[data-theme="${key}"]`]: {
      "--primary-50": getRgbChannels(themes.base["50"]),
      // ...100-800
      "--primary-900": getRgbChannels(themes.base["900"]),
    },
  })
})
```

We used string interpolation to replace `base` with the `key` variable in the `data-theme` attribute.

And, since we were using a template literal, we had to wrap the `data-theme` attribute in brackets.

Now, we need to update the `value` to be the correct theme.

`value` is an object containing the shades of the theme. So we can replace `themes.base` with `value`:

```tsx
Object.entries(themes).forEach([key, value] => {
  addBase({
   [`[data-theme="${key}"]`]: {
      "--primary-50": getRgbChannels(value["50"]),
      // ...100-800
      "--primary-900": getRgbChannels(value["900"]),
    },
  })
})
```

We are once again a step closer to accepting user-defined themes input.

There's still hard-coded stuff in here, but we're going in the right direction!

We can use Object.entries to iterate over the theme object and call addBase with each theme so that we don’t have to manually set each variable.

Dynamically Adding Themes through Iteration

Refactoring to Remove Hard-Coded Theme Names in Tailwind Plugin

Before we continue making our plugin more dynamic, let's consolidate our code concerns in one place.

We have a plugin file where we define the CSS variables for the `:root` and theme scopes:

```tsx
addBase({
  ":root": {
    "--primary-50": getRgbChannels(themes.base["50"]),
    // ...100-800
    "--primary-900": getRgbChannels(themes.base["900"]),
  },
})

Object.entries(themes).forEach([key, value] => {
  addBase({
   [`[data-theme="${key}"]`]: {
      "--primary-50": getRgbChannels(value["50"]),
      // ...100-800
      "--primary-900": getRgbChannels(value["900"]),
    },
  })
})
```

Inside the Tailwind config file, we extend the `theme` to create new utilities that consume those CSS variables:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  theme: {
    extend: {
      colors: {
        base: themes.base,
        rainforest: themes.rainforest,
        candy: themes.candy,
        primary: {
          50: "var(--primary-50)",
          // ...100-800
          900: "var(--primary-900)",
        },
      },
    },
  },
  plugins: [multiThemePlugin],
}
```

**These two parts share the same concern and work together on the same thing.**

It turns out that we can offload the responsibility of extending the user's theme to the plugin itself.

## Challenge

Your challenge is to find a way to extend the theme from within the plugin definition, allowing us to get rid of the `theme` extension.

With this change in place, the only thing in the config file will be requiring the plugin.

We can consolidate our code concerns by moving the responsibility of extending the user's theme to the plugin itself.

In the Tailwind config file, we remove the entire `theme` object:

```tsx
module.exports = {
  content: ["./src/**/*.astro"],
  // REMOVED theme object
  plugins: [multiThemePlugin],
}
```

This will cause the code to break.

Over in the plugin file, the `plugin` function accepts a config object as second argument that can be used to extend the theme.

Our current first argument is this function:

```tsx
module.exports = plugin(function ({ addBase }) {
  addBase({
    ':root': {
      '--primary-50': getRgbChannels(themes.base["50"]),
      // ...100-800
      '--primary-900': getRgbChannels(themes.base["900"]),
    },
  })

  Object.entries(themes).forEach([key, value] => {
    addBase({
    [`[data-theme="${key}"]`]: {
        "--primary-50": getRgbChannels(value["50"]),
        // ...100-800
        "--primary-900": getRgbChannels(value["900"]),
      },
    })
  })
})
```

Let's pass the config object to the function now.

Our config is the whole Tailwind config object, so we can paste the exact same `theme` extension that we had in the Tailwind config file:

```tsx
module.exports = plugin(
  function ({ addBase }) {
    // ...
  },
  {
    theme: {
      extend: {
        colors: {
          base: themes.base,
          rainforest: themes.rainforest,
          candy: themes.candy,
          primary: {
            50: "var(--primary-50)",
            // ...100-800
            900: "var(--primary-900)",
          },
        },
      },
    },
  }
)
```

When we hit save, everything will come back to place:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216846/workshops/multi-theme-strategy-workshop/01-09-02-define_theme_in_plugin_solution_5_00-40000-with-a-simple-copy-and-paste-effort--weve-done-something-significant-here.png.png)

With a simple copy and paste effort, we've done something significant here.

Our plugin file is entirely responsible for implementing the theming strategy. It defines CSS variables and extends the theme object.

In our config file, we simply import and require the plugin in the `plugins` array. This makes our plugin self-contained and able to be used in other applications.

While it is not fully dynamic yet, it is a significant step in the right direction!

Configure Tailwind to Extend Themes via Plugin

Consolidating Code Concerns into a Tailwind Plugin

Our plugin is not yet complete, but it does already contain all the necessary theming functionality.

It is a good time to test it in a real application to see the results of our work.

We will be using a calendar app where users can select days and see the availability on the right. They can confirm a convenient date and submit a form to receive a confirmation screen:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216857/workshops/multi-theme-strategy-workshop/01-10-01-calendar_app_4_00-38960-calendar-days-the-selection-buttons-the-buttons-follows-that-brand-color-and-this-is-where-were.png.png)

The background, calendar days, and buttons all follow the brand color.

**Our theming strategy will be used to swap this brand color.**

Let's take a look at the code base.

Currently, everything in this app is using the indigo color site-wide. We want to replace this with our primary themable color.

If we open open our Tailwind config file we'll see that we are using a couple of plugins:

```tsx
const bgStripesPlugin = require("./plugins/bg-stripes") 
const squareDiagnalPlugin = require("./plugins/square-diagonal") 
```

`bg-stripes` is a fancy CSS variable composition technique which is what creates a nice animated background stripes pattern.

`square-diagonal` extends the width with a mathematical equation and that width allows us to set the perfect width for the ribbon in the top right of our window.

Lastly, our `multi-theme` plugin is code that we wrote in the previous lesson. This code sets up the CSS variables for different scopes, and extends the Tailwind CSS theme colors.

## Challenge

Your challenge is to replace the site-wide indigo color with our primary themable color.

Your first step is to open the Tailwind config file and require the the `multi-theme` plugin, which should then be added to the plugins array.

Once you've registered the plugin, start your first conversion on the split background pattern where the indigo is being used on the left:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216864/workshops/multi-theme-strategy-workshop/01-10-01-calendar_app_19_02-12240-the-themable-color-here-so-in-components-you-will-find-background-decoration-again-it-explains-to.png.png)

### Challenge Steps

In the components folder you will find the file, `background-decoration.jsx`. Inside of which you need to do the following:

* Find and replace all instances of `indigo` with our themable `primary` color.
* Add a `data-theme="candy"` attribute to the parent `div` element.

Once this is working, you can move on and replace every instance of `indigo` in the entire codebase.

When you’ve replaced all of the instances, open up `pages/_app.jsx`. Inside, you will find a commented out `ThemeSwitcher` component.

Uncomment this component and see what happens to your app!

### Bonus: Nesting themes

Remember our themes are nestable and you can override a theme within another theme.

Just for fun, maybe try to replace one component with a different theme by adding a data attribute to that component.

Our goal is to replace the indigo brand color of a real calendar app with our primary themable color using our plugin.

Let's start by requiring the multi-theme plugin in our Tailwind config file:

```tsx
const multiThemePlugin = require("./plugins/multi-theme") 
```

Then, we can add the plugin to the `plugins` array:

```tsx
plugins: [bgStripesPlugin, squareDiagonalPlugin, multiThemePlugin], 
```

## Update the `BackgroundDecoration` Component

Now, let's make the `BackgroundDecoration` component themable.

Using your editor, find all instances of `indigo` and replace them with `primary`.

After saving the changes, the app will update to reflect `base` theme color (which is similar to the `indigo` shades):

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671216875/workshops/multi-theme-strategy-workshop/01-10-02-calendar_app_solution_4_00-38400-you-might-not-notice-the-difference-because-ive-based-the-base-theme-color-very-closely.png.png)

### Trying the Other Themes

In the parent `div` element of `BackgroundDecoration`, add a `data-theme="candy"` attribute:

```tsx
export function BackgroundDecoration({ selectedDate }) {
  return (
    <div
      data-theme="candy"
      aria-hidden="true"
      className="background-split fixed inset-0 grid"
    >
      {/* ... */}
    </div>
  )
}
```

Our app is now using the `candy` theme colors:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671336347/workshops/multi-theme-strategy-workshop/01-10-02-calendar_app_solution_8_00-59280-obviously--the-other-components-are-still-using-indigo--but-it-looks-like-our-theming.png.png)

The other components are still using indigo, but it looks like our theming strategy is working nicely.

Just for fun, let's try making the right panel use the `rainforest` theme:

```tsx
export function BackgroundDecoration({ selectedDate }) {
  return (
    <div
      data-theme="candy"
      aria-hidden="true"
      className="background-split fixed inset-0 grid"
    >
      {/* ... */}
      <div
        data-theme="rainforest"
        className="relative col-span-2 overflow-hidden bg-primary-500"
      >
        {/* ... */}
      </div>
      {/* ... */}
    </div>
  )
}
```

As you can see, this is working really well:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671336351/workshops/multi-theme-strategy-workshop/01-10-02-calendar_app_solution_12_01-17760-so-lets-undo-all-of-that.png.png)

But, let's undo all of that.

Set the colors back to primary, which should get us back to our base theme.

### The `ThemeSwitcher` Component

In `pages/_app.jsx`, uncomment the `ThemeSwitcher` component.

In the upper right corner of the app, there is now a dropdown menu with our different theme options:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671336369/workshops/multi-theme-strategy-workshop/01-10-02-calendar_app_solution_15_01-38400-themes--but-before-we-use-it--lets-take-a-look-at-what-the-code-inside-of-here-is-doing.png.png)

But, before we use it, let's take a look at what the code is doing.

Inside of `ThemeSwitcher` we are setting the `activeTheme` state to the `base` theme by default. There’s a `useEffect` hook that will append the `body` elements with the `data-theme` attribute, whose value is the `activeTheme` state:

```tsx
export function ThemeSwitcher() {
  const themesList = ["base", "candy", "rainforest"]
  const [activeTheme, setActiveTheme] = useState("base")
  useEffect(() => {
    document.querySelector("body").setAttribute("data-theme", activeTheme)
  }, [activeTheme])

  // ...
}
```

If we open up our devtools we can see the `data-theme` attribute on `body` change whenever we switch themes:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671336376/workshops/multi-theme-strategy-workshop/01-10-02-calendar_app_solution_18_02-01120-you-can-see-the-data-theme-changed-to-rain-forest-and-candy.png.png)

## Update the Rest of the App

We still only have the `BackgroundDecoration` component working with switchable themes.

Let's replace every instance of `indigo` to our primary color. So I'll do a site-wide search for `indigo-` and replace it with `primary-`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671336382/workshops/multi-theme-strategy-workshop/01-10-02-calendar_app_solution_25_02-38080-and-that-sounds-scary--but-lets-give-it-a-shot.png.png)

Open up the app and switch the theme to `rainforest` to see if it worked as expected:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671336390/workshops/multi-theme-strategy-workshop/01-10-02-calendar_app_solution_29_03-02480-check-this-out.png.png)

How cool is that?

Everything is using the correct theme and our plugin is working wonderfully.

And, just like I said in the challenge intro, you could go into any component and switch the theme to something else, no matter what the active theme is!

Let's improve the design and functionality of our calendar application by integrating the multi-theme component we created.

Refactoring a Calendar App to Use the multi-theme Component

Testing The Multi-Theme Plugin by Replacing the Site-Wide Color in a Calendar App

It’s time to make our plugin seriously dynamic, including the ability to support nested color theme objects!

In preparation for that, a tiny change has been made to the plugin. Instead of defining the themes directly in it, we are now importing a `themes.json` file:

```tsx
const themes = require("./themes.json") 
```

This change makes our code slightly more complex than before. We still have our `base`, `rainforest`, and `candy` themes.

But, as you can see, there's nested properties like `primary`, and `secondary` now:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671336912/workshops/multi-theme-strategy-workshop/01-11-01-dynanic_css_varuavkes_5_00-28000-but-as-you-can-see--theres-nested-properties-like-primary--and-then-secondary-.png.png)

We need to write code that can support this nested structure.

Let's look at some changes that have been made to the plugin.

Recall that we used to access the shade numbers directly off of `theme.base`.

Now that we have a nested `primary` key inside the `base` theme for our `50` to `900` colors, `plugin` now has an `addBase` declaration that uses `theme.base.primary`:

```tsx
addBase({
  ":root": {
    "--primary-50": getRgbChannels(themes.base.primary["50"]),
    // ...100-800
    "--primary-900": getRgbChannels(themes.base.primary["900"]),
  },
})

```

The same has been done for the theme scopes.

Here we now use `value.primary`:

```tsx
Object.entries(themes).forEach(([key, value]) => {
  addBase({
    [`[data-theme="${key}"]`]: {
      "--primary-50": getRgbChannels(value.primary["50"]),
      // ...100-800
      "--primary-900": getRgbChannels(value.primary["900"]),
    },
  })
})
```

Everything else is exactly the same as it used to be.

## Challenge

Your job is to write a helper function that takes the `theme` object as an input, and then outputs the correct CSS in JavaScript syntax object.

You’ll start with a `getCSSVariableDeclarations` function that takes an `input` and an `output` as arguments:

```tsx
function getCSSVariableDeclarations(input, output = {}) {
  // TODO
  return output
}
```

We're expecting the return `output` to look something like this:

```
// '--primary-50': getRgbChannels('#eef2ff'),
// '--secondary-some-new-color': getRgbChannels('#0099aa'),
```

Deeply nested values should have the kebab case key name like `--secondary-some-new-color`.

If you write the function correctly, you can replace the entire object in the `:root` scope with the `getCSSVariableDeclarations` function call.

While this is more of a JavaScript challenge rather than a Tailwind-specific challenge, this work needs to be done in order to really help make the plugin reusable.

If you can't figure it out, it's not the end of the world. Just try for a bit, and then move on to the solution.

Let's write a helper function that takes a theme object as an input and outputs the correct CSS in JavaScript syntax object, even for nested data.

There are many ways to solve this challenge! What counts is that the results match.

Logging the returned `output` of the `getCssVariableDeclarations` will help us to write the function.

In the `plugin` function, add a `console.log()` with a message to remind us where we are in the code. Add a comma to also log out a call to `getCssVariableDeclarations` with `themes.base` as the argument:

```tsx
module.exports = plugin(function ({ addBase }) {
  console.log("CSS vars definition", getCssVariableDeclarations(themes.base))
})
```

Currently, it logs an empty object because this is the default of the `output` argument:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671337490/workshops/multi-theme-strategy-workshop/01-11-02-dynanic_css_varuavkes_solution_5_00-33440-so-that-should-help-us-construct-the-correct-output-that-were-looking-for.png.png)

In `getCssVariableDeclarations`, we'll use `Object.entries`, but this time passing in `input` as the argument:

```tsx
function getCssVariableDeclarations(input, output = {}) {
  Object.entries(input).forEach(([key, value]) => {
    // TODO
  })
  return output
}
```

At this point we are at a crossroads.

The `value` is either going to be a string or an object.

Let's write an `if` statement.

In the first case, if the `value` is NOT of type `string`, we will call `getCssVariableDeclarations` with `value` as the `input` argument, along with the current `output` argument:

```tsx
Object.entries(input).forEach(([key, value]) => {
  if (typeof value !== "string") {
    getCssVariableDeclarations(value, output)
  }
})
```

Otherwise, we will add a dynamic key to the `output` object, and set it to the `value`:

```tsx
Object.entries(input).forEach(([key, value]) => {
  if (typeof value !== "string") {
    getCssVariableDeclarations(value, output)
  } else {
    output[`--${key}`] = value
  }
})
```

From this, we get a series of variable names that are currently incorrect along with their hex values:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671337549/workshops/multi-theme-strategy-workshop/01-11-02-dynanic_css_varuavkes_solution_17_02-08000-but-this-is-a-pretty-good-start.png.png)

What we actually want is the `getRgbChannels` output.

This is an easy fix. We just need to replace `value` with `getRgbChannels(value)`:

```tsx
Object.entries(input).forEach(([key, value]) => {
  if (typeof value !== "string") {
    getCssVariableDeclarations(value, output)
  } else {
    output[`--${key}`] = getRgbChannels(value)
  }
})
```

## Naming Nested Keys

Now if you look, the CSS vars definition goes from `--50` to `--900` and then jumps straight to `--color`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671337603/workshops/multi-theme-strategy-workshop/01-11-02-dynanic_css_varuavkes_solution_21_02-23120-and-so-if-you-look--it-goes-from-50-to-900-and-then-jumps-straight-to-color.png.png)

This is happening due to the way we are handling recursive calls.

When we hit the nested `secondary` object, we eventually hit a string that has a key of `color`.

Remember, we wanted to have the CSS variable be a full kebab case name of all the nested keys. For example, `--secondary-some-nested-color` instead of `--color`:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671337684/workshops/multi-theme-strategy-workshop/01-11-02-dynanic_css_varuavkes_solution_25_02-57600-so-to-do-that--we-need-to-keep-track-of-the-current-segment-or-the-current-key.png.png)

To do that, we need to keep track of the current key.

Let's add a third argument to `getCssVariableDeclarations` called `path` with a default value of an empty array:

```tsx
function getCssVariableDeclarations(input, path = [], output = {}) {
  // ...
}
```

Inside of the loop, we’ll concatenate the current `key` with the `path` .

If the `value` is not a string, we will recursively call `getCssVariableDeclarations` with the updated `path`:

```tsx
function getCssVariableDeclarations(input, path = [], output = {}) {
  Object.entries(input).forEach(([key, value]) => {
    const newPath = path.concat(key)
    if (typeof value !== "string") {
      getCssVariableDeclarations(value, newPath, output)
    } else {
      output[`--${key}`] = getRgbChannels(value)
    }
  })
	return output
}
```

We'll collect the various nested keys inside this array and then join the array together to construct our kebab-cased variable name:

```tsx
else {
  output[`--${newPath.join('-')}`] = getRgbChannels(value)
}
```

Now we get the correct output:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671337728/workshops/multi-theme-strategy-workshop/01-11-02-dynanic_css_varuavkes_solution_37_04-15200-look-at-this.png.png)

And if we create a new nested object it will generate a CSS variable for it on the fly:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671337769/workshops/multi-theme-strategy-workshop/01-11-02-dynanic_css_varuavkes_solution_47_04-57520-so-it-looks-like-weve-landed-on-a-function-that-can-generate-css-variables-on-the-fly.png.png)

Now that we know it works, we can remove the `console.log` from the `plugin` function.

## Using the Function

Now we are going to try to replace that `addBase` block for `:root` and our themes with our new function:

```tsx
addBase({
  ":root": {
    "--primary-50": getRgbChannels(themes.base.primary["50"]),
    // ...100-800
    "--primary-900": getRgbChannels(themes.base.primary["900"]),
  },
})

Object.entries(themes).forEach(([key, value]) => {
  addBase({
    [`[data-theme="${key}"]`]: {
      "--primary-50": getRgbChannels(value.primary["50"]),
      // ...100-800
      "--primary-900": getRgbChannels(value.primary["900"]),
    },
  })
})
```

We can also remove all of the CSS variables from both `:root` and the themes:

```tsx
addBase({
  ":root": {},
})

Object.entries(themes).forEach(([key, value]) => {
  addBase({
    [`[data-theme="${key}"]`]: {},
  })
})
```

Now we have no more theme colors:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671337855/workshops/multi-theme-strategy-workshop/01-11-02-dynanic_css_varuavkes_solution_56_05-40560-now--instead-of-this-empty-object-here--i-will-call-the-getcssvariabledeclarations.png.png)

The empty objects can be replaced with calls to `getCSSVariableDeclarations`, using `value` as the input for the themes.

Then for `:root`, we will use the first value from the result of `Object.values(themes)` so that we are not longer hardcoding the `base` theme:

```tsx
addBase({
  ":root": getCssVariableDeclarations(Object.values(themes)[0]),
})

Object.entries(themes).forEach(([key, value]) => {
  addBase({
    [`[data-theme="${key}"]`]: getCssVariableDeclarations(value),
  })
})
```

Now our colors are back in place:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671337934/workshops/multi-theme-strategy-workshop/01-11-02-dynanic_css_varuavkes_solution_62_06-10880-that-the-first-theme-is-called-base--which-is-not-a-given-at-all.png.png)

Our plugin is becoming truly powerful now!

The next thing we need to do is dynamically generate the CSS utility classes generated by Tailwind.

We can dynamically create CSS variables by writing a recursive function that builds kebab case variable names from nested theme objects.

Create CSS Variables from Theme Objects with Recursion

Dynamically Generate Colors From Nested Theme Objects

Here is a fancy bit of UI that pulls from the Tailwind config file and outputs a color swatch for each themable color generated with the CSS variable:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671338057/workshops/multi-theme-strategy-workshop/01-12-01-dynanic_utilities_1_00-04560-heres-a-pretty-fancy-bit-of-ui-here-that-pulls-from-the-tailwind-config-file.png.png)

## Challenge

Your goal is to complete the function `getColorUtilitiesWithCssVariableReferences`:

```tsx
function getColorUtilitiesWithCssVariableReferences(input) {
  // TODO
}
```

This function needs needs to output an object that replaces the hardcoded `primary` color shades object in our `multi-theme` plugin:

```tsx
colors: {
  primary: {
    50: 'rgb(var(--primary-50) / <alpha-value>)',
    // 100-800
    900: 'rgb(var(--primary-900) / <alpha-value>)',
  },
}
```

This is similar to the previous approach we've taken. Don't worry if it's a little bit over your head, struggle for a bit and then move on to the solution.

With help from a JavaScript function, we can create an object that replaces the hard-coded color shades in our multi-theme plugin.

As mentioned, the solution will be some similarities to the `getCssVariableDeclarations` function we wrote previously.

Here’s that function’s code for reference:

```tsx
function getCssVariableDeclarations(input, path = [], output = {}) {
  Object.entries(input).forEach(([key, value]) => {
    const newPath = path.concat(key)
    if (typeof value !== "string") {
      getCssVariableDeclarations(value, newPath, output)
    } else {
      output[`--${newPath.join("-")}`] = getRgbChannels(value)
    }
  })
  return output
}
```

Let’s start filling out the `getColorUtilitiesWithCssVariableReferences` function, which will take `input `and `path` arguments:

```tsx
function getColorUtilitiesWithCssVariableReferences(input, path = []) {
  // ...
}
```

An `output` argument isn’t needed since we are not going to populate an object. Instead, we will be returning an object that we construct inside the function.

Similar to the reference function, we’ll add `Object.entries`, but this time we'll be mapping over it.

Inside the map function, we'll create a `newPath` variable that concats the key:

```tsx
function getColorUtilitiesWithCssVariableReferences(input, path = []) {
  Object.entries(input).map(([key, value]) => {
    const newPath = path.concat(key)
  })
}

```

After `newPath` we'll have an `if` statement that checks if `value` is not a string, in which case we'll recursively call `getColorUtilitiesWithCssVariableReferences` with the updated `path`:

```tsx
function getColorUtilitiesWithCssVariableReferences(input, path = []) {
  Object.entries(input).map(([key, value]) => {
    const newPath = path.concat(key)
    if (typeof value !== "string") {
      getColorUtilitiesWithCssVariableReferences(value, newPath)
    }
  })
}

```

The code has so far been very similar to the `getCssVariableDeclarations` function we've done in the previous step, but now we are going to do something different.

We want an object but since we are using `map` we are currently getting an array.

To solve this, we can wrap `Object.entries` with `Object.fromEntries`:

```tsx
function getColorUtilitiesWithCssVariableReferences(input, path = []) {
  return Object.fromEntries(
    Object.entries(input).map(([key, value]) => {
      const newPath = path.concat(key)

```

`Object.fromEntries` expects an array of key-value pairs, so we'll return an array with the key and the result of calling `getColorUtilitiesWithCssVariableReferences`.

```tsx
if (typeof value !== "string") {
  return [key, getColorUtilitiesWithCssVariableReferences(value, newPath)]
}
```

Unlike the reference function, returning the array we don't need an `else` statement because we’re only interested in returning this array.

Because of `Object.fromEntries` we'll need to return an array with the key-value format. The value will be a properly formatted string with the joined `newPath`:

As a reminder, the strings we are looking for need to follow this pattern:

```tsx
"rgb(var(--primary-50) / <alpha-value>)" 
```

```tsx
function getColorUtilitiesWithCssVariableReferences(input, path = []) {
  return Object.fromEntries(
    Object.entries(input).map(([key, value]) => {
      const newPath = path.concat(key)
      if (typeof value !== "string") {
        return [key, getColorUtilitiesWithCssVariableReferences(value, newPath)]
      }
      return [key, `rgb(var(--${newPath.join("-")}) / <alpha-value>)`]
    })
  )
}
```

Let's test this out with `console.log`, passing in `themes.base` as input:

```tsx
module.exports = plugin(function ({ addBase }) {
  console.log(getColorUtilitiesWithCssVariableReferences(themes.base))
  // ...
})
```

And now we'll see the result, a `primary` object full of key-value pairs with the correct syntax:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671339022/workshops/multi-theme-strategy-workshop/01-12-02-dynanic_utilities_solution_23_02-56880-primary-object-and-then-the-keys-with-the-correct-syntax-and-then-this-nested-hierarchy-which-seems.png.png)

This is exactly what we want!

## Replace the Hardcoded Theme Extension

Now let's replace the hardcoded `theme` extension with our new function.

We'll start by deleting the entire `colors` extension object and replacing the value with a call to `getColorUtilitiesWithCssVariableReferences`, passing in `themes.base` as input:

```tsx
colors: getColorUtilitiesWithCssVariableReferences(themes.base) 
```

And it's working beautifully:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671339071/workshops/multi-theme-strategy-workshop/01-12-02-dynanic_utilities_solution_27_03-36160-down-primary-900-and-look-at-this-secondary-some-nested-color-so-its-working-beautifully.png.png)

Then if we add some nested data to the `secondary` property, it will still work!

Matching the CSS variables generated by Tailwind and the utility class names allows us to create this super dynamic theming strategy:

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671339129/workshops/multi-theme-strategy-workshop/01-12-02-dynanic_utilities_solution_30_04-00400-and-then-the-utility-class-names-and-these-two-parts-work-together-to-create-this-theming.png.png)

The last thing left is to update the call to `getColorUtilitiesWithCssVariableReferences` to use `Object.values` just like we did before:

```tsx
colors: Object.values(
  getColorUtilitiesWithCssVariableReferences(Object.values(themes)[0])
)
```

### A Note About Repeated Colors

You might have noticed that each of the bottom color swatches in the above screenshot is the same color.

This is because we only have that nested structure in our `base` theme.

The primary theme needs to act as a blueprint for the structure of all other themes. Otherwise, it's going to generate variables for the first theme that won't exist in the others.

This lesson was long, so take a deep breath. We have just one more step to go!

Dynamically Define Theme Colors In Your Tailwind Config

Write a Function That Replaces Hard-Coded Theme Colors

The last thing that is hard-coded in our plugin is the way we're passing the themes.

In our multi-theme plugin we are currently importing the `themes` and then using it with our magic dynamic stuff.

But, as a user, you'd want to pass in **your own themes** when using that plugin.

## Challenge

Your challenge is to move the `themes` outside of the plugin, and get rid of the import.

Then you’ll need to update the Tailwind config file to pass the `themes` object as an option to the plugin.

So your challenge here is to get rid of the `themes` import and instead pass the `themes` to the plugin in your Tailwind config file where the plugin is registered.

Have a look at the [Tailwind CSS docs](https://v2.tailwindcss.com/docs/plugins) for a way to pass options to a plugin.

We’ll figure out how to pass options to a plugin so that users can provide their own themes to our plugin. 

Let's start by removing the `themes` import from our `plugin`, which will break the application.

Instead, we'll import it into our config file.

With that done, we will call our plugin like a function, and pass that function an options object containing a key of `colorThemes` with a value of the `themes` object:

```tsx
const themes = require('./themes.json')

module.exports = [
  content: ["./src/**/*.astro"],
  plugins: [multiThemePlugin({ colorThemes: themes })],
]
```

This isn't working yet.

We need to modify our plugin to accept an options object and read from `colorThemes`.

## Updating the Plugin

In our multi-theme plugin we'll call the `.withOptions` method on `plugin`. This method has a similar signature to `plugin` but both arguments are wrapped in functions that each take an `options` argument:

```tsx
module.exports = plugin.withOptions(
  function (options) {
    return function ({ addBase }) {
      // ...
    }
  },
  function (options) {
    return {
      theme: {
        // ...
      },
    }
  }
)
```

Note that `themes` is still not defined because we are not yet doing anything with the `options` it receives.

Let's destructure `colorThemes` from the `options` object and use it in our plugin:

```tsx
module.exports = plugin.withOptions(
  function (options) {
    const { colorThemes } = options
    return function ({ addBase }) {
      addBase({
        ":root": getCssVariableDeclarations(Object.values(colorThemes)[0]),
      })
      // ...
    }
  },
  function (options) {
    const { colorThemes } = options
    return {
      theme: {
        extend: {
          colors: getColorUtilitiesWithCssVariableReferences(
            Object.values(colorThemes)[0]
          ),
        },
      },
    }
  }
)

```

And boom, our application is working again!

![](http://res.cloudinary.com/pro-tailwind/image/upload/v1671339399/workshops/multi-theme-strategy-workshop/01-13-02-plugin_with_options_solution_20_02-24320-were-not-done-yet-though--because-we-passing-the-color-themes-option--but-here-we-cannot-assume.png.png)

## Adding a Helper Function

The problem with our current implementation is that we are assuming that `colorThemes` will always be provided, which isn't true.

So let's implement a helper function that checks for a valid `colorThemes` input:

```tsx
function checkForValidColorThemesInput(input) {
  const isValid =
    typeof input === "object" &&
    Object.keys(input).some((key) => typeof input[key] === "object")
  if (!isValid) {
    throw new Error(
      "The Multi-Theme Plugin expects a 'colorThemes' option passed to it, which contains at least one theme object."
    )
  }
}

```

This first checks if the `input` is an object, and then checks if the object has at least one key that has a value with a type of `object`.

If the input isn't valid we throw an error.

Now back in our `plugin` we can call this function after destructuring `colorThemes` off of the `options` object:

```tsx
module.exports = plugin.withOptions(
  function (options) {
    const { colorThemes } = options
    checkForValidColorThemesInput(colorThemes)
    return function ({ addBase }) {
      addBase({
        ":root": getCssVariableDeclarations(Object.values(colorThemes)[0]),
      })
      // ...
    }
  },
  function (options) {
    const { colorThemes } = options
    checkForValidColorThemesInput(colorThemes)
    return {
      theme: {
        extend: {
          colors: getColorUtilitiesWithCssVariableReferences(
            Object.values(colorThemes)[0]
          ),
        },
      },
    }
  }
)

```

This is a much more robust implementation that ensures that the user is providing our plugin the proper input.

## Recapping Our Work

With all that, our plugin is slowly but surely reaching its final form.

Let's recap everything we've done!

We've defined helper functions to get RGB channels:

```tsx
function getRgbChannels(hex) {
  const { red, green, blue } = hexRgb(hex)
  return `${red} ${green} ${blue}`
}

```

and to generate CSS variables:

```tsx
function getCssVariableDeclarations(input, path = [], output = {}) {
  Object.entries(input).forEach(([key, value]) => {
    const newPath = path.concat(key)
    if (typeof value !== "string") {
      getCssVariableDeclarations(value, newPath, output)
    } else {
      output[`--${newPath.join("-")}`] = getRgbChannels(value)
    }
  })
  return output
}

```

We generate utility classes:

```tsx
function getColorUtilitiesWithCssVariableReferences(input, path = []) {
  return Object.fromEntries(
    Object.entries(input).map(([key, value]) => {
      const newPath = path.concat(key)
      if (typeof value !== "string") {
        return [key, getColorUtilitiesWithCssVariableReferences(value, newPath)]
      }
      return [key, `rgb(var(--${newPath.join("-")}) / <alpha-value>)`]
    })
  )
}

```

and validate the correct input from the theme object:

```tsx
function checkForValidColorThemesInput(input) {
  const isValid =
    typeof input === "object" &&
    Object.keys(input).some((key) => typeof input[key] === "object")
  if (!isValid) {
    throw new Error(
      "The Multi-Theme Plugin expects a 'colorThemes' option passed to it, which contains at least one theme object."
    )
  }
}

```

In our plugin, we use `plugin.withOptions`, which lets us grab the `colorThemes` option passed to the plugin.

And then we check that `colorThemes` is valid using our `checkForValidColorThemesInput` helper function:

```tsx
module.exports = plugin.withOptions(
  function (options) {
    const { colorThemes } = options
    checkForValidColorThemesInput(colorThemes)
    return function ({ addBase }) {
      // ...
    }
  },
  function (options) {
    const { colorThemes } = options
    checkForValidColorThemesInput(colorThemes)
    return {
      // ...
    }
  }
)

```

If `colorThemes` is valid in our first function argument, we then add the `:root` CSS variable and each of the theme CSS variables using our `getCssVariableDeclarations` helper function:

```tsx
function (options) {
  const { colorThemes } = options
  checkForValidColorThemesInput(colorThemes)
  return function ({ addBase }) {
    addBase({
      ':root': getCssVariableDeclarations(Object.values(colorThemes)[0])
    })

    Object.entries(themes).forEach([key, value] => {
      addBase({
       [`[data-theme="${key}"]`]: getCssVariableDeclarations(value),
      })
    })
  }
}

```

And if it's valid in our second argument, we extend the Tailwind config theme object with our `getColorUtilitiesWithCssVariableReferences` helper function where we grab the first object in the theme options:

```tsx
function (options) {
  const { colorThemes } = options
  return {
    theme: {
      extend: {
        colors: getColorUtilitiesWithCssVariableReferences(
          Object.values(colorThemes)[0]
        ),
      },
    },
  }
}

```

Now we’ve done this work, anyone can:

* use this plugin
* register the plugin in their config file
* pass their own themes object

The plugin we created will take care of generating all the CSS variables and the custom utility classes for everything to work!

The .withOptions method enables configuration options within our plugins, providing a more flexible experience for developers.


Enable and Validate Plugin Configuration Options

Determine How to Pass Options to a Plugin

Congratulations! You've completed the multi-theme strategy module.

We're only just scratching the surface of what you can do with the Tailwind plugin API, or even with the theming strategy.

Right now, we're only changing theme colors.

What else could you do next with this plugin?

You could implement theming tokens for border radius, shadows, or font-families.

The approach for that would be very similar to what we did in this workshop! You'd create CSS variables in the `:root` scope and theme scopes that hold the values you'd need for each theme, then you'd extend the Tailwind config's `theme` object with utilities that consume those variables.

That’s just one idea for something to try next. As you move on from this workshop, remember that your new superpower of combining CSS variables with the Tailwind plugin API will help you achieve just about any theming customizations you can think of.

## Case study: Feather.so

I've made [a YouTube video](https://www.youtube.com/watch?v=ahs9e4Y7ca8) showcasing an interesting real-world application of the Multi-Theme Strategy you've just built in this workshop.

It's a bout a SaaS application called Feather, which lets you turn a Notion database into a blog in a few minutes only.

Bhanu, the creator of Feather, attended the first live zoom workshop for this Multi-Theme Strategy module.

A few days later, he had rolled out the first iteration of a color theme picked into production for Feather!

Here's the video, enjoy!

Great job! You've finished the multi-theme strategy module. Tailwind plugin API has so much more to offer. Keep exploring the possibilities of theming.

Level Up at Tailwind CSS

Multi-Style Tailwind Components

Tailwind Multi-Theme Strategy