DON'T Make This Tailwind Mistake! (easy fix)
HTML-код
- Опубликовано: 12 июн 2024
- This Tailwind issue has gotten me several times!
*Newsletter*
Newsletter 🗞 - www.jamesqquick.com/newsletter
*DISCORD*
Join the Learn Build Teach Discord Server 💬 - / discord
Follow me on Twitter 🐦 - / jamesqquick
Check out the Podcast - compressed.fm/
Courses - jamesqquick.com/courses
*QUESTIONS ABOUT MY SETUP*
Check out my Uses page for my VS Code setup, what recording equipment I use, etc. www.jamesqquick.com/uses
1:51 small correction. Not specificity, but cascade. The C in CSS. Styles with same specificity get applied in order they are defined in the source file, not order defined in markup.
Regarding this approach mentioned in the video, I'm usually against allowing className to be passed into a component from a component library because then things quickly deviate from design system, but sometimes you just need that one off padding/margin or some layout (flex/block change) and it's silly to add a prop just for that because you'll end up with 10 props for these specific cases in the end. So this solution is great in the end.
Btw beware if extending or using a custom Tailwind theme. You'll have to customize tw-merge because it doesn't know how to merge your custom theme definitions. By default it handles default Tailwind styles, but cannot know how your custom styles should be merged.
Great catch, these are CSS fundamentals that are usually overlooked by many and reaching out to CSS frameworks does not solve ignorance a bit.
Ah good correction on cascade! Yeah using className like that isn't always the right way to go but can be helpful in some situations.
it's kind of insane that we need something like this for to work correctly. it's almost as if we use Tailwind incorrectly, not the way they intended it and hence why this problem even occurs. It was interesting to learn about this.
In fairness, Tailwind just gives CSS so regular CSS rules apply based on ordering. Not sure this is something Tailwind would be responsible for solving. It's just a quirk to be aware of.
Loved it! Super helpful, as I've been struggling with this exact issue.
Yayy! Glad this helped!!
Great info! Thank you
Glad you enjoyed it!
how does this compare to the cn() and cva() functions that come with Shadcn?
They are built on twMerge
Oh good to know. I didn't know that but totally makes sense!
Funny thing is I never encounter this behaviour with tailwind, purely because of how I write the utility classes. Basically I write them in an order of how I would write a vanilla CSS. Even before people started realising this behaviour with tailwind. This proves that newbies to CSS must start writing vanilla before reaching out to frameworks like tailwind.
I wish I knew this earlier. I had issues like this in Next.js, just didn't know why. So I had to find my own work around
Thanks James,
Damn! Why didn’t I know about this before. Thanks for this amazing video ❤
Really had this exact problem recently ,now got the solution
Yeahhh it's so common. I hit it a lot actually. NEVER AGAIN lol
Or, you can set default values to that prop. This is the perfect example of how you can use style props, instead of class props. You could have a padding prop with a default value in this case.
very well explained. I always wondered why everyone installed this.
I wrote vanilla CSS for over a decade and I never encountered this when trying out tailwind for the first time, mainly because it is second nature for me to write the utility classes in an order how I would write vanilla CSS. That's why tailwind is never been for beginners as most people thought. A dev that have no idea about CSS cascasde fundamentals would fall into the issue showed in this video. Tailwind enables faster prototyping but only if you knew css already.
Awesome! Thanks!
Glad you enjoyed it! Have you experienced that issue before?
@@JamesQQuick I heard about it from colleagues, but haven't encountered it myself
I have videos like that. Basically you said that we should use the library for the stuff that doesn't work outside of a box. That's totally not a perfect solution.
What would you suggest doing instead?
So, i really enjoy using visual code becuase it made me a better programmer but can you create large software projects with c++ with visual code
Just a small question, but should twmerge not be installed as a dev package?
So shadcn's cn function does exactly that under the hood?
I think it actually uses tw merge behind the scenese
Anyone know if this adds to the file size on build? I heard gossip it does, but could just be people hating on Tailwind.
In their docs they have a section on "when not to use" that covers this. In short, yes it will add some to bundle size. I don't think it's much to be overly concerned about, but they do call it out. github.com/dcastil/tailwind-merge/blob/v2.2.1/docs/when-and-how-to-use-it.md
@@JamesQQuick thanks for the link! I assumed it was true, but an overblown critique.
Twmerge and clsx is great combined
Yes, tailwind is everyone’s fav way to implement css to components. That is why it is the de facto library for nEXtjs.
But real talk, nobody uses tailwind without classnames or cva and tailwind merge. Also, you don’t need a default className value. It’ll just return an empty string. Classes are already bloated as is.
Nest everything inside of the cn() function too, including the className prop. It’ll make you look like you have a clean headspace. Lol
I use tailwind without those things. The issue mentioned in the video could have also been solved without using tw merge. The way I would do it would be to add default values to the classname prop instead of on the component itself. So instead of having the px-4 and text-blue-50 on the component, you would only apply those styles whenever the classname prop was undefined. Every class that is directly on the component would be considered mandatory.
I can definitely see the benefit of using something like tw merge, but it is absolutely not necessary.
@@Voidstroyer But without tw merge, that can still lead to css cascade issues. I forget the name of the extension, but if you're going to go about it like that there's a very useful extension that will format the classnames in the order in which they are defined in the tailwind root file. That way you can at least be able to infer what will be overridden.
@@treyrader I believe that you are talking about the headwind extension. I already use that. It correctly orders the tailwind classes upon saving the file. I am unsure if there is a tw merge package for other programming languages since I use Elixir Phoenix. The css cascade issues could be solved by simply understanding how css works. Of course, we don't have control in which order the tailwind css classes are defined, and that's why I would take a different approach. Instead of having px-4 by default on the component and then trying to override it with px-10 by passing it in as a variable. You would first check if the variable has been defined. If it is, then you just use the value of the variable. If it isn't, then you add px-4. This way you prevent having both px-4 and px-10 on the component at the same time and then having to rely on the css gods. My approach definitely has more to think about, but it is a solution that works in every programming language.
@@Voidstroyer yea that's it! The merge and clsx packages are often used in tandem. It'll ensure you have no css overrides
👍‼
Ffs stop recommending tw-merge without mentioning its BIG performance impact. Why you all are treating it like theres no performance cost? Its not like its minimal, it WILL actually be noticible in medium to large apps depending on the amount of elements with it and the amount of "overrides".
A WAY, WAY better aproach is to just make a component with variant props like size, color, variant, type, etc. depending on its use cases and project's design system. That way you duplicate the same styles way less often, if there are changes in the design system, you could easily adapt the components, since all the necessary changes would be done in one place, no 20 or 30. And you still have the flexibility to make one-off changes via className: just pass in the classes with exclamation point, which would mark them with !important.
In my experience working on a realy huge project with tailwind we had to override styles with classNames for custom components like 3-5 times. Other times we just use variants.
class:list ... thank me later 🤘
Why don't you guys just learn CSS? it's not that hard.
Hmm so your take is that anyone that uses tailwind must not know css?
You cannot really use Tailwind without knowing CSS and nothing is stopping you from using Tailwind and regular CSS together. No need to go to either extreme.
But to be honest I've been writing CSS for last 7-8 years and I'm just tired of writing it basically from scratch all the time and re-inventing the wheel. I work in an agency and never work on just a single project constantly. Tailwind is a nice theme generator really. I also don't want to invent my own framework for no reason, which I definitely have to do if I don't want to lose my sanity so I just skip that and use other people's work instead.
I've been using vanilla CSS for 20 years and I love Tailwind, what's the problem with that? Give it a try
Why don’t you learn tailwind? It’s not that hard.
For real, though, tailwind is only worth it if you actually know CSS. Tailwind’s goal is to make it quicker and easier to apply styles with utility classes. If you have to know what CSS you need in order to apply the right tailwind classes. If you don’t know the CSS you can’t know what classes to apply. Implying that people use tailwind because they don’t know CSS shows that you don’t know enough about Tailwind and its use cases to understand it.
This is it!@@rand0mtv660