Add tw-merge to manage overrided classes correctly #793
Replies: 2 comments
-
After playing with tw-merge, it is only compatible with runtime detection, so this is not what we want. Here is another idea: The tailwind config file of polaris could have two outputs:
The Polaris app would then have 2 stylesheets, the last one imported would always have the priority. So, imagine our Spark button has a default class for padding
Would probably result in
MAIN PRO: Only uses natural browser behaviour to work. In the meantime, they should continue to override this way:
|
Beta Was this translation helpful? Give feedback.
-
Another option would be to use standard CSS by creating a small, dedicated CSS module file next to the component one want to override the styles for, e.g.: /* styles.module.css */
.override:is([data-spark-component]) { /* specificity === 0,2,0 which is higher than the TW utilities classes */
background-color: theme(colors.secondary);
} Then, inside the component: import { Button } from '@spark-ui/button'
import styles from './styles.module.css'
export function SomeComponent() {
return (
<>
...
<Button className={styles.override}>some button</Button>
</>
)
} |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Issue is when developers wants to override styles of Spark component using tailwind classNames instead of props (for some edge cases)
If a spark component name
<Foo />
has a default classNamebg-primary
, and the developer tries to override it like this:The component will then have both classes:
bg-primary bg-secondary
.And the one that is defined last in the stylesheet generated by tailwind would be applied. So it's possible the override does not work.
Until we find a better way to do it, they must use the
important
TW modifier:Beta Was this translation helpful? Give feedback.
All reactions