As these class names will be dynamically generated in the template, we need to explicitly include all of them in our Tailwind config file ‘safelist’, or else they will not be included in the build: https://tailwindcss.com/docs/content-configuration#safelisting-classes

This approach, of returning via a turbo stream template, gives us more flexibility to apply changes to multple distinct elements within the page. In our case, we want to re render the pollen, UV and temperature predictions, but we’ll also want to re render the  alert guidance component in the next commit.

This will be triggered by the turbo stream in the previous commit, and will be rendered when there is an air quality alert.

I have also removed the bold tags from the guidance text as they are not part of the designs.

The rules that govern which styles should apply are quite complex, so I have ended up with a slightly verbose implementation that hopefully is at least fairly clear.

The order in which the classes are listed is also important - the ‘inactive’ class needs to be below ‘active’ in order to override it.

There are two versions of each of the DAQI alert classes. This is unfortunate but allows us to simplify the Javascript code that toggles the selected classes.

We will use this in our air pollution tabs when there is an alert.

This component will allow us to store the logic required to calculate the styling required, which vary according to each DAQI level.

Add background colour class util to air pollution prediction

We will use this to generate the colour used in the forecast tabs.

We now need to toggle an inactive class as well as an active class, because of the interaction of the active class with the daqi-level classes. In cases of alerts, we want to override the active class with the relevant daqi-level class, but where that tab is not active, we want to override that again with our inactive styling.

The integration tests in CI were complaining about overlapping elements on a button because of he icon on the new air pollution tab. It doesn’t matter that it overlaps, so I’ve introduced this alternative syntax to fix the issue.

If today has an alert, we always want to display the alert stylings. For tomorrow and the day after tomorrow, if they have alerts, we only want to display the alert stylings when the tab is selected.

I have opted for a slightly verbose Javascript implementation that extends the Stimulus code that was already in place, rather than bringing the tabs into the Turbo stream that is already in place for this action. However, if any part of this design becomes any more complex, this would probably be a good candidate to refactor along those lines.

We need to update our integration tests to allow us to explicitly set DAQI values, so that we can check that the correct class for that value has been set on the active tab where there is an alert.