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.