4 ms·
> CSS modules still seem to solve every problem Tailwind solves, and better. I don't understand Tailwind either; but I find myself struggling with CSS modules
by azangru 5y ago
> CSS modules still seem to solve every problem Tailwind solves, and better.
I don't understand Tailwind either; but I find myself struggling with CSS modules when I need to override a CSS rule of a child from a parent. Like, say, my button should always be green, except in this context I want it to be purple, its font-size larger and its padding a bit different. With CSS modules, the parent component is unaware of the class name of the child component; so it cannot target that. Perhaps this should all be done with CSS variables; but then hell, how many CSS variables should my components expose? and besides, I am not even sure even they will completely solve this.
- mixedCase 5y ago.button is the default .button-context is the context version className={isContext ? ".button--context" : ".button"} ---- alternatively if you want many unrelated base rules that aren't color/padding as a baseline: .button contains base rules .button--default default color/padding .button--context contextful color/padding className={`.button ${isContext ? ".button--context" : ".button--default"}`}
- azangru 5y agoYeah, sounds sensible. What I've been doing so far was attempting to extend the base class like so: import classNames from 'classnames'; ... className = classNames(styles.buttton, props.className); But this leaves me at the mercy of the order in which webpack builds stylesheets (sometimes props.className will be defined after styles.button and my plan would work; other times it will get defined before styles.button, and styles.button will override the CSS rules of props.className). Really wanted the extension of the base rules to work out; but I guess you are right: the className from the props should override entirely one of the classNames of the component.
- docmars 5y agoUse Twin Macro for Tailwind-in-JS — you won't regret it!