Exercise 3: The Dynamically-Constructed Class Name Gotcha — Possible Solution ==================================================================== THE GOTCHA, WITH A CONCRETE EXAMPLE ------------------------------ Per this chapter's own warn-box, "a class used only via a dynamically-constructed string — for example, `text-${color}-500` in a JavaScript template literal — is a genuinely real, well-documented gotcha." Concretely: suppose a React component has a color prop, and a developer writes something like:

Status

The intent is that if color is "red", the rendered className becomes "text-red-500"; if color is "green", it becomes "text-green-500," and so on — dynamically selecting the correct Tailwind utility class based on a runtime value. This looks reasonable, but per this chapter's own warn-box, it silently fails to work in production. WHY TAILWIND'S TEXT-BASED SCANNING MECHANISM CAUSES THIS FAILURE ------------------------------ Per this chapter, "content scanning is a plain text match, not real JavaScript evaluation, Tailwind can't 'see' a class name assembled at runtime; it only ever sees the literal template-literal source text, never the actual interpolated string." Tailwind's content scanner doesn't run or evaluate any JavaScript code at all — it simply reads the raw SOURCE TEXT of the file itself, looking for strings that look like real Tailwind class names. When it scans the file containing `text-${color}-500`, that's exactly what it literally sees in the source — the raw, uninterpolated string "text-${color}-500" — which does NOT match any real Tailwind class name pattern (Tailwind has no class literally named "text-${color}-500"). Tailwind never sees the actual runtime-computed strings "text-red-500" or "text-green-500" at all, because those strings only come into existence once the JavaScript code actually RUNS — long after Tailwind's own build-time scanning has already finished. As a result, Tailwind never generates CSS rules for text-red-500 or text-green-500 at all, and those classes simply don't work once the application is actually running, even though the developer's own intent was entirely reasonable. THE FIX ------------------------------ Per this chapter, "the fix is writing out the full class name literally somewhere scannable, or using a safelist." Rather than constructing the class name dynamically, the full, literal class names need to appear as actual text somewhere Tailwind's scanner will read them — for example, writing out a lookup object mapping each possible color to its own full, literal class name (e.g. { red: 'text-red-500', green: 'text-green-500' }), so the complete, real class name strings genuinely exist in the source text for Tailwind's scanner to find, even though the application still selects between them dynamically at runtime. WHY THIS WORKS AS AN ANSWER ------------------------------ It constructs a concrete, realistic example of the gotcha, explains precisely why Tailwind's own plain-text scanning mechanism (no JavaScript evaluation) can never see the actual runtime-interpolated string, and states the correct fix per the chapter's own guidance.