Advice Generator App with React, TypeScript, TailwindCSS
Design comparison
Solution retrospective
My TailwindCSS classes seem to be bloating my components' markdown. My first instinct is to create a @layer components { ... } in a stylesheet, but I believe it might start getting crowded.
What is the best way to approach long class names with TailwindCSS & React?
Community feedback
- Account deleted
I don't think long class names are a problem. For people who are used to Tailwind it's quite easy even with 4 lines full of classes to understand generally what's going on. What I recommend is to use the tailwindcss plugin for prettier. This plugin will make sure all your css classes are organized in a consistent way. This makes it even easier for people writing with Tailwind to get used to it.
Link to the plugin: https://tailwindcss.com/blog/automatic-class-sorting-with-prettier
Also "bloating" your components with CSS and specifically with Tailwind classes means that you don't have to deal with other files. All the stuff you need for your component are in one file. It's kind of convenient if you look at it this way. In a much bigger project with many components dealing with css files can be really mentally draining.
1@LuzefiruPosted over 1 year ago@arkatsy I see, that makes sense.
What are your thoughts on using utility class arbitrary values like
py-[24px]
instead of the built-in classes?In some designs I tend to reach for arbitrary values a lot and then extract them into a separate stylesheet anyway and use the full customizability of CSS, but this ends up creating the unnecessary separation of concerns like you stated with multiple CSS files.
However, so far, I'm leaning towards reaching out to Tailwind first for any cookie-cutter designs and rely on the base utility classes, but then reach for CSS Modules for anything that requires more customized styling.
1Account deleted@Luzefiru I'm sure you'll hear countless opinions as it is with anything CSS related topic, but here is what I think of this.
Tailwind gives you (very naively put) 3 things
-
A specific way to write your CSS styles inside html/jsx with classes.
-
A predefined design system that provides some good sensible defaults.
-
And a way to modify or creating a design system that suits your needs.
The predefined tailwind design system is just another design system. For sure It's a well thought one and if you follow it you are guaranteed to have designs that look very nice and clean. But it's still a design system with it's own set of defaults and values. So of course you might want to change them and put what fits yours better. That's the good thing about Tailwind. It's not forcing you neither locks you down to a specific way of styling.
Now whether getting away from the default styles means putting arbitrary values all over the place or creating another design in the tailwind config that fit your needs, that's on you to decide. Of course the bigger the project, the better the latter will serve you. But also this doesn't mean that you should avoid arbitrary values. Sometimes arbitrary values are necessary to achieve perfection in details, you know like some icons or text that needs to be adjusted a couple of pixels left or right.
Now about what you said about extracting classes to another css file. As you said if you overdo it you will end up with the same issue where to change something you have to look for it somewhere else.
I think that repeating styles is not as bad as people tend to think with Tailwind. Especially if it's structured repetition it might be ok most of the times. For example if you have 3 classes that repeat themselves 4 times it's okay to keep the repetition. Don't overthink it too much. Repetition will serve you better than abstraction.
The only thing I think it's nice to separate to somewhere else is the animations. Not simple animations like hover effect and simple transitions but actually complex animations that require a lot of thinking and probably are not going to be changed any time soon. And even if they do they are going to be worked from scratch most likely.
Every time you separate and abstract styles always it's good to remember that you couple things together. If it serves you go for it. If it doesn't because it's prone to change again soon or something then keep it like that. And of course keep in mind the readability for someone reading the code for the first time. In this point of time with my experience I think that more abstraction can lead to less readability. But other people might disagree with this and they should, there isn't a standard practice or opinion that is good or bad, it always depends.
Note: I just read what I wrote and I think I missed what you said at the end with using CSS modules. I see what you are saying but also Tailwind is just CSS at the end of the day. If something is complex or you are not used on the tailwind way of doing it then just write vanilla CSS, tailwind won't complain.
CSS modules are still good of course. It's a solution to a problem where the problem is having name collisions and style overrides because you put everything in the global scope. It's a good solution especially for a bigger project that wants to go the old CSS route. In my opinion this is much better than using a name convention like BEM to solve the same issue. Actually to put it correctly the issue is not the naming convention but rather the fact that you are still putting things in the global scope and soon or later if the project gets bigger you might have to deal with issues. But again someone might disagree and say if you follow some rules and be careful you won't deal with any issue. And to be fair that's true. The use of CSS modules and naming conventions is a choice also.
To come back to Tailwind of course there isn't this issue to begin with. So you have that as also a positive.
Also something I forgot, Tailwind adds vendor prefixes automatically that way you don't need to care about browser compatibility most of the time except if you have some specific requirements. So if you go the vanilla CSS route you need to make sure to take care of that.
I wrote this in a hurry so excuse me if something doesn't make sense or it's a little messy, I hope you found something useful on what I wrote.
Marked as helpful1@LuzefiruPosted over 1 year ago@arkatsy Amazing explanation. Really loved the part where you said:
"Repetition will serve you better than abstraction."
But yeah, my biggest reflection from this was that Tailwind offers guardrails and vendor prefixes to enable consistency and compatibility from the get-go.
The only time I'll ever reach from abstracting from now on are complex, reusable designs (like page layout) & animations. These are the only things I feel like merit their own stylesheets.
Thanks for the advice!
1 -
Please log in to post a comment
Log in with GitHubJoin our Discord community
Join thousands of Frontend Mentor community members taking the challenges, sharing resources, helping each other, and chatting about all things front-end!
Join our Discord