Challenge 3: Fixing a Direct-Class-Name CSS Modules Mistake — Possible Solution ==================================================================== WHY THE STYLES WON'T APPLY ------------------------------ Per this chapter's own warn-box, when Button.module.css is imported as a CSS Module, its .button class gets automatically rewritten at build time into something like Button_button__x7f3a — a real, generated class name, NOT the plain text "button" that was actually written in the source CSS file. Writing
puts the literal, original, unmodified string "button" directly into the rendered HTML's class attribute. But the CSS that actually gets loaded on the page only defines styles for the RENAMED class (Button_button__x7f3a) — there is no rule anywhere in the final output targeting a class literally named "button". Since the rendered element's class attribute and the CSS's own actual selector don't match at all, none of the intended styling applies, with no error or warning of any kind. THE CORRECTED CODE ------------------------------ import styles from './Button.module.css'; // ...
Here, styles.button reads the ACTUAL generated class name back out of the object CSS Modules produces at build time (per this chapter's own example, styles.button resolves to the real string "Button_button__x7f3a"). Using {styles.button} instead of the literal string "button" ensures the class name actually applied to the element matches exactly what the build-time-renamed CSS selector targets. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains precisely why the mismatch occurs (the rendered class name and the CSS's own real selector are different strings), and supplies the exact corrected syntax (reading the mapped name from the imported styles object) rather than just stating that "you need to use styles.button" without explaining the underlying reason.