faeron
commented
5 years ago Sounds like #228. Maybe you can also get ideas from there.
Open murr4y opened 5 years ago
faeron
commented
5 years ago Sounds like #228. Maybe you can also get ideas from there.
So I’m thinking about using Tailwind to build an internal component library. A few thoughts and questions around this, maybe y’all have some ideas and opinions.
Tailwind as a dev dependency vs compiled css So there have already been discussions here about this. This would apply if you have built components with Vue for example.
You could a) require Tailwind install for your users. They would have to install it just like you in your library and additionally would have to use your tailwind config (eg a team/company one).
Optionally they could use their own config with own colors etc. b) compile the css with a prefix. That way you ensure the style as intended and it’s even usable for users that don’t use Tailwind. The output would basically be a purged tailwind css file including only the utilities you used plus own components.
I guess you could even offer two versions. One for Tailwind users and one for users without.
If you’re already using Tailwind then it makes sense to not compile the css beforehand, that’s just duplicated css.
If you’re not using Tailwind already you could get a compiled version. But then again, you could also just install Tailwind as dependency. Don’t really know the best way to do this.
Sharing css components for repeated code Let’s you’ve got some repeating patterns of classes and you extract them into css components. How would you go about sharing them across projects?
One option would be create plugins right? So instead of applying the classes in your css you would write them into the config, make them installable via npm. (Although plugins are mostly used for things where custom css is required, not as collections of Tailwind classes it seems?)
Alternatively you could put them into component css files and share those between projects.
Sharing css components for non-repeated code So this is maybe a rare case but then again a very common case if you’re building a design system.
If you look at all the design systems that have emerged (basically every big company has one) you’ll always have a mix of people using plain html and teams using frameworks like Vue.js.
The best way to abstract components -like Adam notes again in his new video- is to create js components.
But what is when somebody using another framework (or no framework) wants to benefit from your css?
They could of course copy paste your html including the Tailwind utility classes and install Tailwind as well.
If they don’t it’s a bit trickier. If you look at big design systems they use BEM classes for example. That has all the downsides compared to utility only of course. But since it forces you abstract components early, it’s easier to share markup and css because it’s all hidden behind classes. You copy the HTML, you get a compiled css for the component or a min.css for all components and you’re good to go (internally it’s compiled Tailwind but that doesn’t matter anymore).
But then if you would do that you kinda disregard half of the Tailwind benefits right? That is if you give everything a custom class.
Anyway, those are just a few thoughts I’ve been having and maybe I’m overcomplicating things and everyone should just install Tailwind and be happy ;)
Would be interested in your opinions tough!