|
|
|
|
|
|
by rcarr
909 days ago
|
|
|
If I remember right, the design philosophy around why Tailwind encourages you to write all the different classes out individually each time is that it wants you to reuse components rather than CSS classes because as the codebase scales and gets more complex you now know that any changes are only going to affect that component and not that component + whatever dev decided to use that custom class you made somewhere else. The other issue it solves is loads of devs making custom classes that are almost identical and cluttering up the codebase. If you're working on personal projects and know you're only ever going to need to change those three things about buttons then this is probably a great thing to use but be aware that if you're creating a commercial project and may have lots of people working on it, this is probably not the way to to go. I will see if I can find the exact part of the tailscale docs where they go into this and update this comment with the link later. Edit:
The core concepts section is worth a read in it's entirety but I believe this is the relative part: https://tailwindcss.com/docs/reusing-styles#avoiding-prematu... |
|
|
But, this component needs a little more padding here and not there. We need flexbox - which parts? Some. Some here, some there, but not all of it…yet. What about grids? Sure, maybe, how? Media queries spread all over the place wrapping things arbitrarily. Oh! And scoped styles every which way for that component-specific flair!
Our component class declarations are about to get a lot more verbose, and I’m all for it. I’d much rather see that, and know what the visual structure should be, instead of tracing a class back through mountains of tacked-on SCSS to add a child class that gets applied in one place that makes a thing have zero margin.