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.