In this workshop, you'll learn the best way to create & manage multiple Tailwind-powered style variants for your UI components.

Tailwind CSS's Just-in-Time engine does not support dynamic class names. This leads to overly complicated conditionals and nested ternary statements that are hard to keep track of - and even harder to add new variants to 😭 

Throughout this workshop, you will build and practice a repeatable process for identifying, refactoring, and implementing dynamic Tailwind CSS style sets.

## Topics we will cover

This workshop is separated into three sections: working with buttons, modals, and refactoring the calendar demo app from the Multi-Theme Strategy Workshop. These sections build on one another, exploring different angles for defining and maintaining your component style variants.

* Creating dynamic size, shape, and color variants for increased flexibility
* Customizing the Tailwind IntelliSense Plugin for VS Code to enhance your development workflow
* Implementing an async-ready accessible Modal with configurable animated transitions
* Refactoring complex conditional logic into discrete states

## By the end of this workshop, you will:

- have the ability to extend your UI components to support multiple style variants using Tailwind CSS.

- be comfortable defining and executing a repeatable process to refactor complex component styles into a cleaner, more maintainable code structure.

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.