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.