Even the best design system needs local overrides to satisfy a product owner's incomprehensible requests, like "can we push that button a few pixels to the left?".
Even the best design system needs local overrides to satisfy a product owner's incomprehensible requests, like "can we push that button a few pixels to the left?".
In a design system. You specify variants of a component. Each one has its own combination of style defined by the design system.
You do not set „Gap“ to 2. you would specify smth like „small“, „medium“ or „large“ as props.
This is not a tailwind issue.
How would you handle a design change where a size becomes required that fits between "small" and "medium"? These things happen throughout the lifetime of a project.
Opaque numerical design tokens may not be the most explicit to understand, but they allow for expansion.
Are you unfamiliar with having-a-boss?
On the places where things work, bosses act like the GP's one. Granted, that doesn't happen on the large majority of places.
Note however that this API is brought by Styled System [1], which Chakra uses (and exposes), and adds the component library and other niceties on top.
My only regret with Chakra is that it's a tad runtime-heavy, and it's not really adapted to static content. I'd love to see some sort of compiler that digests a React tree into rendered HTML + CSS, with minimal JS just for style interactions (is this what Svelte does?)