Closed styxlab closed 3 years ago
Hey @styxlab , I have thought briefly about it, but ditched the idea because it felt to me that it's not quite a CSS-in-JS approach.
However, looking at Tailwind
's popularity, probably it will make sense to try it out, and see if it fills the gaps I'm looking for.
It would also help better understand its tradeoffs and use-cases.
I agree, it's a different approach. However, you are also writing Tailwind classes directly into JS, so it's basically TailwindCSS-in-JS. Glad that you'll have a look at it, because it is an alternative to the other packages you compared. Thanks for your consideration, you can close the issue.
I'll leave it open, cause I have another open issue about adding another library.
@styxlab has you used TW with TS? I'm banging my head around trying to use it, and can't figure out how.
What I don't know how to do is for example:
tailwind.config.js
, for instance: red, green, blue
red, green
Union
of those values, with a single source of truth (no matter what the source of truth is)?Here are the methods I've tried:
.ts
file (which I can import and use anywhere else) with a static Object
, or Enum
as the whole set of colors, and use that to spread the values in tailwind.config.js
-> doesn't work, as I cannot import/require .ts
files inside that config file, and the config must be .js
tailwind.config.js
. I've found https://typed.tw/ but it looks to introduce a whole new syntax, and not sure if they provide typings (at a first glance they provide an API for accessing the style options from JS)Also, wherever you search for tailwind, react, typescript
you find only the setup and a silly hello fucking world
example, so no luck with that.
The official docs also have zero
information about TS.
Hey @andreipfeiffer!
Yes, I am using tailwind in pure typescript projects, but it seems that I do not use it in the same way as you are trying to. First off, I don't convert tailwind.config.js
into a .ts
file (I leave it as is) and I also don't try to make types from the tailwind descriptors nor do I pass tailwind variables around as props.
For me, tailwind just provides a couple of descriptors that are basic strings
which I pass to the className
attribute. So, I rely on the eslint-plugin-tailwind
package for getting the descriptors right and not on a typed system. I may pass around className
or className
fragments which are again simple strings.
What you are trying to do is definitively a huge effort and I would not do that without being backed by the tailwindcss team. The Prisma team did something similar for their database interface, which might serve as an inspiration if you really want to get into that. Please ping me on twitter, if you want to discuss further.
@styxlab I've tried DM-ing you on TW, but your DMs are closed.
With static types it's easy, but let me see of I understand how you deal with dynamic styles:
const padding = `p-${some_boolean_prop ? '2' : '4'}`; // dynamic styles based on logic
const color = `text-${color_prop}`; // dynamic styles based on props
return <p className={`text-large ${color} ${padding}`}></p>
If this is the case, then you basically don't get any type-safety in regards to styling, so TS has zero
impact for styling, as far as I can tell.
eslint-plugin-tailwind
Can you please elaborate what does the ESLint plugin do?
Do you have any insights on how they manage this?
I don't use all variants you show, mostly because partial substitution inhibits purging but I do use dynamic selection of TW classes. I agree that TS has no impact here, except for trivially checking that you pass a string to className
.
eslint-plugin-tailwind
Currently the plugin only checks for correct ordering but not for for correct classes. However, I also use a vscode plugin with tailwindcss intellisense, so correct classes are shown while typing and can be easily selected.
I use it preferably, but I do combine it with regular css stylesheets or regular inline styles where needed. Type of applications range from admin panel to front-end UI, with varying degree of customization.
Prisma came to my mind as they are solving similar problems.
While there is no official TS support at the moment, TS support is on its way:
Got it, not I kinda get how purging works. I'll also check out the Prisma video.
I saw there is a PR on Definitely Typed, I was curious if it's only for built-in styles, or you could also provide your own typings for customisations. But I'll wait and see after it's merged.
Review available here: https://github.com/andreipfeiffer/css-in-js/blob/main/README.md#tailwind Would probably revisit this when the TS PR will be merged.
Thanks a lot for your preliminary review. Just one comment with respect to purging, you write:
we have to be aware of purging to not get missing design tokens in production builds
This is not accurate. Purging is for eliminating unused design tokens in an effort to reduce bundle size. You can opt-out of purging altogether, if you want to.
As far as I understand (but please correct me if I'm wrong):
config
file only contains the required tokens, right?text-${color}
, which I don't know how you could enforce and prevent), purging will remove those styles from the production bundle, so you might end up with missing styles in production, but they would work in development.The whole point of purging is to give you a rich set of tokens during development, and eliminate the unused later to reduce bundle size.
Completely agree with you.
However, one of our initial goals was to look for a solution that's (type) safe and have a somewhat low(ish) learning curve (which is debatable, of course).
Using all the other CSS-in-JS solutions, it was pretty easy to figure out what you have to do to get the work done (took me about 2 hours on average to figure out how a library fully works). Using TW, it took me (until now) more than 5 times the effort to understand how it works, and I still haven't fully figured it out, so it's definitely not something that's solid.
It might be easy to pick up, in regard to "choosing class names" and attaching them on HTML elements. But there is so much more tooling needed on top of it, at least considering our development workflow, or expectations.
No worries. I am not affiliated with Tailwind, just a happy user. Totally agree that it currently does not fit well to your selection criteria.
Anyway, thank you for all this thread @styxlab as it forced me to look into TW and better understand its weak & strong points.
Not strictly CSS but I would love to see it compared with the rest. Have you considered including it?