Yes! (https://marketplace.visualstudio.com/items?itemName=bradlc.v...)
Although I wouldn't mind an array instead so I can use the typescript typechecker.
theme: {
button: {
primary: {
color: 'blue',
padding: '2px',
},
},
<Button {...css(theme.button.primary)}>
vs. tailwind classes:
<Button className="text-blue p-2">
Having IDE autocompletion (or even TypeScript integration) would be really nice. I'm sure there's plugins for many IDEs or editors that can do that, though.
Use withStyles [1] and vscode autocompletes without needing a plugin.
I currently have a tailwind project that's around twelve months old. I'd like to add a dark theme.
Normally - in a CSS, SCSS, PostCSS project - this would consist of adding a media query overriding a handful of color variables.
Using tailwind (which has 'inbuilt dark mode support') I have a few thousand colors spread around the project and I have to modify them all. Additionally by having a giant palette of named colors, we have, for example, multiple occurrences of our active color as `blue-400` and `blue-500` and `blue-600` rather than a single `var(--active-color)`.
We’ve been doing this in CSS for quite some time using variables. This didn’t require adding a fairly leaky and thin abstraction on top of CSS and adding thousands of copy pasted singleton styles to our projects.
And CSS variables are great but way more verbose and still require you to come up with "semantic" names for everything.
This is confusing component reuse with design system reuse.
Two components may have completely different purposes, but they both have a certain rounding, palette, and other styles.
However Tailwind tells users they shouldn't be doing this, encouraging them to paste the same mixins on every element they want them.
Everyone stopped using unstructured cryptic class="bg-gray-100" for good reason. Tailwind is backwards progress.
Clearly, not "everyone" stopped doing that.
Tailwind being popular doesn't really contradict their point.
The point is undoing single element styling would never would have been necessary if tailwind didn’t encourage styling single elements (saying that “best practices aren’t”) in the first place.
The author literally even mentions we should use “symantic descriptive names”. You know, like those best practices that tailwind says don’t work.
Tailwind is easy to start but hard to maintain and extend.
Its good for a prototype or small landing page.
I would never use it for long term project where you need to maintain and extend your features a lot.
You don't.
Thus not much more difficult to read and remember than css key value pairs.
Why would you typecheck component class names? If so, its all strings, seems pretty easy less error prone than inline styles.
<Button className="bg-gray-100 rounded-full flex" ...
How do you remember the names of all your classes? Should your IDE know about these classes? Can you autocomplete class names? Where's the import statement for these classes so you know where they're defined and what they do. There's a better way:
Use site-wide themes (Objects with keys like colors.heading.primary having value '#000') and withStyles[1] and React.PureComponent[2]. Having your React component render the same result given the same props and state makes things so much easier to work with. Also, the compiler knows about your theme so your IDE helps auto-complete and makes sure the style you're using is actually defined.
[1] https://github.com/airbnb/react-with-styles
[2] https://reactjs.org/docs/react-api.html#reactpurecomponent