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

Multi-Style Components Workshop Welcome

[0:00] Welcome to the Multi-Style Tailwind Components workshop. Together, we're going to learn strategies and patterns to handle multiple style variants with Tailwind CSS.  
  
[0:09] Think of a button that can have a size prop that changes the button size, a look prop that changes the colors, maybe a shape prop that will change the border radius of the button. The combination of those props brings some styling complexity, especially when factoring in how Tailwind's just-in-time engine works.  
  
[0:27] All right, speaking of buttons, let's jump into our first workshop section.

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

[0:00] In this first section, we're going to work with a series of buttons. These buttons have multiple variants. You can see an Impact variant that changes the color or intensity of the button. We also have a Size variant and a Shape variant.  
  
[0:13] The way these buttons are currently implemented is not ideal. They're just hardcoded HTML button elements and you can see a lot of Tailwind classes repeated over and over. 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.  
  
[0:31] Here's sort of how we want these button components to be used to generate the same buttons as the example we've just looked at. There are a few rules and gotchas around what you should and shouldn't do when working with Tailwind's just-in-time engine to make sure things work properly.  
  
[0:46] For example, you cannot construct dynamic classes, something like this. div class = bg- and then interpolate props.color. This will not work. In this workshop, we'll discover patterns and techniques that work around those just-in-time requirements.  
  
[1:01] Ready to jump into the first challenge? Let's go!

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

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

Identifying Common Classes

Instructor: [0:00] Let's take a look at our hardcoded buttons and try to identify common classes. Looking at the code for our first button, which is this one here, classes like the first one, rounded-md, are not likely to be common to all.  
  
[0:12] It's probably a Shape class here. Similarly, background classes are likely an Impact prop, the padding x and y, probably a Size, etc. So far looks like none of these classes are common to all buttons.  
  
[0:25] Next, we have font-semibold. To me, it looks like every single button has the same font-weight. Let me highlight that class. You can see that when I highlight one, it highlights the other instances of that. It looks like every single button, yep, has that font-semibold class. I will copy this, and in our button components, I will store in the baseClasses this first fontSemibold class.  
  
[0:52] Going back to the hardcoded buttons, text color, shadow, hover, background color seem very specific to Impact. Focus classes though, focus-visible, outline-none, and then ring-2. If we take a look at the focus styles, you can see that every button has very similar focus styles, using the ring utilities.  
  
[1:14] There's a good chance that we can grab focus-visible, outline-none to undo the default styles, and then ring-2, ring-indigo-500, ring-offset-2, at least.  
  
[1:26] Then we have these active styles and disable styles, so you can see translate-y-px, and this is the little spring effect going down by one pixel that you can see when we click or hit the space bar when focused. Again, all the buttons have that effect.  
  
[1:42] We're going to not only select all these classes, but also the active class, the disabled class, and the disabled, opacity. I will select all these classes here, and add them alongside our baseClasses. We can scroll down here, and down here on our className attribute, I want to for now pass just the baseClasses.  
  
[2:07] You can see the buttons have changed slightly. They have the semibold font weight, the little translate effect on Active, and they should have a blue ring outline when focused. Not looking great just yet, but this is a great starting point. Now we're going to start implementing the individual styles based on each variant.

Extract Common Base Classes

Instructor: [0:00] All right, here's your very first challenge. At the top here we have our hardcoded buttons we've just looked at with different variants for impact, size, and shape. Here's the code for it. You can see there is a lot of repeating tailwind classes throughout each button, which is not great.  
  
[0:17] What we want to do down here is extract the tailwind classes that are common to all button variants. We already have a button component in place. You can see we have props for impact, size, and shape with the different possible values. Here's a button component. You can see that currently it has no styling applied.  
  
[0:36] What you need to do in this challenge is take a look at the hardcore buttons file and identify and extract all tailwind classes that are common to all buttons and store them in this base classes variable. Then once you've done that, you can add your base classes variable here.  
  
[0:53] The buttons here are not going to look finished, but they should have some common traits that are coming from these common classes used on these buttons up here. Good luck.

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

Customizing the Tailwind IntelliSense Plugin for VS Code

[0:00] You might take this for granted, but did you notice that we had the Tailwind IntelliSense extension working within our BaseClasses variable? You can see it right there, we've created these BaseClasses variables, where we store a series of Tailwind classes, and Tailwind IntelliSense is working.  
  
[0:14] We have these hover information panels, we can see the color swatch, and if I start typing something like dark text red, you can see we have the autocomplete suggestion working perfectly. This is not a lucky accident, I've opted for a naming convention here.  
  
[0:29] Check this out, if I change the name of the BaseClasses variable to BaseClass, all of the Tailwind IntelliSense goodness will vanish. I don't have any hover information, I've lost the color swatch, and if I type something, even if I press Ctrl space, I am left on my own.  
  
[0:45] If I bring it back to BaseClasses, immediately everything is back. That happens because I've customized the Tailwind IntelliSense extension options, as I'll show you right now. I'll use the comment palette to open the settings, and we'll choose the UI here, and search for Tailwind.  
  
[1:01] You can see the Tailwind CSS IntelliSense extension here, and we have this class attributes option, and you can see I've added this period star, classes, period star. Basically, this means that anything that has some characters, following by classes and then some characters, will be a scope where Tailwind IntelliSense should do its thing.  
  
[1:21] By default, the scope of the Tailwind IntelliSense is just class, class name and ng class to support React and Angular, but I've added this .classes naming convention, which means that I can kind of write on this naming convention to benefit from the Tailwind IntelliSense.  
  
[1:36] Right now, we don't have any IntelliSense goodness, but if I change the name of this object to thing classes, you bet, now Tailwind IntelliSense is working inside there, font, semibold, very cool. That's one of the ways you can extend the surface area where the Tailwind IntelliSense will help you.  
  
[1:53] If you want to go deeper with more control, there's another way to do it. Back in our Tailwind IntelliSense settings, there is another setting called experimental.classRegex. You can edit this in your settings.json config. This is kind of tricky. It takes an array of arrays and each array has two values.  
  
[2:09] The first one is the container that wraps the scope where you want the Tailwind IntelliSense to work. The second one is a class list matching pattern. Here, I've tried another approach where I could have this tw comment before and after something where I wanted to have access to Tailwind IntelliSense.  
  
[2:27] That's a nice opt-in strategy, but it does leave some strange comments inside your code. You can see I've also created support for a cx function that we'll use throughout these challenges. In this project, we have this cx function in a utils folder. I could have something like const other thing, a string of text green 300 text 4xl.  
  
[2:49] There's no IntelliSense happening here, but I can wrap this in a cx function and that will bring IntelliSense support once again. These are two ways to extend the surface area where Tailwind IntelliSense can help you. This is going to be very valuable for us in these challenges.  
  
[3:06] I've added these customizations in the root of this project in the vscode settings.json file. The support that we've just looked at should work for you out of the box from the next challenge onwards.

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

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 

Instructor: [0:00] To identify what classes we want to apply to different impact variants, let's take a look at the Hardcoded buttons. We're looking at these three buttons up here. The code for them starts here.  
  
[0:11] It's quite clear that the primary concern of the impact variant, in terms of visual styles, has to deal with colors. We have a dark background and white text for the bold variants. A light background and dark text for the light variants. A transparent or very light background on hover for the none variant.  
  
[0:28] Looking at the classes, we can identify this bg-indigo-500 background color, which is this one, the text-white. The hover-bg-indigo-600, as you can see on hover. Background color, text color, and background hover color is essentially the main three classes that the impact variant deals with.  
  
[0:47] It might be a bit hard to see, but the bold variant also has a subtle shadow below the button, which the other variants do not have. You can see the shadow-md class here, which is also undone when the button is disabled. You can see that the light and none variants do not have this shadow, but they do have a background color, a text color, and a hover background color.  
  
[1:11] Let's scroll up. For the first button, let's grab a little bit more. We're going to grab all of this and copy that. We'll go in the button. Remember we have these impactClasses that uses a TypeScript record. The nice thing about TypeScript here is you can see a suggestion of the three keys that this impactClasses object should have.  
  
[1:30] Let's start with bold. Here we can paste our strings, but remember we have a little bit too much here. We want to get rid of the padding classes, the font-semibold class. We're left with background color, text color, the shadow that is specific to the bold variants, and the hover background color. Nice.  
  
[1:47] The next key of our object will be light. For this, let's check the second button classes. We are going to grab bg-indigo, all the way to the hover background color too. Paste it here. We'll remove the padding classes and the font weight. We'll do that one more time. Command space, you can see that only the none key is available left.  
  
[2:10] Notice how now we're satisfying the conditions for this record. There is no more red underline. If we had a typo in one of the keys like nonne, you can see that now it's going to tell us that none does not exist in our record. Also, if we're missing a key, now the error is at the object name level, and it's telling us that the none property is missing.  
  
[2:31] That's super useful to make sure that we reflect each possible variant for a prop. Which is key, because we're going to rely on accessing these keys when we apply our styles in the className attribute.  
  
[2:43] For the none variant, we'll go down here, and this time we have bg-transparent, text-indigo-700, and hover: bg-indigo-50. Copy, paste, remove the extra classes we don't need, and save. That is our impactClasses object complete.  
  
[3:01] Now, we can go down here. Remember we have this cx( ) function that lets us combine multiple variables that hold classes like this, cx (baseClasses, impactClasses). If I save this, it's not going to work, because impactClasses is an entire object. What we want to do is specify which key we want to reach for.  
  
[3:25] For example, if we are reaching for bold, you can see that now all our buttons have the bold variant. If we had light, all of them are lights. What we want is to dynamically reach for the correct key based on the prop that is passed to the button.  
  
[3:40] What we can do instead of hardcoding the value here is to use our impact prop, which is exactly that. It's either bold, light, or none. When I save this, you can see that now the first variant is bold, second is light, and third is none. Then all the others are bold, which is equivalent to what we have up here.  
  
[4:00] We have successfully implemented the impact variant styles and composed this with the baseClasses already in place. Now, we can continue the process with the other variants to complete our button.

Simplify Button Styling for All Possible Variants

[0:00] We've extracted command classes to all of our buttons. Now we're going to tackle the Impact variant and handle styles for all possible variations. The Impact variant has three distinctive styles, Bold, Light and None. Our button has prop types here and the impact prop reflects these three possible values.  
  
[0:18] We've extracted the base classes in the variable as a string, and similarly we want to store the different possible class combination for the impact prop in a Tailwind sort of lookup directory. Instead of doing complicated ternary logic in the className attribute, what we want to do is have an object, a lookup object that has a key for each possible prop variants and then stores a string of the classes we want to apply for that variant.  
  
[0:44] All right, so here below our base classes you can see that we have an impactClasses object, and this object should have a key for each possible impact value, so Bold, Light and None. To help us provide the correct object shape, we're going to use a TypeScript record here. If you haven't used TypeScript before, don't worry, I'll explain to you what happens.  
  
[1:04] We define the type of these impactClasses as a Record, which is a series of key value pairs where the key is the ButtonProps ['impact'] . You can see if I hover over it that it tells us it can be "bold", "light" or "none". Those are the keys of our impactClasses object, and the values will be a string, which is a series of Tailwind classes.  
  
[1:26] Setting up that record type like so ensures that this object here will have one key for each possible prop variant. Your job in this challenge is to identify what classes are specific to the impact prop and then organize them for the Bold, Light and None variants inside these impact classes and then combine our base classes here with the impact classes.  
  
[1:49] You can see as a helper there is a little cx() function here imported at the top. It's a helper function that lets you pass multiple classes separated by commas and then we'll do the work to merge them together as one big string of classes.  
  
[2:02] You can use this to combine the baseClasses with our new impactClasses and our buttons down here should start taking the impact variant styles, getting a little bit closer to this and to what we're working towards.

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

Creating Dynamic Style Variants 

Instructor: [0:00] Let's start this time by defining the shape of the objects that we want to create. For the sizeClasses, we need to cover the large, medium, and small variants. Let's start with large, set an empty string, medium, and small. The TypeScript error is gone.  
  
[0:16] For the shapeClasses, we're going to cover square, rounded, and pill. You can see that without having to refer to the ButtonProps type, I can use the autocomplete suggestions and easily create the object shape that is required to make sure we cover every possible variant.  
  
[0:35] Let's start with sizeClasses. I will scroll down to the size variants down here. What's affecting the size here is likely the font size and the internal padding inside the button. For the first one, px-7, py-2.5, and text-lg as well. I think everything else is out of the size concern. I'll copy these and paste them in the large variant.  
  
[0:59] Going to the second one, the medium one, we have px-5 and py-2. We do not have a font size here, because I guess the font size is the base, the normal default font size. I'll paste the padding classes here.  
  
[1:14] I think it's worth here explicitly specifying the font size with text-base, not only to communicate the intent, but also possibly reset the font size if a parent element sets the font size to something else. Here, I will specify text-base.  
  
[1:28] For the third one, the small variant, we have px-3, py-1, and text-small. Let's try to blend these sizeClasses alongside the baseClasses and impactClasses. SizeClasses, and we'll reach for the dynamic size prop value. Hit Save. You can see our buttons are taking shape rapidly now. We can see the different sizes here working.  
  
[1:54] Essentially, what's missing is the shapeClasses, the rounded corners, the pill button. Everything else seems to be falling in place really nicely. Good stuff.  
  
[2:04] Let's go and implement the shapeClasses now. I'll continue going down for the shape variant. Here, we're most likely looking for just rounded corner classes. The square has no class. We can see here for the rounded, it has rounded-md.  
  
[2:20] Once again, we could leave an empty string for the square variant, but let's explicitly set rounded-none which sets the border radius to zero pixel. We've seen that the rounded was using the rounded-md class. I'll paste that one here. The pill variant uses the rounded-full class.  
  
[2:41] One more time, let's go in the className attributes. We're going to compose one more variant. The shapeClasses reaching for the dynamic shape prop. Our buttons now look really nice.  
  
[2:56] Let's do a quick recap. We've taken a series of hardcoded buttons with a lot of repeated classNames for each button, and then essentially organized our classes within different style concerns. Then, we composed these parts together dynamically inside the className attribute, which allows us to organize dynamic styles in a really elegant and organized way.  
  
[3:18] The baseClasses is a string that stores every utility class applied to all of our buttons. Then, we have our impactClasses for the bold, light, and none variant. You know what, I just realized that for the bold variant, we have a shadow here. We forgot to implement the disabled reset of that shadow.  
  
[3:35] If we look at the bold hardcoded button, when the button is disabled, we undo that shadow. I'm going to copy this and add that one to the bold variant. These are our impactClasses, setting the background color, text color, and as you've seen, the shadow.  
  
[3:52] I'll remove this comment here. Then, we have the sizeClasses, setting padding classes, and font size classes for the different variants. The shape classes do the same for the rounded corners.  
  
[4:02] Once we have all these styles lookup objects put together, we compose them together in the className attributes. We have the baseClasses. Then, for each prop, we reach for the dynamic prop value passed for the impact, the size, and the shape.  
  
[4:16] By doing so, each button gets the correct mix of Tailwind classes applied without having any complicated logic inside the className attributes. Instead, we have all our styles organized in one place, this Tailwind classes lookup directory.  
  
[4:30] All of the classes used for all of our buttons are organized in one place, and we don't use any interpolation to create dynamic classes. Everything is going to work really well with the Just-In-Time engine.  
  
[4:41] Let's scroll down here and play with it a little bit. I'm going to change the props passed to the first button here. It's this button right here. You can see it doesn't have any props, because it's using all the default values which is bold, medium, and rounded.  
  
[4:55] I'll just change the text here to Pro Tailwind. Let's have some fun with it. I can change the impact. You can see the auto suggestion. Let's change it to light, maybe change the size to small, and the shape to pill.  
  
[5:10] Let's make the impact back to bold by removing the prop. You can see that everything is working really well. If I add the disabled attributes, there is no point or events, no shadow, and everything is working really well.  
  
[5:25] All our nine buttons are displayed here within these 15 or so lines of code. You can see that this is incredibly more pleasant to work with and maintain than what the hardcoded buttons look like when we're repeating all the Tailwind Classes.  
  
[5:40] Hopefully, that gives you a good idea of how you can organize your styles and compose multiple style concerns together. Up to this point, there wasn't much complexity in our buttons.  
  
[5:50] We always had objects with strings inside of them, but this approach of having style lookup objects can also handle more complex scenarios as we'll see in the next challenge.

Implement Size and Shape Variants

[0:00] 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. We've taken care of the impact variants. We now want to repeat the same process for the sizeProp and the shapeProp.  
  
[0:16] Down here, after creating our baseClasses and impactClasses, we're going to repeat the same process for a sizeClasses object and a shapeClasses object.  
  
[0:24] Once again, TypeScript will guide you through the process. Once you have created these objects and you add them to the class name attribute, you should have the buttons below here look exactly like the buttons at the top.

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




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

Instructor: [0:00] Let's make the tone prop and the impact prop work together. Our new tone prop has three values -- default, danger, and success. We want to combine this with the impact -- bold, light or none, possible values.  
  
[0:13] Scrolling down, I'll remove some of this comment here to have a bit more space. You can see, the default tone should take the same color as the current one, which is the indigo. Then, the danger would have red with the same number shades, and success will have green with the same number shades.  
  
[0:29] We want to satisfy our new impactClasses shape, which is a Record where the keys are the tone prop, so default, danger, success. Then the values, instead of strings, are a new Record key-value pair, where each key is the impact, so bold, light and none.  
  
[0:45] If I press Ctrl+space, we should see the tone props here. We would have default, and then nested inside of this, we would have an object which has the three impact props. I could move all of that up here. This would satisfy the first default prop value. Then I can copy that a couple of times and change the keys to -- TypeScript should tell me -- danger and success.  
  
[1:11] You can see we've now achieved the correct impactClasses object expected shape. We want to keep the same shades, so 500, 600, 100, 700, etc., but we want to change the actual underlying color. We'll keep all of the default stuff to indigo, change all of the danger stuff to red, and change all of the success stuff to green.  
  
[1:37] As you can see, it's not working. We have broken all of our color styles. You can probably guess why. If I scroll down to the className attribute, for our impact classes, you can see we reach directly for the impact. Remember, impact is bold, light, or none.  
  
[1:52] We look for impactClasses.bold, for example. ImpactClasses doesn't have a bold primary key. It's nested now inside default, danger, or success. We need to reach for, first, the tone prop with the dynamic tone value, which is one of these three, and then reach out for the dynamic impact value.  
  
[2:12] Before the impact, I will first reach for the tone prop. When I hit Save, the buttons should take the exact colors that we're expecting. Check this out.  
  
[2:23] Are we done? We're not done. Look at this. If I tab through the buttons here, you can see that our tones have specific ring colors. Right now, if I continue tabbing through the buttons, check what happens. The danger tone and success tone are still using the indigo ring color. We've got to fix that.  
  
[2:45] If I scroll up here, the reason this happens is we have abstracted at the very beginning the focus colors, using the Indigo class here. Everything else can remain in the base classes. We just need to take out the focus-ring color here, so I will cut that. In our impactClasses, we need to implement this.  
  
[3:07] Now we're in a bit of a dilemma because we want our focus-ring color to be applied to all three possible impact prop. We have two options. We can copy the same focus class in all three impact variants, but you could come up with the base impactClasses string that you then compose with the rest if you really wanted to avoid having three times the same class.  
  
[3:28] It's all about finding what works for your specific requirements. Here, having the same focus-ring color three times is not a big deal. I will select the three lines and add the focus-visible-indigo-500. Then for the danger, I will paste this, but change indigo to red. Finally, for success, I will change this to green. Now when I tab through my dynamic buttons, the ring color is correct.  
  
[4:01] There you have it. We now have a Button component that composed four different style variants together. If you look at the className attribute in our Button component, everything is composed together without complexity creeping in. This is easy to read and reason about.  
  
[4:14] All our styles are composed together in a styles lookup directory, in one place, all in full strings, to play nice with the Tailwind just-in-time engine. Nice.

Separating Tone & Intensity Concerns

[0:00] Just as we've finished organizing our button classes within different styles lookup objects, here comes the product manager with an adoscope new request. 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.  
  
[0:17] This tone prop clearly impacts the colors of the button, and up to now we were using the impact prop to handle the styling concern of colors, so we have to revisit that. Thinking of it and looking at the name of the impact props, it feels to me like Bold, Light and None, instead of color concern could be intensity concern.  
  
[0:36] The Bold has a very intense dark color and bright text, and then the Light has a subtle light background and dark text, and None has virtually no background except on hover.  
  
[0:46] If we look at the different tones, the same bold concerns are applied. We have a bold strong color for Bold, a Light bright background, and transparent for the None variant.  
  
[0:59] We might be able to split our color concerns into two components, intensity and color. What if we make the tone prop responsible for the actual color of the button, and the impact prop becomes responsible for the intensity of the shade? I'm talking the 50 to 900 shades of the tailwind colors. I think that will work.  
  
[1:17] Here's your challenge. The impactClasses object has now changed its type. We have a nested record that uses the tone and the impact props together. You can see that TypeScript is not happy because this is not respecting the new shape of this impact classes object. Your job is to update this and separate these concerns between intensity of the color and the actual color. Good luck.

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

[0:00] In this section, we'll take a naive, basic model 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 model's size, tone and sliding animation direction.

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.

Refactoring to use Headless UI

Simon Vrachliotis: [0:00] Let's convert our component to a Headless UI Dialog component. It's already imported at the top here, and I'll scroll down, and all I need to do is replace the parent most div with the Dialog component. Now I will pass the open and onClose props to the Dialog component, and with just that we should already have greatly improved our modal component.  
  
[0:22] If I open the dialog now, and then try to scroll down the page, I promise you I am scrolling on that wheel, nothing is happening, the body scroll is locked. If I start tabbing through the focusable elements, you can see that the focus remains trapped within the modal, we never focus on the body background element. This is great.  
  
[0:40] Let's try to close the modal using the keyboard. I'm going to hit the escape key in three, two, one, bling! You can see that it worked perfectly. This was a huge win, and well worth the minimal effort of converting a div to a Dialog component.  
  
[0:54] We can even further simplify our implementation if we go to the page where we're using that modal. Check this out. Right now, we have this isOpen piece of state, and then we conditionally show the modal based on the piece of state. We can get rid of this isOpen check. The modal component will be able by itself to decide whether or not it should be showing.  
  
[1:13] If I save this, we have simplified the logic here, and everything still works perfectly. This is a great start. Let's now look at the things we can still improve. If I open the dialog and try to close it by clicking outside the modal, nothing is happening, the modal is not closing.  
  
[1:29] We can improve this by making the component aware of this panel area. In the modal component, if I scroll down here, you can see the modal panel, which is this panel. We're going to replace this div with Dialog.Panel, so that now Headless UI knows what is considered outside the panel. When I click on it, it will close the modal. Great.  
  
[1:51] The last improvement we'll do is replace the h2 here with the Dialog.Title component. You can see right now we're using a simple h2 tag with no other attributes.  
  
[2:00] By converting this to a Dialog.Title, you won't see any difference, but if I go in the browser and open the DevTools, you can see we're still using an h2 element, which is the default, but we also have extra attributes like an id here. If I scroll up, you can see our modal wrapper is using the area labeled by pointing to that id.  
  
[2:19] With very minimal effort, we've made our modal components more accessible and more usable. Now we have solid foundations in place to start thinking about implementing multiple style variants with Tailwind CSS.

Convert a Modal to a Headless UI Dialog

[0:00] Let's take a look at the basic model component we're starting with. Here's an in page example, so if I click the button, the model will show, and then I can cancel or confirm to close the model.  
  
[0:10] 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 I've added some page contents to bring some context and be able to discuss some of the shortcomings of the current implementation.  
  
[0:24] Right now, the model component looks pretty good, but it's lacking some really important features in terms of accessibility and usability. A model, when open, should technically freeze the background and prevent the body from scrolling, but right now, if I try to scroll the background, you can see that it scrolls freely.  
  
[0:41] Another thing a model should do while open is trap the focus within the model. Right now, if I hit the tab key, you can see we'll go on the first link, and then first and second button, but if I keep tabbing, we will end up into the focusable elements in the background page, and that's not what we want.  
  
[0:58] Another shortcoming is the only way to close the model is click one of the buttons. I can't click outside here, or I cannot hit the escape key, this won't do anything. All of this behavior, scroll locking, focus trapping, keyboard navigation, are essential to a model component.  
  
[1:14] Before we implement multiple style variants to our model, let's improve the usability and accessibility by using Headless UI. Here's your challenge. At the top of the model file, you see we already import the Dialog component from Headless UI.  
  
[1:27] Your job is to turn this component into a Dialog component, and then also convert the components to use the Dialog. Panel and Dialog.Title components, and this should put us in a really nice place.

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.

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

Refactoring for Dynamic Modal Contents

Simon Vrachliotis: [0:00] Let's take it step by step and start with the title prop. Right now, it's saying Confirm subscription, and if I scroll down the text is here. In my index page here, I will add a title prop with "Helloooooooooo." Before it works, I need to implement that, so let's replace the hardcoded text with {title}. Nice, I'll change this to "Confirm subscription."  
  
[0:28] Next, I want to implement the whole body copy here, and if I scroll here, you can see that this here is the body, so I'll copy this whole div right there and here we would use the children prop.  
  
[0:41] Right now, we should have an empty body, so instead of having a self-closing modal component I will have an open and closing modal tags, and in here I will paste the whole markup that I've copied. With a bit of luck, we have our modal copy once again.  
  
[0:58] Beautiful, the last piece of the puzzle is our actions here and you can see TypeScript is telling me that we're missing the 'actions' prop. Let's give ourselves a little bit of space here. The beauty of TypeScript is it will tell us what we can and must use.  
  
[1:12] Let's start with the confirm action. It needs a label, "Yes please!" and for the action we'll have a function that for now just closes the modal so setIsOpen(). Let's also add a cancel action. The label here will be "No thanks." and for the action we'll do the same, a function that sets the IsOpen prop to .  
  
[1:38] None of that is implemented yet because it's still hardcoded in the modal component. Let's go there, scroll down to find the action buttons, there they are. The first button here is the Confirm action so the text can be actions.confirm.label, and you can see I don't even have to type. The action instead of just onClose will be actions.confirm.action.  
  
[2:05] You can see that now the button says Yes please! And when I click it, it will close the modal. Nice. We can do the same with the cancel action. onClick we want to fire the actions.cancel.action, and the label will be actions.cancel.label.  
  
[2:23] Beyond that we only want to show this button if there is an actions.cancel object passed in the actions prop, so let's check here if actions.cancel and if that's the case render our button. Let's hit Save and now we're expecting our buttons to say Yes please! And No thanks, and sure enough they do. Great stuff.  
  
[2:45] This is awesome, and now I promise we can go and implement the multiple style variants with Tailwind CSS.

Update the Modal to Support Dynamic Contents

[0:00] Before we implement multiple style variants to our modal, let's make the content of this modal dynamic. Right now, we're just calling a Modal component, and all of the content, the title, the body of the modal is hardcoded inside that component.  
  
[0:13] If we look at the modal, we can identify what sort of data we would like to pass to it. We definitely want a title, we want a modal body, and then we have this action buttons section here, which could be called actions. This is the main three pieces of data that we want to make dynamic for this component.  
  
[0:30] I've prepared the terrain for you, so we have our open and onClose props already, but we've added some new props now. A title prop, we will pass the content through the children prop, and then we have this actions object.  
  
[0:43] We have an optional cancel action, because some modal will have only one confirm button, which receives a label string and an action function, and then a mandatory confirm action, again a label and an action.  
  
[0:56] Your task in this challenge is to pass these props to the modal component when calling it here, and then of course in the modal component replace the hardcoded title, body, and actions to consume the props that we're now passing to it. Good luck.

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

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

Instructor: [0:00] We have this new size prop which can be "small", "medium" or "large". We want to populate our sizeClasses object and add a max-width container for each. Before we do that, let's understand what element we need to style with these classes.  
  
[0:12] We have a Dialog component with the background overlay. The place we want to apply a max-width container is the Dialog.Panel here. Specifically, we have this small breakpoint class max-w-lg. To me this is the class that we need to make dynamic with the sizeClasses object. Note that there is no max-width container by default. It's only applied from the small breakpoint and up.  
  
[0:35] We have this small breakpoint and up specified, so let's go and populate this object. I'll scroll down a little bit. Ctrl-space to toggle the options. Let's start with small. Here we want at the small breakpoint max-w-sm. For the medium size at the small breakpoint, we'll have max-w-lg, and for the large we'll have small max-w-2xl.  
  
[0:58] All right, now let's go make the class dynamic. I will make the whole className attribute here use the cx() function, and I will delete this max-width container at the small breakpoint. Instead, we will reach for the sizeClasses object and get the dynamic value of the size prop, just like we've done before.  
  
[1:20] Let's verify that it works. Small modal. Yep, that looks pretty small. Medium and large. Good work.

Add Multiple Modal Sizes

[0:00] In this challenge, we want to add support for a size prop for our modal components. This time we have three toggle buttons, small, medium, and large. Currently, they all display the same modal size.  
  
[0:10] Here's what the modal sizes should look like. The small size should use max width of small, the medium size, max width of large, and the large size, max width of 2XL.  
  
[0:20] In our modal component, we've added a new prop called Size which can receive small, medium, or large. Similarly to what we've done with the button Component, we have these size classes object here, which is typed as a record using the size prop.  
  
[0:33] Your job is to populate this object with the classes mentioned here so that our three models are displayed at the correct size. You know what to do. Good luck.

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

Add Modal Background Color Support

Instructor: [0:00] Looking at the examples, the obvious two things that we should change style-wise is the background overlay color and the button colors. Let's look at the markup for the modal and start with the background overlay.  
  
[0:11] Here it is, and this class here, bg-indigo-300, should probably be the one made dynamic. Let's go in the toneClasses object, and we'll start with default. Here, we'll go with bg-indigo-300, and then for danger, let's go bg-red-300. Finally for success, bg-green-300. That should do the trick nicely.  
  
[0:34] Then to implement that, we are going to replace this hardcoded class here. Let's turn the className attribute to use the cx function, like so. Then instead of having the class in there, we can remove it and pass it as toneClasses reaching out for the tone.  
  
[0:55] That still works, but now the Danger has the nice red overlay, and the Success has the nice green overlay. Obviously, the buttons are still using the default tone. Here you might start thinking, I need to pass some classes to the buttons to style them as well but remember the button component does have a tone prop already.  
  
[1:13] Instead of passing classes to style the buttons, we can pass the tone prop that we receive inside the modal and pass it to the Button component and this should do the trick. Where we have our action buttons down here, all we need to do is to pass the tone prop.  
  
[1:29] You can see here it tells us what possible values are, and here we will pass the tone prop further down to the buttons. Let's try. Danger, nice. Success, excellent. It's working great.

Implement Modal Background Tints

[0:00] The next style variant we're going to implement is a tone prop. Take these three buttons that suggest different tones for our modal. This is the default tone. For now, they all are using this default tone.  
  
[0:11] What we want them to look like, is like so. The default tone is as it is now. The danger tone has this red tint. The success tone has this green. You can probably recognize the buttons that we have built in the previous section. Our modal component has now one more prop added to the prop types.  
  
[0:30] You can see the tone prop using the ButtonProps ['tone'] . We're not listing manually the different values like we do for the size, but we're grabbing the tone props that we had on our buttons previously, which are "default", "danger", and "success". You can see at the top of the file here we're importing this ButtonProps from the button component.  
  
[0:49] Your job is to populate this new toneClasses object. You know the drill. You need to figure out what you should be styling with this toneClasses object and then go and implement it. Good luck.

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

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

Instructor: [0:00] I'll start by wrapping our Dialog component in a Transition Root component, so I'll scroll down in here, Transition.Root, and let's move the closing tag at the end of the component. As you can see we're getting an error because our Transition component needs a show prop which is set to true or .  
  
[0:19] Basically, here we want to base this logic on the open state of the Dialog. Show equals open, which will fix the problem, and we can now actually remove the open prop on the Dialog component because it's able to derive that information from the Transition component.  
  
[0:37] If you try to toggle the modal everything still works. We don't have any transition animations yet so let's do that now. The first element we want to animate on enter and leave is the background overlay which is this div here. Let's wrap this in a Transition.Child this time.  
  
[0:54] Our Transition Child component will have a series of props where we can pass some tailwind classes to handle the transition animation. We'll have enter, enterFrom, and enterTo. Then the same for leave. Leave, leaveFrom, and leaveTo. In the enter prop, we'll have tailwind classes that should be there during the entire enter life cycle. We want "transition" and "ease-out."  
  
[1:22] Then remember we want to fade in this background overlay, so we can do, from, "opacity-," to, "opacity-100." Let's try that. Nice. You can see that the background fades in on enter slowly but it still disappears instantly.  
  
[1:40] For the leave transition, we'll essentially do the exact opposite. "Transition ease-in," and with leaveFrom, "opacity-100" to, "opacity-." Let's try that. Fade in, fade out. Very nice.  
  
[1:56] Right now, our background overlay fades in nicely but the model panel itself just appears and disappears abruptly. That feels a little bit odd, especially on leave, and we can fix this with another transition trial. It will be slightly similar, so I will copy the first Transition Child with all the props as a starting point.  
  
[2:15] Let's scroll down to the Dialog panel right here. I will paste a Transition Child wrapper here around the Dialog panel, and let's move the closing tag after the closing Dialog panel. Right now, both the background overlay and the panel should have the same fade in and out animation. That looks nice, but we can make things much nicer.  
  
[2:35] Remember we want to slide in from the bottom, so instead of opacity to 100, our enterFrom animation will go from "translate-y-8" to "translate-y-." We start off the enter animation a little bit lower and animate into the normal position. Let's try that. Very nice.  
  
[3:01] The fade out on leave is fine, but I think we can have some fun and also make the element scale down just a little bit to add a bit of delight. I will keep "opacity-100," but also add "scale-100," and then "scale-95" percent. Let's try it out. Slide from the bottom and scale down. That looks great. Good job.

Transitioning Modals with Headless UI

[0:00] Right now, our modal appears and disappears really abruptly and I think we can improve the situation with a little bit of Enter and Leave animations. To do that, we're going to use Headless UI's transition components.  
  
[0:11] Let's open the modal. We want two different animations. We want the background overlay to fade in and then we want the modal panel to subtly slide in from the bottom.  
  
[0:21] In our modal component file, we are importing the transition component from Headless UI, and you're going to use this to apply Enter and Leave transition. We want the background overlay to fade in on Enter and fade out on Leave.  
  
[0:34] Then, the dialogue panel should slide in from the bottom and maybe just fade out on Leave. You'll need to use a Transition.Root component to orchestrate both these animations. 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.

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

Instructor: [0:00] To populate this slideFromClasses object, we need to figure out what elements we want to apply Tailwind classes to. Let's scroll down to the second transition child here, which is the Modal panel, and the SlideFrom concern lives in the enterFrom and enterTo attributes, specifically the translate classes here.  
  
[0:21] Y-8 to y- will slide from the bottom, but minus y-8 to will slide from the top. Then we can use translate-x utilities to slide from the left or right. Let's try implement these in our slideFromClasses object. Let's start with top, and remember here it's not a string, but we need an object with From and To values.  
  
[0:44] From, to slide from the top will be -translate-y-8, and the To property will be translate-y-. Then let's go clockwise with right. To slide in from the right, we need to start with translate-x-8 and go to translate-x- . Then we'll do bottom, From will be translate-y-8, To, translate-y-. Finally, for the left value, we'll go From -translate-x-8, To, translate-x-.  
  
[1:24] That should get us all sorted to coordinate our slideFrom dynamic classes. Let's go down back to the second transition child. For these two here, I'll select the two lines. We will use the cx function, and then we can delete this hardcoded class here.  
  
[1:45] Instead, for the enterFrom, we will use slideFromClasses and grab the slideFrom prop, but then we need to reach for the nested From property which will hold the starting point transition class, and I'll copy that part because the enterTo will do the same but reach for the To property.  
  
[2:05] If we've done things right, we should be able to verify the From top slides from the top, yep, From right, From bottom, and From left. It's working perfectly. Great job.

Customizing Modal Slide-In Animation

[0:00] We want to provide more control over the Slide-in Animation we've just implemented and let users decide if the panel should come from the bottom, from the right, from the top, or from the left.  
  
[0:09] We've got four model toggles here, but right now only the from bottom is honoring the slide from prop. The from top also comes from the bottom, just like all the others do.  
  
[0:21] In our model components, you know the drill. There is now a new slide from prop, which can be set to top, right, bottom, or left.  
  
[0:29] We have a style object, slideFromClasses, that needs to be populated. You can see that it's a record, but it has an object shape of from and to classes. Your job is to fill this object with Tailwind classes to make everything behave like it should. Good luck!

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

Conditionally Display a Loading Animation 

Instructor: [0:00] Let's start by simply displaying the loading pinner regardless of the isLoading state just to see how it looks inside the button. We've got this Loading Spinner component, and what I want to do inside the confirm action button before worrying about the isLoading true prop is simply display this loading spinner. Let's take a look, and here it is in all its glory.  
  
[0:23] Obviously, we don't want to show the spinner initially and it should only show up when we click the "Delete My Account" button. All we need to do to make that happen is to conditionally display the loading spinner if isLoading is true.  
  
[0:38] Now the spinner is not going to show and nothing is going to happen on click because up here, we're setting the isLoading value to by default. Now we need to go where we consume the component and wire things up. We have this isLoading piece of state which we'll be able to use but before it does anything, let's make sure that we pass it to our Modal component. I'll delete this comment.  
  
[1:02] Next, let's take care of filling up the handleConfirm function. We want to setIsLoading to true, but just to play with the UI, let's, when the button is clicked, setIsLoading to what it's currently not. This will just flip the isLoading value back and forth between true and . Now when we click on our button, it's loading, and it's not. Look at this smooth little transition coming in. Very nice.  
  
[1:28] Cool. Let's change this to true, and then we simulate an async operation for two seconds. We want to close the modal after that, setIsOpen . Save that. Now when we click the delete account it loads for one, two, and the modal goes away. Job done? Not quite yet.  
  
[1:50] Let's reopen the modal, and uh-oh, it is still loading. That makes sense. We're closing the modal itself, but the Page component which is where the isLoading state is living is still here, and so the isLoading value is maintained throughout. An easy way out of this would be to also, at the end of the async function, setIsLoading to  as well.  
  
[2:15] Now when I trigger the action, it loads for two seconds and then closes. Then when I reopen, it's closed. If you're like me and pay attention to details, you might notice something here. Let's open the modal again and watch the loading spinner carefully just before the model fades out. Loading, whoops, did you see that? The spinner goes away completely just before the modal closes.  
  
[2:41] Loading, not loading. That makes sense. We're setting isLoading to  as soon as the timeout finishes. The only reason we see that little glitch is we have these transition components that fades out the modal slowly instead of disappearing abruptly.  
  
[2:57] Here what we'd ideally want to do is setIsLoading to  after the transition has finished. After the leave transition. Guess what? Headless UI's transition component has an after-leave prop which can be used for this exact scenario.

Add Support for Async Tasks in the Modal

[0:00] We're going to add support for asynchronous task within our modal. We've added a new prop in our modal component, this isLoading prop, which is just a boolean. The modal itself is not going to be responsible for handling any of the loading logic.  
  
[0:13] It just receives this isLoading prop, which can be true or . At the bottom of the modal component, I've added a new loading spinner component, which is just a spinning SVG. Here's the modal we're working with.  
  
[0:26] We want to start showing the loading spinner when the confirm action button is clicked. Currently, nothing happens, and we're going to wire that all up. Your job in this challenge is to first set up the loading spinner to display inside the confirm button whenever isLoading is true.  
  
[0:43] You'll then need to go in the index page, where we're consuming the modal component. You can see we added this new isLoading piece of state. We've prepared this handle Confirm function, which is fired when the confirm action button is clicked.  
  
[0:57] You can see here we're calling handle Confirm. Your job is to use that isLoading piece of state inside the handle Confirm function. You can see here to simulate an asynchronous operation, we have the setTimeout of two seconds.  
  
[1:10] Basically, after two seconds, you can close the modal. If you've done things correctly, when you click the Yes, delete my account button, you should see a loading spinner here on the right for two seconds, and then the modal should close.

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

Updating State After a Transition

[0:00] This next one is not a challenge but rather a show and tell, as this is very Headless UI-specific knowledge. We want to persist the loading spinner all the way until the modal has completely disappeared, which is not the case right now.  
  
[0:12] Our Modal component is using Headless UI's transition component, and you can see different props like enter, enterFrom, enterTo, etc., but the Transition component also has lifecycle event hooks, which allow us to fire some logic before or after a transition in or out.  
  
[0:28] One of these props, let's go in the Root component here, is called afterLeave. This will allow you to run some code at the end of the leave transition, so when the modal is completely disappeared. This seems like a perfect time for us to set the IsLoading property back to .  
  
[0:44] You might think you'd want to do something like setIsLoading here, but remember, the Modal component itself should not be responsible to handle any of the logic of whether the modal should be loading or not. It receives the isLoading prop, and that's it.  
  
[0:59] In other words, instead of directly trying to change the isLoading value here, we want to emit a signal back to the parent components that consume this modal to say, "Hey, right now would be a good time to do your thing and setIsLoading back to ."  
  
[1:13] Check this out. Our modal is already receiving these sort of event props like onClose. What I'm thinking here is just like we have this onClose event, we could have a sister event called onCloseComplete, which would also be a function. Let's make it optional.  
  
[1:30] Down where we receive our props, let's receive onCloseComplete. Let's make it default so it just doesn't do anything if it's not passed. Now here we can use this onCloseComplete as our event emission to the parent, so afterLeave, we can just fire the onCloseComplete function that can be set in the parent component.  
  
[1:51] Now, once again, we're not handling any of the isLoading logic. We just give a chance to the consumer of the Modal component to execute some code after the leave transition has completed. Now we can go back to our index file here and get rid of the setIsLoading  inside the handleConfirm function. Instead, we can pass a new onCloseComplete function.  
  
[2:14] This is where we're going to setIsLoading to . With a bit of luck, when we click the button, it's going to set the loading to true. Then after two seconds, close the modal. When the close transition is complete, this is where it's going to setIsLoading back to . Let's take a look.  
  
[2:34] We open the modal, pay very close attention to the loading spinner, and see if you see it disappear or not. Hopefully it will stay until the end. When we reopen the modal, it's not there. Very nice. Let's check a second time. Spin, spin, spin, spin, spin, spin, spin all the way, and then it's set to  behind the scenes. This is starting to look pretty nice.

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

Disabling Buttons and Modal Exits While Loading

Instructor: [0:00] Let's go one step at a time and start by disabling the buttons when isLoading is true, so I shouldn't be able to click one of these.  
  
[0:07] Here, that's pretty simple. I'll select both buttons and add the disabled attribute, and the value can be linked to the isLoading prop. If isLoading is true, the buttons are disabled, which seems to be exactly what we want.  
  
[0:20] Let's give it a try. Trigger, and you can see they're disabled, and I cannot click on them. Perfect. That's step one of the puzzle, but we can still now click outside of the modal.  
  
[0:30] To solve that, we can scroll up to our Dialog component. You can see there is the onClose prop. Remember, this onClose gets fired when we click outside or hit the Escape key, so we need to pass a function in this onClose prop.  
  
[0:43] If we were to pass an empty function, we should now be totally unable to close the modal by clicking outside or hitting the Escape key.  
  
[0:52] Essentially, we want that scenario while isLoading is true. I can have a ternary operator that says that if isLoading is true, have an empty function to basically short circuit the ability to close the modal.  
  
[1:05] If it's not loading, then provide the normal onClose function passed as a prop. Now, if the modal is not loading, I can click outside or hit Escape, but while it's loading, clicking outside does nothing and hitting the Escape key does nothing.  
  
[1:23] By effectively freezing our modal while the asynchronous action is happening, we can avoid all sorts of troublesome scenarios that we don't want our users to be into.

Improve Modal Behavior During Async Operation

[0:00] In appearance, our async loading management looks really good, but there's a few issues with it. Check this out. I will open the modal, and I will try to click on the action to trigger the loading.  
  
[0:09] Cancel it immediately, and reopen the modal within the two second timeout. Ready? Trigger, stop, reopen, and it just closed again right away.  
  
[0:19] The set timeout was still running, and after the two seconds, its set is open to  and closed the modal on us. I can also close the modal mid async action by clicking outside, or by hitting the escape key.  
  
[0:33] None of these scenarios are ideal, and will likely bring some confusion and stress to your users. Did the action perform? Was my credit card charged? You don't want that to happen. We can do two things here to improve things drastically.  
  
[0:45] Once the asynchronous action is triggered, the first thing we want to do is disable the buttons. In other terms, we don't want to be able to click multiple times on the action.  
  
[0:54] The other thing we want to disable is the ability to click outside or hit the escape key. Essentially, we want to lock or freeze the modal while it's in its loading state.  
  
[1:04] The two places you'll need to operate for that is the action buttons in our modal component. You can take care of disabling the buttons while isLoading is true.  
  
[1:13] To lock the ability to close the modal, you might need to look into the onClose event here. Clicking outside the modal or hitting the escape key fires this onClose event. You've got all the tools you need. Good luck!

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

Modal State Management Patterns

[0:00] To wrap up this segment, I want to make a quick observation on state management patterns. In our ModalProps, I see two specific boolean props that share some common surface area. That typically should make you stop and think.  
  
[0:11] Open and isLoading here are managed independently. We literally have an isOpen piece of state and an isLoading piece of state. They both work together in determining whether the modal should be open, closed, or frozen while loading.  
  
[0:26] There isn't honestly much complexity in our modal, yet we've already faced some scenarios where we have a broken state. The modal is closed but loading. That shouldn't happen.  
  
[0:35] Also, with complexity creeping in, we may need more states than just isLoading. What about error, success, installing? What I'm saying is working with booleans is somewhat limiting, and working with multiple booleans working together can lead to really weird states.  
  
[0:49] A much nicer approach here would be to have one single property, an enum, that lists all the possible states that our modal can be in. The modal should only be able to be in one of these states at any time. Essentially, this would lead to a list of finite, predictable lists of possible states.  
  
[1:06] What that would look like in our code, instead of having open and isLoading, would be something like a status prop, where our modal could be open or closed, and also maybe loading. This single prop could already play the role of both the open and isLoading.  
  
[1:23] Status open would be open true, isLoading . Status closed would be open , isLoading , and status loading would be open true, isLoading true. By doing this, we remove the risk of having the modal closed but loading, like we had to cater for before.  
  
[1:40] As new scenarios happen, maybe it's been loading for seven straight seconds, and you want to have a new state called stalling, where you could display a little notice saying, "Hey, it's taking a bit longer than usual. We're still trying. Please hang in there," or something like that.  
  
[1:54] You could also use this to handle error states and so on. You get the idea. That approach to me is more scalable and future-proof, but more importantly, it removes a lot of these weird states and bugs your application can be in when you use multiple booleans combined together.  
  
[2:09] This is state management talk, but it also has a real implication on styling. In the next and final chapter of this module, we're going to refactor some codes that I wrote using multiple boolean props to handle styling, and quite frankly, made a mess.

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

[0:00] To wrap up this module, let's go on a little refactoring exercise based on some real code that I wrote. Here's the calendar app that I've built to support a lot of the Pro Tailwind materials. Things like multi-theme support, but also multiple style patterns like these background stripes here, this little caret, or the corner ribbon.  
  
[0:22] One thing that consistently gave me troubles is this calendar here. You can see a day can look different based on different scenarios. If it has availabilities, it will have this blue background, like number 9. If a day does not have any availability, it will just be dark grey on white. You can see there's no availability for that one. A day can be selected, a day can be disabled, unavailable.  
  
[0:46] When prototyping on this calendar, I've tried to use the same approach we're using in this course. I identified the common classes to all variants, and then I tried to identify a set of dynamicClasses based on what state a calendar day is in.  
  
[1:00] Then things got out of hands when I tried to compose these classes together in the className attribute. I first composed the baseClasses, and then if the button is selected, I had the selected classes. If it was disabled, the disabled classes. From there, that's where things start to fall apart.  
  
[1:16] I started to find all these edge scenarios where style should be applied to a calendar day only if the day was this, but also not that, and maybe this as well. I started to have these gradually more and more complex set of conditions, and I never landed on anything I was really happy with.  
  
[1:32] I started to look at other calendars out there in the wild to see how other folks handled the situation. Here's a calendar example in Tailwind UI.  
  
[1:40] If we look at the code, and I scroll down here, you can see the className attribute has actually quite a similar approach. BaseClasses first, and then some simple logic, and then we enter these compound conditions where we're trying to apply styles based on the combination of different factors.  
  
[1:56] If you search around the Internet, you'll find a lot of other examples like this. Turns out calendars are pretty complicated. If we look back at my dynamicClasses object, there's one major reason why things start getting out of hand, and it's the fact that a calendar day can be in more than one of these states at a time.  
  
[2:12] For example, a day can be today, but also have availability. That's tricky because these two states, style-wise, compete in the same space. They both apply text color, background color, and so you need to carefully compose them together. That's how you end up checking whether a day has availability, but also is or isn't the current day, and so on.  
  
[2:31] You can easily end up with conflicting styles applied to the same element, and have things behave unpredictably. We can draw a parallel between what happens here, and what happened in the modal challenge, where we were composing two pieces of states together to decide if the modal should show, should be hidden, should be loading.  
  
[2:48] With our current approach in this calendar, we're creating impossible states, because we're compounding multiple Boolean states together. We were talking about simplifying our modal logic by using a finite list of possible states it can be in. I think we can do exactly the same here with our calendar styles.  
  
[3:04] In this challenge, we're going to turn this complicated mess into a much simpler, easy-to-reason-about status variant for our calendar days. Each day will only ever be able to be in one single status at a time.

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

Listing the Calendar States

Instructor: [0:00] I've come up with five different statuses for the calendar days. It's very likely your list will be named different, but let's have a look at what I've come up with. The first status is the one I already hinted at and it's the selected status. That one's already in place.  
  
[0:14] Another status that made sense to me is these days in the past, or if I go six months in the future, those days that are out of range. These you can see I cannot select like I can select any other day, so those are to me disabled. The second status I'll add is disabled.  
  
[0:31] Another visual state that makes sense to me is this concept of having availability. If I change the selected day on both calendars, you can see that even if the day is today, it is styled exactly the same as any other days with availability. I will call that status, Vacancy.  
  
[0:48] Another status is the counterpart to that, days that do not have vacancy. I'll add another status called No Vacancy. We've got to be careful here because if you look at today, in the scenario where there's no vacancy, you can see that it's styled differently than any other day.  
  
[1:06] When it has vacancy, it's styled exactly the same. I think we need to add one more sneaky status, Today No Vacancy. Today No Vacancy. To me, from the thinking I've put into this, these five statuses should cover any scenario possible.  
  
[1:22] Remember, we're thinking of these statuses for visual styles. To me, a calendar day will only ever be in one of these statuses at a time. All right, let's keep going.

Identify Possible Calendar States

Instructor: [0:00] Your first challenge is to try and make that list of possible visual states a calendar day can be in. We have two instances of the calendar that you can play with here. They are exactly the same except for one thing. I'm recording this on the 12th of December. The calendar on the left doesn't have availabilities today, whereas the one on the right has availabilities today.  
  
[0:20] What I want you to do here is try to make a list of all the possible visual styles a calendar day can be in. I'm not talking about the states in terms of logic, but really visual states a calendar day can be in. Have a play around, click around, and see what you can derive from here.  
  
[0:36] Today's calendar day has different styling, but if today is selected, it looks exactly the same as a day with availability selected, a day without ability selected. It feels pretty safe to say selected is one of these visual states a calendar day can be in.  
  
[0:52] In the code, I've created a new type called Status. To get you going, I've added this 'SELECTED' state, and then your job is to try create the other states to complete the list based on your observations.  
  
[1:04] Have a play with the calendar, and try to come up with a list that makes sense for you of what visual states or statuses a calendar day can be in. Good luck.

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

Create Styles for the Unique States

Instructor: [0:00] I'll start by adding the correct keys in the statusClasses object. Since it's typed as a Status Record, I should be able to use Ctrl-space and auto-complete the keys. The first one we want is SELECTED. We'll just leave them as empty strings for now. The second one is DISABLED, third one will be VACANCY, then NO VACANCY, and finally the sneaky TODAY NO VACANCY.  
  
[0:25] Let's try port the styles over from this dynamicClasses object. The "selected" key quite obviously should be the SELECTED classes, and same with DISABLED, I can grab the ones from the "disabled" key. Now for VACANCY, I think we want the "hasAvailability" style, so I'll copy that here.  
  
[0:46] The big difference here is we're never going to have these styles clash or compose with other styles like "today." If we have NO VACANCY, this is what used to be called "candidate," so any day that is within the range. It's not in the past and it's not after six months.  
  
[1:02] The difference here is we're going to use these styles as literally a style saying, "There is no vacancy on this day that is within the range." Let's copy that here. TODAY NO VACANCY can be "today," but as we've seen, if today has vacancy, it actually is going to be having the VACANCY status.  
  
[1:23] That's where our naming conventions eliminates the possibility to have compound styles and multiple statuses at the same time. I'll paste that here, and with a bit of luck because as you've seen, everything is already wired up to work properly, let's go take a look at our reference tables.  
  
[1:40] You can see that everything is working properly. This is great. This tells us that our lookup status styles are covering every scenario properly, and so we can confidently try to implement the logic to determine which status a day should be in. Let's try to do that in the next challenge.

Porting Dynamic Styles to Specific States

[0:00] With our new calendar day status in place, I've created a little table for visual reference of these different statuses. Let's take a look. You can see the table on the right correctly displays the styles for disabled, vacancy, no vacancy, selected for both any regular day or today.  
  
[0:15] Whereas the table on the left is missing a lot of these styles. All of them look very similar. Looking at the code, the reference table on the right has all the styles hardcoded for every single calendar day. You can see how they all look individually.  
  
[0:29] Then the table on the left, which is our challenge, here's what we've got. I've ported over the status that we've created in the previous lesson. We have our base classes in place as well as the dynamic classes that we had at the start of this section.  
  
[0:41] Instead of using these dynamic classes, what we want to do is create a new statusClasses object, which is going to use our status type that we've created. This might look familiar. We created this empty statusClasses object, typed as a status record.  
  
[0:57] Your job is to populate this object with the correct keys, and then port the styles over from these dynamic classes. If we scroll down here, you'll see that this table is trying to compose these statusClasses that do not exist yet with the base classes.  
  
[1:12] Without touching any of this markup, the challenge is to make this table on the left look exactly like this table on the right, which would confirm that we have set up the statusClasses lookup object correctly. Good luck!

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

Implementing the getStyles Function

Instructor: [0:00] Let's figure out these calendar day statuses, shall we? We got the list of statuses here, and let me get rid of this comment here. I like the idea of creating a function called getStatus. Here, we want to return one of the status variants. I can type this function to be a function that returns a status.  
  
[0:23] We get the squiggles, but if I was to return -- we should have autocomplete, yep, check this out -- if I was to return one of these statuses, the type would be satisfied. If we had a typo, it would not be happy. That's perfect. Let's delete all this.  
  
[0:39] We want this getStatus function to return each of the possible statuses based on different conditions. The philosophy here is to start by short-circuiting the system as early as possible. Let's go with the low-hanging fruits to begin with.  
  
[0:54] If we go and have a look at what we were doing before, you could see that we were checking this isSelected to determine if the dynamicClasses should have the selected style. Same with isDisabled. These, if I scroll up, come from this React area's useCalendarCell hook.  
  
[1:11] You can see here with this structuring, isSelected and isDisabled from this useCalendarCell call, and that's where the calendar logic state is handled to determine if a day is selected, or if it's disabled, meaning that it's in the past, before today, or after the select range, which we have set to 6 months. Anything after 6 months from today is also disabled.  
  
[1:35] These are going to make our job easy for the first two conditions of our getStatus function. We can immediately check if isSelected, in that case, we can return "selected." Boom, that's one condition down. We can do the same with disabled. If isDisabled, return "disabled." We're already catering for these two scenarios, so we have these three left.  
  
[2:01] If I look at these three, two of them mention "no vacancy." To me, that tells me that the third one, "vacancy," can be determined quite easily. Let's look at what we were doing, and it looks like we have this hasAvailability variable here that seems to be helpful. Let's check what it's all about.  
  
[2:21] OK, so it's here. Basically, hasAvailability is signifying that a given calendar day has bookable times for that given day. Remember, in our calendar app, we have some days highlighted in blue, and these days have availability. If I select any of the days not in blue, they don't have any vacancy. Once again, that makes our job really simple here. If hasAvailability, return "vacancy."  
  
[2:52] So far, our getStatus function is extremely simple to reason about. We have two more statuses to handle, "no vacancy" and "today no vacancy." The difference between these two is quite obvious. One is today, and the other one is not. Once again, we have that information already.  
  
[3:09] You can see this isCurrentDay that we were using in multiple places. In the code, you can see that isCurrentDay checks if the day is today. This isToday function comes from the @internationalized/date package, and we can use that to continue making our function super simple, but also complete.  
  
[3:29] Because this is the last return statement, we can return and check isCurrentDay? If it is, we're going to return "today," but with "no vacancy." If it's not today, we're going to return just "no vacancy." Check this out. This very simple getStatus function returns each of the five possible statuses.  
  
[3:52] All we need to know to get the correct status is to do const status, which is a Status, equals, and we can call the getStatus function. Now, this status variable will hold the correct status based on what this getStatus function has determined.  
  
[4:11] We can scroll down, and instead of doing all this convoluted logic, we can reach for the statusClasses object, which holds all our variants, and reach for the status. What I'm hoping here is when I switch to the UI, the calendar on the left looks exactly like the calendar on the right.  
  
[4:31] And boom! Bingo! Look at this. The calendar days look identical, but this calendar on the right is using that styling approach, whereas the calendar on the left is getting everything it needs from the statusClasses using the getStatus function. If you wanted, you could skip this status variable here, and in there, directly, call the getStatus function. That works as well.  
  
[4:59] Now that everything is working, we can remove the old stuff here and there, and we're left with a pretty tidy Calendar Day component. A bunch of the complexity is in the calendar logic state, but then style-wise, we have our status type, we have baseClasses, we have a statusClasses lookup object, and a getStatus function to determine which is the current status.  
  
[5:24] Then all we do is compose the baseClasses and the statusClasses together in the className attribute. Hopefully, that lets you visualize how you would approach your specific case scenario. You can see that this technique is very scalable, flexible, and works in a lot of different cases.

Apply Styles for a Specific State

[0:00] The main reason we made a mess with our logic in the className attribute is that the original statusClasses object did not have mutually exclusive variants. There was a bunch of if this but not that or that but also that scenarios with compound styles from multiple keys in the object.  
  
[0:16] We now have a list of finite and mutually exclusive status style variants so we should be able to clear that complexity significantly. We just need to figure out how we're going to determine what status a given calendar day should be in.  
  
[0:30] In the previous sections of this module, like the button and modal components, we had a clear distinction between each variant. A component would receive a prop we could match with the variant styles. Here, we're likely going to need to use some conditional logic to determine the status of a day.  
  
[0:44] We already have our styles lookup object, we just need to know which one to reach for. We need to write some code to get the status of a calendar day so we can reference one of the variants in the styles directory we have in place. Get the status. getStatus. That sounds like a function name.  
  
[1:03] Now there's definitely more than one way to approach this but I think writing a getStatus function that returns one of the possible status variants would work pretty well.  
  
[1:13] For this challenge, you'll see that we have our Status type and the baseClasses in place, and then I've kept the old dynamicClasses object for reference but we also have the new statusClasses we've worked on. The other thing that I've commented out is the complexity that we have in the className attributes.  
  
[1:29] In the UI, I have the reference calendar which is how things should look and on the left, this is the calendar rendered by the code that we've just looked at. We don't have the styles in place, we just have the baseClasses for every calendar day.  
  
[1:42] In this challenge here's what you need to do. You're going to have to figure out how to determine the status of any given day so that we can replace all of that mess with a single reference to the statusClasses object.  
  
[1:56] We want something dynamic like statusClasses Status but obviously, you need to figure out what the status is, and I think we can all agree that referencing to one single property like this is going to be a big improvement over doing all of this logic. All right, good luck.

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

Multi-Style Tailwind Components

[0:00] 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.  
  
[0:13] You're 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.

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

0:00 Welcome to the Multi-Theme Strategy Workshop. Together, we'll combine two superpowers together, CSS custom properties, also known as CSS variables, and Tailwind's JavaScript Plugin API.

0:11 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 a theming implementation. All right. Let's have some fun.

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

0:00 A quick note about our approach in this workshop. We're going to start simple and build upon our foundation step by step. We'll do a bunch of copy/pasting around, write repetitive code, and that's all right. We'll improve our code reusability later. We'll also write some naive code first and make it more robust later. Go with the flow. Take it step by step.

0:18 We're building fundamental concepts first and keeping things intentionally simple. No clever loops or recursion before we need to. Trust me, they're coming. All right. I just wanted to make this clear before we get started. Let's go.

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

0:00 Let's take a quick tour of our starting point. Creating color palettes from scratch will send you down a deceptively large rabbit hole. We'll skip that bit. We'll kick off the workshop with a little head start, a themes object with three custom colors. You can see we have a base color, a rainforest color, and a candy color.

0:17 Then we're extending our colors in the Tailwind config with these three colors. You can see that we're sticking with the 50-to-900 color-shade name strategy that Tailwind uses. This is not required. Because we want to implement the multi-theme strategy to an existing app, this is going to make things much easier on us to be able to swap the colors using the same names.

0:38 To create these colors, I've used an online tool called Huetone. We have our three colors ranging from 50 to 900. You can see these numbers here -- 20, 36 -- that are matching for each color shade. This is the APCA contrast, which is the perceived contrast algorithm.

0:54 Essentially by having numbers that match, you can imagine that switching colors will retain a consistent contrast when switching from theme to theme. All right. This is going to be our starting point to implement the theming strategy. As you can tell right now, we are not doing any theming at all. We have three colors. We simply extend our colors object with these three colors.

1:13 What we want is to be able to use the same color utility class across all themes. We should be able to redefine the value of the color based on the current active theme. To do this, we're going to leverage the power of CSS variables.

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

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

0:00 The solution is pretty simple here. All I had to do is in the square--pink class, redefine the --color variable, and assign it the color of deeppink, and now the square is pink. Pretty straightforward, right? This CSS variable scoping is a foundational piece of our theming strategy, so I need to make sure that you're comfortable with it.

A Primer on CSS Variables

0:00 A really quick primer on CSS variables because this knowledge is essential to our theming strategy. You can define a CSS variable with dash dash and the variable name that you want and then assign a value to it. You can then consume that variable by using the var function and the variable name inside of it.

0:16 Note that our variable name here will be available within the scope to which it's been defined. Here we're using the root scope, which is the entire document. It's available everywhere. A great feature of CSS variables is they can be redefined within any CSS selector. Here I'm going to redefine the variable name to the deep pink color within the button pink selector.

0:38 Now in the button class here, the variable name consumed here will still hold a value defined as the root scope. Inside a button pink class the variable name color will have been updated. Here's a little challenge for you. We've got these two shapes here. The first one with a class of square and the second one with a class of square but also square dash dash pink.

0:58 Your job is to make the second square, well, pink. We're defining this dash dash color variable at the root scope where we use that teal color. Then in the square class below here we consume that color to apply it to the background color property. Now your job is to redefine this CSS variable inside the square pink class to make the second square here pink.

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

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

0:00 In the CSS file, I will start by defining the root scope variables. I'll open an @layer base here and target the root selector. Inside I want to define a --primary-500: CSS variable, and up here we have the color that we want to apply to it, so I'll copy that and paste that here.

0:21 The variable is defined, but nothing yet is consuming it, and that's what we're going to do in the config file. Down here I'll uncomment the primary object to extend a colors object and for the 500 shade I will here consume the CSS variable, which you can do. Remember with 'var(--primary-500)'.

0:41 When I save, you can notice that the 500 shade now has taken place. Before we implement the theme scopes, let's recreate the process for the 50 to 900 shades. Since I'm already in the config file, I'll replicate this a couple of time. Let's go with 50, 100, 200, 300, 400, 500, 600, 700, 800, 900.

1:03 Of course we need to define the CSS variable at the root scope here. What I'll do is grab the key value pairs inside the base object here. Let me paste that here for now, and we'll do some multi cursor magic. We want each CSS variable to be named --primary- and the shade number.

1:21 We are in CSS here, not JavaScript. I'll remove the quotes. If I've done things correctly, when I hit save, we should see the entire color spread happening. Look at this. Beautiful. Obviously the three spreads are using the base color only since this is the only color we've defined.

1:37 We now need to figure out how to define our theme scope. The theme scope can be any CSS selector. It can be a class name, but it can also be a data attribute. Let's take a look at the html. If we pay close attention to the html markup we need to style, you will see that we have these data theme attributes here.

1:56 We have one set to base, and then we have one set to rainforest, and finally one set to candy. We can use this data theme attribute as the scope for each of our themes. Let's try that. You need square brackets in CSS to target an attribute.

2:14 Here I'll go data-theme="rainforest" . Once again, I will grab the values from 50 to 900 for that theme. Paste them there and do some multi precursor magic --primary and convert these to valid CSS. Check it out. Now the rainforest color spread is happening, and I will duplicate this to do the candy.

2:40 This time I will try to only grab the hex values and with a bit of luck with multi cursor, I should be able to replace them like so. Nice. Now we have the three color spread. Let's recap because this is important. We are defining at the root scope CSS variable with a default value, which is our base theme.

3:02 Then within theme scope, data theme rainforest and candy, we redefined the values for the same CSS variables. We generate new tailwind color utilities in our config file. If I use text primary, it's going to use that CSS variable for the color, and same for background color.

3:20 By default, everywhere in the site will have the base theme color. Even if there is no data attribute here. If I can remove that, nothing will change. If I was to obtain another theme scope like candy, you can see that now the CSS variables have been redefined within this block of html.

3:37 Whenever we are using bg-primary or text-primary, these values have been changed and you could indefinitely nest this. If I go to the 500 value here, and here adds a data theme equals rainforest. Check this out. Shade 500 is now rainforest.

3:57 You can see that this is super powerful and gives you a lot of flexibility on what parts of your html inherit what values. Let me go back to base here. At this point you might think that the challenge is complete, but there's a little problem.

4:10 Check this out. In our CSS, we've defined the base color for the root scope and then theme scopes for rainforest and candy. We don't have a theme scope for the base theme. Now, I just showed you how I could override the base theme with the candy theme, but let's try the opposite.

4:26 Let's go in the data theme, candy attribute, and inside of there go find the 300 shade this time and try to add a data-theme="base". As you can see, the 300 shade has not moved to another color. There is nothing that sets data theme base as a theme scope.

4:45 Actually, if we want to be able to override a specific theme with the base theme, we also need to create a scope for the base theme. That's really quick and easy because I already have the variables here. Before rainforest, let me duplicate that one, and I will change the name to base and change the values to the base values.

5:07 You can see now that our 300 shade has been overriding the candy theme, so everything is working properly.

Create Themable Color Shades with CSS Variables

0:00 Let's create themeable color shades. We'll use the same color name across all themes. Let's choose a name that is not tied to a specific color or field. We'll call it primary. 

0:10 Here's your first challenge. We have these three-color spreads here, and they're currently using the three colors that we have extended our Tailwind config with. If I look at the HTML, you can see that these colors are using text-base, bg-base, and then rainforest, and later candy.

0:26 Without touching any of the markup below, we're going to use the primary color for all of these three spreads. We want them, without changing the HTML, to start looking like the ones on top. You can see here, if I highlight the word primary, everything is using these primary background and text colors.

0:45 Let me give you a couple of tips to get going and then you're off to your first challenge. The first thing you'll want to do is, in the CSS file, create CSS variables for our primary color shades. You can name these primary-50 to primary-900. I suggest you start with just primary-500, and then repeat the exact same process.

1:03 You'll find these theme values in the Tailwind config file right here, but for convenience, I've put the 500 value for each theme down here. You'll first want to define these CSS variables within the root selector.

1:16 Before anything works, you'll need to go in the Tailwind config file and extend the colors object with a new primary object. You can see it's already there, commented out. If you've done that right, you should see the 500 shades take place here.

1:30 Finally, back in the CSS file, you'll want to redefine the CSS variable within the theme scopes. To figure out what these theme scopes are, you're going to have to look at the HTML. Remember, you can't touch that HTML markup, but looking at it, you will find a clue to what you can use to create your theme scopes.

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

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

0:00 Let's start by converting the hex value to R, G, and B channels. Unless you want to do some base 16 math in your head, you can use an online tool for that or inside VS Code, there is this neat little extension called Hex to RGBA that I could use here. This will transform to a format which is not what we want, but it gets us halfway there.

0:20 Check this out, I'm going to select all of the hex colors and I will convert them to RGBA, all at once. Then, we actually don't want the RGB or RGBA function. All we want is a space separated string of R, G, and B. When I save this, this is going to break our design, because we actually don't have the composed color. We just have the channels for now.

0:43 Step two is to now update in our Tailwind config the way we consume these CSS variables. We only have that part. We want to wrap this in an RGB function and compose with the transparency alpha-value.

0:56 Once again, multi cursor to the rescue. This is a very good skill to have in this workshop. We're going to open the RGB function and let me close it at the end. RGB is going to be that part and we're going to compose that with the alpha-value provided by Tailwind. When I save this, we should have full support for opacity, which is fantastic.

1:18 If I inspect the bg-primary-600 class, you can see that now we are composing this tw-bg-opacity variable. Then, the background color is using this, applying our RGB individual channels within the CSS variable and composing that with the opacity variable, which is the alpha-value that we've used.

Implementing Color Opacity with CSS Variables

0:00 We are creating new themable colors, but it looks like in the process, we've broken support for color opacity. Check this out.

0:06 Here, we've got some default Tailwind colors showing at various degrees of color opacity, and you can see everything look as it should, but below here with the same code using our themable colors, things are obviously not working.

0:19 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.

0:34 Let's hover a default color like bg-teal-600. You'll see that it sets a tw-bg-opacity variable set to 1, which is 100 percent opacity. Then the background color is set to that color, and it composes the opacity here in the alpha modifier.

0:51 That was the 100 percent color here. If you look at the 70 percent color, this is the same bg-teal-600 with opacity of 1, and then the bg-opacity-70 down there, can you guess what it does? All it does is set and redefine the tw-bg-opacity variable to .7 or 70 percent. Now when we apply this bg-teal-600, the opacity will be .7 or 70 percent.

1:17 This is the same mechanism that we've used with our colors, where we would redefine the color variable within the 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.

1:34 If I scroll down to the multi-theme colors that we've implemented, let's see what happen if I hover the primary background color. There is no tw-opacity variable. It just applies the CSS variable as the background color.

1:48 If I go to the 70-percent opacity here, the bg-opacity class here sets the tw-bg-opacity variable to .7, but the bg-primary-600 color doesn't use it at all. It just sets the background color to our CSS variable, so of course, nothing is going to change when this class is applied.

2:07 When we define colors as CSS variables, all we give Tailwind is this variable name, which is a placeholder that can contain any value, and Tailwind is not able to extract these R, G, and B channels, so we're going to have to do this manually.

2:20 In other terms, in our CSS file, instead of defining colors as hex value, we are going to want to convert these to R, G, and B channels. Not the RGB color, just the individual channels.

2:32 Your job in this challenge is to transform all of these hex values into R, G, B channels, literally a string of R, space, G, space, B. Once you've done that, in the config file, you will be able to compose these R, G, B channels with Tailwind's alpha-value, which is the exposed equivalent of these tw-opacity variables Tailwind has internally.

2:55 You'll be able to create an RGB function with the R, G, and B channels and then compose the alpha-values like this in each of these values. Good luck.

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


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

0:00 We'll need the plugin function from Tailwind CSS. The first thing I'll do here is const plugin and require tailwindcss/plugin. Then inside of my plugin's array here I can call this plugin function. This function actually gives me another function, which is where I can grab things such as addBase, addComponents, addUtilities. Here we want to add to the base layer, so I'll choose addBase.

0:25 We'll use that helper function to inject styles to the base layer. We want to target the body. Remember it's CSS in JavaScript syntax, textTransform. The value will be a string of uppercase. We can see our styles have been properly injected. The plugin is working.

0:43 That addBase function here is exactly what we're going to use to inject our theme styles -- our CSS variables that we've defined in the previous lessons.

Improve Your Developer Workflow with Tailwind CSS Plugins

0:00 We've already laid out the foundations of a theming strategy. We can probably improve our developer experience here. We're defining our CSS variable in a CSS file. Then we're generating new color utilities in the Tailwind config file. That would be nice if we could do both things within the same file.

0:16 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. That way is the Tailwind plugin API. Tailwind CSS offers a powerful plugin API that lets you author your CSS with the full power of JavaScript. It also allows you to reuse functionality across projects.

0:37 Here's your challenge for this one. We're going to start creating a plugin. In our config file here, we have this plugins array. You're going to pass here a plugin that will generate the following CSS, target the body tag, and set text transform to uppercase.

0:53 We want this heading tag here and the paragraph to be uppercase as a verification that the plugin is working and injecting the styles like it should. Good luck.

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

0:00 I will grab all the CSS variable declarations here, the root scope, and the theme scopes. In the config file, I could replace the body selector here with all of this -- of course, it's all broken -- and start the conversion to a CSS in JavaScript Object. This is a pretty tedious task.

0:21 One tool that's pretty handy for this is this transform.tools that lets you transform all sorts of things. I can literally paste the CSS that I've copied here. It's going to convert all of this. I don't need the converted variable, but I can grab everything that's inside of it.

0:37 Let me replace that CSS with the CSS in JavaScript syntax. Because we are injecting this CSS in the base layer, we're essentially doing exactly what the CSS file was doing. I can go and delete all of that CSS injected to the base layer. When I save, you can see that everything still works.

0:58 Just to show you I'm not playing tricks on you, if I comment out the add-base declaration here and save, all the colors are gone because the CSS is being injected from our plugin API. What this means is we're not doing any work in our CSS file anymore. All of our work is happening in the Tailwind config file. Eventually, we'll move that into its own plugin file.

Moving CSS Variable Declarations into a Tailwind CSS Plugin

0:00 Now that we have a working plugin, let's move our theming strategy into the plugin. For this challenge, you're going to take the CSS variable declarations in the CSS file here, and move them to the config file inside our plugin.

0:14 You can replace this text transform uppercase Hello World and put the declarations here. Remember you need to use the CSS in JavaScript syntax, so you'll need to do a bit of formatting. Good luck.

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

0:00 We're going to use our multi-cursor skills, once again, here. We'll start with just the root level variables, select all these and go getRgbChannels. We want to reach for the themes object and then the base key. Here, we want to grab the value that is matching the name of the variable.

0:24 Now, I'm going to copy these 10 lines here and the base scope will be exactly the same values. Further down, the rainforest needs to take the rainforest colors. Finally, the last one needs the candy color.

0:39 I will try to save with the base color just to verify that our colors are being set by these. Yeah, you can see the candy now has the base color. When I change this to candy, it's going to take the correct candy color.

0:53 Obviously, 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 allow users to define their own themes object and pass it to the plugin. Then have the plugin read from that theme to generate the correct CSS variables and utility classes.

Convert Hex to RGB with JavaScript

0:00 Our plugin is going to continue growing going forward, so I went ahead and moved it to its own file. Looking at the tailwind.config file, you can see we're requiring this plugin file. At the bottom here, instead of defining the plugin, we pass the plugin that we've imported in this file.

0:15 If we look at the plugin file, there should be something bothering you at this point. We have a themes color in hex values. Then we define our colors as RGB separate channels, but we do it manually. We convert these manually. There is nothing that takes the values from these themes and then passes them there.

0:36 We can probably improve the situation here. First of all, the R, G, and B separate channels is not very common and kind of awkward. That would be much nicer if we could pass the colors as hex values. For example, if someone uses the Tailwind default colors imported from tailwindcss/colors, these would come as hex values.

0:53 Because we are now in JavaScript land, we can use a little JavaScript function that can take a hex value and do the transformation into the R, G, and B channels we want.

1:03 We could do this manually, but here I have provided a little helper function. This is a library by Sindre Sorhus called hex-rgb. I created this getRgbChannels function here that takes a hex value. It's going to grab the red, green and blue channels and return them as a string.

1:20 Your challenge here is to take all of these values here and replace them with this getRgbChannels function and grab them from the themes object instead. Once again, don't worry about code duplication and repetition. We'll sort that out later. For now, let's just focus on making the transformation from hex to RGB.

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

0:00 Here, we're going to use addBase function multiple times, once for each theme. If we look at our theme, we can see that it's an object that has multiple keys, base, rainforest, etc.

0:11 To be able to iterate over them, we're going to keep this root definition as is, but we want to close this addBase function here, and its role is going to just define the root scope variables, and then for our three theme scopes here, let's reopen another addBase just so the syntax is correct and things don't break.

0:31 Now instead of doing these three declarations manually, we're going to iterate over the themes object. Here outside of the addBase -- let me scroll up a bit -- I will go Object.entries and grab our themes. Then we can use a simple forEach loop here, and Object.entries will give us both the key and the values of the object. Essentially, we want to use an addBase function for each theme.

0:56 Here, we will copy the first CSS and JavaScript block and paste that here. Actually, before we continue, let's delete this one, because we want to make sure that we break things to fix them again later. Now everything is using the base color, which is what we're expecting. Let's try change the 500 to candy, and sure enough, that works.

1:17 We have access to the key, which is going to be base, rainforest, or candy, and then the value is going to be the object with the 50 to 900 shades.

1:25 First thing we want to change is here, the name of the theme. We'll want to do this dynamic, so I'll change this to a template string, and here, I can use interpolation to use the key. This is not valid JavaScript syntax. If you want a dynamic key in an object, you need to wrap it in square brackets as well like so.

1:47 Now we're generating the correct data, theme scopes, but we need to update the value to be the correct theme. Essentially, themes.base here can be replaced with the value, which is going to be one of these objects. Cross our fingers and save, and boom, everything is working again.

2:05 Once again, we're one step closer to accepting user-defined themes input. There's still hard-coded stuff in there, but we've just taken one step in the right direction.

Refactoring to Remove Hard-Coded Theme Names in Tailwind Plugin

0:00 I know I've said, "Do not worry about code duplication," but let's just do a little code refactoring before we keep going. We are reading the values of our theme's object here, but we still hard-code the name of the theme's base -- rainforest and candy. In this challenge we're going to keep the root CSS variable definition as is.

0:19 Then for our three theme scopes we're going to iterate over the theme's object. Use a bit of JavaScript to iterate over the three themes. There's a couple of hints in the code comments. Good luck!

We can consolidate our code concerns by moving the responsibility of extending the user's theme to the plugin itself.

Configure Tailwind to Extend Themes via Plugin

0:00 In the Tailwind config, I will cut the whole theme object. It's saved in my clipboard. I will hit save, which will break everything. In the plugin file, if I hover over the plugin function, you can see that it accepts a second argument, which is a config object. Our first argument is this function here that goes all the way to here. 

0:21 If I have a comma, this is where I can pass a config object. Our config is the whole Tailwind config object. I can paste the exact same theme extension that we were doing in the config file. When I hit save, everything will come back to place. With a simple copy-and-paste effort, we've done something significant here.

0:40 Our plugin file is doing all the wiring for our theming strategy. It defines CSS variables and extends the theme object. In our config, all we do is import the plugin and require it in our plugin's array. Everything is contained inside the plugin, which is a huge milestone. Our plugin is not completely dynamic yet, but it's self-contained. We can technically use it on another application right now.

Consolidating Code Concerns into a Tailwind Plugin

0:00 Our plugin is starting to look pretty good. Before we continue making it more dynamic, let's consolidate our code concerns in one place. Right now, we have our plugin file where we define the CSS variables for the root scope and the theme scopes.

0:13 Then inside the Tailwind config file, we extend the theme to create new utilities that consume those CSS variables. 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.

0:30 Your task in this challenge is to find a way to get rid completely of the theme extension here so that all we do in the config file is require the plugin and instead find a way to extend the theme from within the plugin definition.

Our goal is to replace the indigo brand color of a real calendar app with our primary themable color using our plugin.

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

0:00 Let's start by requiring the multiThemePlugin in our tailwind config file. Require('./plugins/multi-theme'), and at the bottom of the tailwind config file here in the plugins array, I can require the multiTheme plugin.

0:14 Here's the running app, and we are going to try to make the background split component here become theme-able. In components background decoration, I will find all instances of indigo like so and replace with primary.

0:29 When I hit save, the app should look very similar, which is a good sign. You might not notice the difference because I've based the base theme color very closely to the indigo color shades. This is really the theme-able colors at work.

0:42 In the parent most element, here I will add a data theme =, and let's go with candy. What we're expecting here when we switch back to the browser is to see a background use the candy color. Yeah, it's working. Obviously the other components are still using indigo, but it looks like our theming strategy is working really nicely.

1:01 For fun, let's try see. There's the left panel here and the right panel. Let's change the theme on the right panel only. Rain Forest. This is probably going to look terrible with pink and green side by side, but as you can see, this is working really well.

1:16 Let's undo all of that. We'll keep the colors to primary, so we should be back to our base theme. Yep. Now let's go in pages and underscore app. Here we will uncomment this theme switcher. If we look at the app, once again, we have this nice little dropdown menu with our different themes.

1:34 Before we use it, let's take a look at what the code inside of here is doing. All right, so we are setting the active theme to the base theme by default. Then we have this use effect that will append to the body elements, the data theme attributes with the active theme.

1:50 Let me open the dev tools here, and on the body tag here, you can see this data theme. Let's try switch it to rainforest. You can see the data theme change to rainforest and candy. We still have only the background split working and changing the themes because that's the only place we have implemented the primary colors.

2:11 Now let's go to town and replace every instance of indigo to our primary color. I'll do a site wide search and search for indigo, and maybe let's add a dash to make sure we only select utilities that use the word indigo. These are all pages or components, so it seems to me like it's safe to replace them.

2:30 I will replace all of these 43 instances with primary-. That sounds scary, but let's give it a shot. Ready? Yes. Boom. Should we take a look at the app? Are you scared? I'm not scared. All right, moment of truth. Let's switch to a rainforest theme.

2:50 You can already see the background color on hover is working, which gives me a lot of confidence that everything is working properly. Check this out. How cool is this? Everything is taking the correct theme and our plugin is working wonderfully.

3:12 Just like I said in the challenge intro, you could go in any components like the time picker, and then on the parent's div of that component, switch the theme to something else. Now no matter what the active theme is, our time picker will always remain candy.

3:30 I don't know about you, but I'm calling this a success. Our plugin is working really well. Let's keep going and make it more dynamic.

Testing The Multi-Theme Plugin by Replacing the Site-Wide Color in a Calendar App

0:00 Our plugin is definitely not finished yet but it already contains all of the theming functionality. I think it's a good time to try it out in a real app to get some gratification on the work we've done. We're going to work with this calendar app right here. You can select some days and see the availability on the right, as you can see.

0:19 When you find a date that you find convenient, you can confirm this and then have a little form. Then, you submit the form and you get a nice confirmation screen. Everything from the background to the calendar days, the selection buttons, the buttons, follows that brand color. This is where we're going to use our theming strategy to swap that brand color.

0:42 Let's take a look at the code base. Currently, everything in this app is using the Indigo color, site wide. This is what we want to try to replace with our primary themable color. If I open the tailwind config file, you'll see that we're already using a couple of plugins.

0:58 Here, in the plugins directory, BGStripes is a fancy CSS variable composition technique, which is what creates this nice animated background stripes pattern. Then, the square diagonal plugin extends the width with a mathematical equation and that width allows us to set the perfect width for this ribbon.

1:18 Finally, inside this plugin directory, we have our multitheme plugin. This is the exact code that we had in the previous lesson where we stopped. We're setting up the CSS variables at the different scopes and then extend the tailwind theme colors. Feel free to poke around the code base and take a look at things, but let me outline the challenge to complete here.

1:37 Your first step is to go in the tailwind config file and here, you're going to require the multitheme plugin and register it in the plugins array down here. By the way, you can find the instructions for this challenge in the readme file here. Once you've registered the plugin, I think it's a good idea to start with one component and try to do the conversion.

1:56 We're going to take this background pattern here, which has the split background aligned with the card split, and we're going to change the color from Indigo to the themeable color here. In components, you will find background decoration.

2:11 Again, it explains to you find all instances of Indigo, replace with a primary color, and try to add a data theme candy attributes and see what happens. If you got that working, take a deep breath and go and find and replace every instance of Indigo to primary on the entire code base.

2:27 That feels kind of scary, but remember our plugin is registered and it should generate the correct CSS variables and tailwind utilities for it to work. Finally, and this is the fun part, you should go in pages and underscore app, and down here, you will see that we have a theme switcher component, which is commented out.

2:45 Check out the code for this component if you're curious. Go ahead and uncomment it here in this underscore app file and check out what happens in the app. One more thing you can try just for fun. Remember, our themes are nestable and you can override a theme within another theme.

2:59 So, maybe try to replace one component with a different theme by adding a data attribute to that component. All right, have some fun and see you in the next one.

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.

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

0:00 To help us write our function, let's console.log the returned output in the terminal. Down here is our function definition, and then inside the addBase here, let's add a console.log that says CSS vars definition, and then consumes that function, so getCssVariableDeclarations, and as the input, we will pass our themes.base. 

0:24 You can see currently, it logs an empty object because this is the default output. That should help us construct the correct output that we're looking for.

0:33 The approach I'm going to use is one of many. This is JavaScript, and you can do all sorts of different approaches. I'm going to use a forEach loop and then do a little bit of recursion inside of it.

0:44 The first thing I want to do is do Object.entries, and instead of grabbing our themes, we're going to grab the inputs, which is passed to this function. Then forEach, again, we're going to have a key and a value here.

0:57 Here, we're essentially at a crossroad where if the value is a string, we want to output a CSS variable for that string, but if it's not, if it's a nested object, we want to recursively call the same function again with a different input.

1:11 If we're here and the value is a string, a hex color, we can create the CSS variable for this, but if we're here and the value is actually a whole object, we need to call the function again. Let's try the if statement, if typeof value is not a string, we're going to call the same function, getCssVariableDeclaration, but this time, the input will be the value, and we'll also pass the output.

1:39 Otherwise, if it is a string, what we can do is take our initially empty output object and add a dynamic key to it, which will be -- for the CSS variable prefix. It's not going to work just yet, but let's pass the key here, and for now, let's set the value of that property to the value, which is a string.

2:00 We've got a start. We've got a series of variable names. They're obviously wrong, and the value is the hex value, but this is a pretty good start. Looking up here, you can see that we want the getRgbChannels output. We can fix that easily, getRgbChannels for that value. Very nice.

2:19 If you look, it goes from 50 to 900 and then jumps straight to color. Remember, if the value is not a string, we are calling the function again recursively. What happens is when we hit secondary, we call the function again, and again, and again, and eventually have this color name. That --color name is just the last part.

2:38 What we want to create is a segment which is a kebab-cased string of all the nested keys one after the other. We want this --color here to be -secondary-some-nested-color.

2:53 To do that, we need to keep track of the current segment or the current key, and so I'm going to add a new argument to the function here. Between the input and the output, we will have a path, which will be by default an empty array.

3:08 Now inside the forEach loop, I can start by updating the path so every time the function is called again, it has a new path, so const newPath = path.concat, and we will pass the key here. What this new path does here is take the path, which at the start is an empty array, and then adds the key inside of this array.

3:30 We'll collect the various nested keys inside this array, and then we'll join the array together to construct our kebab-cased variable name. Now if the type of value is not a string, and we call the function again, we will pass this newPath as the path.

3:46 This function will be called again, but the path here, instead of being an empty array, will be the first key. With that in place, we can replace here just the key, which was the last key in the object, with newPath. Because it's an array, we will .join it, and the delimiter between each element of the array will be a -.

4:07 As I hit save, I think we're going to nail the structure that we want. Three, two, one, boo. Look at this. We have our primary-50 to 900 colors, and then exactly as we wanted, we have secondary-some-nested-color.

4:24 Let me clear that output, and now look at this. I'm going to go in the theme.json file, and to show you that it works, I will add a hello, ffffff, and save this. You can see my primary-hello key added here. If the value wasn't a string but was an object, wow, it, really, works. I broke it, but I need to add a comma here, and now look at this, primary-hello-wow-it-really-works.

4:53 It looks like we've landed on a function that can generate CSS variables on the fly based on the input object shape. I will backpedal on my demonstration here, and we're now going to try to replace that addBase block with a function.

5:10 I'll remove the console.log here, and instead of a terminal output, we'll look at the UI once again. We are going to try to replace that CSS with our getCssVariableDeclarations function. Let's delete all the CSS variables inside of there, just to see that it should break the UI, and also delete these ones here. Now we have no more theme colors. It's pretty obvious.

5:33 Now, instead of this empty object here, I will call the getCssVariableDeclarations. Our input here will be themes.base for now. Check it out. It's successfully creating the CSS variable colors once again. Down here, instead of the empty object, we will call getCssVariableDeclarations one more time. This time, the input will be the value, and boom, everything is back into place. How cool is that?

6:05 One quick note here. We're still making the assumption that the first theme called base, which is not a given at all. Instead, here, I will use Object.values from our themes object, and then simply grab the first instance, which is, in our case, the base theme. Basically, the first theme that the user passes in the themes object will be used to generate the global CSS variables, and it still works.

6:31 Our plugin is becoming truly super powerful now. The next thing we need to do is dynamically generate the CSS utility classes generated by Tailwind.

Dynamically Generate Colors From Nested Theme Objects

0:00 We're going to make our plugin seriously dynamic now and even support nested color themes object. In preparation for that, I've done a tiny change to the plugin. Let me show you that real quick.

0:10 Here's our plugin file on the left, and instead of defining the themes directly in it, we are now importing a themes.json file. We can see that file on the right, and it's slightly more complex than before.

0:20 We still have our base, rainforest, and candy themes, but as you can see, there's nested properties like primary, and then secondary, and even inside secondary, we have some, nested, color. The idea is we're going to write some codes that can support this nested structure. Let me show you the changes I've made to the plugin real quick.

0:38 Because we now have inside the base a nested primary key for our 50 to 900 colors, I have added here in the addBase declaration, themes.base.primary. It used to be just themes.base '50' , but now we added this nested primary key. I've done the same here for the themes scopes. I've added value.primary. Everything else is exactly the same as it used to be.

1:02 If I scroll back up here, your job for this challenge is to write a helper function that takes the theme object as an input and then outputs the correct CSS-in-JS object. I've created this getCssVariableDeclarations function here that takes an input and an output. Essentially, what we're expecting is the return output looks something like this primary-50 getRgbChannels with the color that matches.

1:29 Then for nested values like this color here, we have this kebab-cased variable name, second-some-nested-color, and it represents the correct color.

1:41 If you manage to create this function correctly, you can then use it here and replace these hard-coded variables. You would replace this entire object for the root scope with this getCssVariableDeclarations function call.

1:57 This is obviously JavaScript knowledge rather than Tailwind-specific knowledge, but this is what will really help make the plugin reusable. If you can't figure it out, that's not the end of the world. Try for a bit and then skip ahead, watch the solution, and we can continue to the next step.

With help from a JavaScript function, we can create an object that replaces the hard-coded color shades in our multi-theme plugin.

Dynamically Define Theme Colors In Your Tailwind Config

0:01 Our code will have similarities to what we've done in the previous step, but it's also a little bit different. Here is the function we've created before, and underneath, we're going to work on the getColorUtilitiesWithCssVariableReferences here.

0:15 Just like earlier, we'll want to keep tab of a path which starts as an empty array. We don't need an output object here. We're not going to populate an object. Instead, we're going to return the object that we construct.

0:27 Once again, we go with Object.entries and grab our input, but instead of forEach, this time we will map over it and grab the key and value. Inside of there, we'll construct our newPath, path.concat key. If the typeof value is not a string, we're going to want to call that function once again, where the input will be the value and the path will be the newPath.

0:56 Up to this point, you can see the code is quite similar, but now it's going to change. We're using .map, and we actually don't want to return an array. We want to return an object. We can use object from entries to wrap around our code to achieve that.

1:10 Up here, I will wrap the Object.entries inside an Object.fromEntries like so. We need to return this. Object.fromEntries expects an array with two things, so instead of just calling the function here, we're going to return an array which is a key value pair where the key is the current key, and the value is that function call.

1:37 Since we're returning the array, we don't need an L statement, because the code is going to stop execute here if the condition is met. In case that it is a string, what we want to return is an array where the key is the current key and the value, we want to achieve this syntax here, rgb with the CSS variable color composed with the alpha-value.

2:02 I will copy this and up here use back ticks and paste that here, and instead of the hard-coded CSS variable, this is where our newPath is going to come handy. We have kept track of where we are in the tree and we're going to output this with newPath. Remember it's an array, so .join with a - separator.

2:26 That was a lot. Let's actually try to console.log the result once again. Inside the addBase function here, I will console.log getColor, blah, blah, blah, lots of letters, and the input will be themes.base. Let's save that and let's make this a little bigger. What do we have?

2:48 We have this primary object, and then the keys with the correct syntax, and then this nested hierarchy, which seems to be exactly what we want. Moment of truth, let's try and replace the hard-coded theme extension with our new function that should generate the correct utility class sets.

3:07 Let's start by deleting the entire colors object extension. Here, instead of the object, we're going to getColorUtilitiesWithCssVariableReferences. We only need to generate the first theme, so let's go themes.base and hit save. That's looking promising. Let's scroll down, primary-900, and look at this. Secondary-some-nested-color. It's working beautifully.

3:36 If I go into base theme from the JSON file, and here create even more nesting -- omg, yes, it, works -- and paste that up here, look at this. We are matching the CSS variables generated, and then the utility class names, and these two paths work together to create this theming strategy that now is super dynamic.

4:03 You can see the three colors are the same. The reason is this variable only exists in the first theme. One thing that is important with this approach is you need to take the first theme, which is base, and this is like the blueprint that should be matched by other themes, because otherwise, it's going to generate CSS variables based on the first theme that don't exist in the second one.

4:27 If I was to copy the secondary part of the base theme, and here in rainforest replace that and change the color to black, you can see that now it's updated properly.

4:39 I'll backpedal on the changes here, and just like we did before, we're here assuming that themes.base exists, and we should not do this. Instead, let's do Object.values and grab the themes, and then grab the first instance.

4:57 All right, take a deep breath. Maybe take a break. This was a big one. We have one more step to go.

Write a Function That Replaces Hard-Coded Theme Colors

0:00 Here's a pretty fancy bit of UI here that pulls from the Tailwind config file and outputs a color swatch for each theme-able color generated with the CSS variable. You are going to have to create a get-color utilities with CSS variable references function.

0:17 What you want to be able to do is output an object that will replace this hard-coded object. This is quite similar to the approach before. The code is a bit different, obviously, but the reasoning is the same. Good luck. Once again, if it's a little bit over your head, don't worry, struggle for a bit, and then come watch the solution.

We’ll figure out how to pass options to a plugin so that users can provide their own themes to our plugin. 

The .withOptions method enables configuration options within our plugins, providing a more flexible experience for developers.


Enable and Validate Plugin Configuration Options

0:00 All right, let's do this. I'm going to explode my page by removing the themes import, and instead in the config file, this is where I'm going to import the themes, const themes = require, and we'll grab the themes.json file.

0:18 Here where I register the plugin, I can actually call it as a function and pass an options object where we will have colorThemes -- let's call it that -- which is themes.

0:29 This is still not working, obviously, but now, we're going to modify our plugin to accept options and read from that color themes option that we've just passed. Let's get rid of that comment here, and we'll pass our helper functions into the plugin definition down here.

0:46 The plugin function also has the plugin.withOptions API. If you look at the signature, it's fairly similar, except both arguments accept a function which gives you the options inside of it. The first part and the second part of our plugin functions need to be wrapped in another function where you receive the options.

1:07 I'm going to move all the first argument inside there and return it, and we move the comma down one level. Then the second argument, which is our config object, also needs to be wrapped in a function that receives the options. I will move the config object and return it.

1:28 You can see themes is still not defined, because we're receiving the options but we're actually not doing anything with this. Before we can use the themes here, we want to try and grab it from the options. Remember, we have named our option colorThemes. Let's try this.

1:47 Const colorThemes = options. We're hoping that this colorThemes object gives us what we want so we can replace themes in two places. You can see it's still complaining about themes not defined.

2:01 This is because here, we are in the first function wrapper, but there's another one down here where we need to do the same thing, const colorThemes = options, and replace the reference to themes to colorThemes. Boom. It's working again.

2:19 We're not done yet though, because we're passing the colorThemes option, but here, we can assume that this is going to exist in two places. If it was accidentally called colorTheme, everything will explode, or if no options was passed, the same.

2:35 We could do a check like if we don't have colorThemes, throw new error and here paste a message like the multi-theme plugin expects a colorThemes option passed to it. You also need to check that there is at least one themes object, because here, we're referencing the first object. We will need to add this to the check and then do it a second time down here.

2:58 I think what we can do -- let me remove that -- is create another little helper function here, check for valid color themes input. I'll paste some code here and explain what it does.

3:11 We have a checkForValidColorThemesInput function, and it checks that the type of input is an object. It also checks that there is at least one object inside which is of type object. Essentially, it checks that we have a colorThemes object with at least one object inside of it.

3:31 If it's not valid, it's going to throw this error saying that it expects a colorThemes option passed to it, which must contain at least one theme object.

3:40 Now we can go where we grab our colorThemes option, and checkForValidColorThemesInput, and pass our colorThemes object, which is going to make it throw the error here. I will paste that same line down here after we do the second check.

3:57 That gives us a much more robust approach now. You can see that we have this meaningful message, because we're currently not passing a colorThemes object. If I fix it to colorThemes, it will now work, but let's pass an empty object, which means that it doesn't have a nested object inside of it. Again, we're going to have the same problem.

4:22 With all that, our plugin is slowly but surely reaching its final form. Let's recap everything we've done.

4:28 We've defined helper functions to get R, G, B channels to generate CSS variables, generate utility classes, and validate the correct input from the theme object.

4:39 Then in our plugin, we use plugin.withOptions, which lets us grab the colorThemes options passed to the plugin. We check that it's valid, and if it is, we can add the root scope CSS variable and the themes scope CSS variables.

4:55 Once we've done that, we also grab the colorThemes option from the second argument and we check that it's valid. If it is, we extend the Tailwind config theme object with our getColorUtilitiesWithCssVariableReferences, where we grab the first object in the theme options.

5:16 This is really nice because anyone can use this plugin and register the plugin in their config file, pass their own themes object, and this will take care of generating all the CSS variables and the custom utility classes for everything to work.

Determine How to Pass Options to a Plugin

0:00 There's one last thing that is hard-coded in our plugin. It's the way we're passing the themes to the plugin. I'm in the plugin file. We're currently importing the themes inside this plugin. Then we're doing our magic dynamic stuff with it.

0:13 If you think about it, as a user, you'd want to use that plugin and pass your own themes object. That's exactly what we're going to do now. We're going to move the themes outside of the plugin. Then in the Tailwind config file where we call the plugin, we're going to pass the themes object as an option.

0:29 Your challenge here is to get rid of this import. That's obviously going to break everything. Instead, you want to pass the themes to the plugin here, where you register it. Have a look at the Tailwind CSS docs for a way to pass options to a plugin. Good luck.

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.

Next Steps for Theming Tailwind CSS Apps

0:00 You've completed the multi-theme strategy module. Congratulations. We're only just scratching the surface of what you can do with the Tailwind plugin API, or even with the theming strategy. What would you do next with this plugin?

0:11 Here's some food for thoughts. Right now, we're only changing theme colors. Perhaps, you could implement theming tokens for border-radius, shadows, font families. The approach for that would be very similar to what we have done.

0:23 You'd create CSS variables that holds the values you'd need for each theme. You do that at the root scope, and then the theme scope. Then you'd extend the Tailwind config theme object with utilities that consume those variables.

0:36 You can use your new superpower of combining CSS variables with the Tailwind plugin API to achieve just about any theming customizations you can think of.

0:46 I hope you enjoyed this module. Thank you so much for your support. I will see you around the Internet or, hopefully, maybe in real life one day. Have a great day.

Professional Tailwind Workshops

Multi-Style Tailwind Components

Tailwind Multi-Theme Strategy