My Professional React & Next.js course is OUT NOW now! Find it here: bytegrad.com/courses/professional-react-nextjs -- this is the #1 resource to master the latest React & Next.js, my absolute best work.
As i am new to react and nextjs, but started right with typescript, tailwind, shadcn... It all is quite overwhelming. I didn't understand why they use cn() in the components and how to make components reusable. Thanks for the compact explanaitions. You are my todays hero ❤
Reusability is the reason components were created. If it's quite overwhelming, well you did a bad choice. You should first get basic understanding of something before moving onto a next thing. If you'd know CSS then tailwind is really easy.
Ok, in one of my projects, the infrastructure code base has such utils that I am confused at first glance that I asked GPT, this video dives deep and clearly. THX.
It's obviously useful trick, but i think it has several disadvantages. 1. You need to additionally configure tailwind-merge, if your tailwind config file is different from the standard one. 2. We don't know anything about tw-merge perfomance. 3. It makes developers less vigilant when writing replacement classes.
1:50 In Tailwind CSS, if you have conflicting classes, the class that comes later in your class list will take precedence. This is because Tailwind CSS uses the "Cascading" part of CSS, meaning that if you have two conflicting styles, the one that is declared later is the one that will be applied. For instance, if you have a text-red-500 text-green-500 class on an element, the text will be green, because text-green-500 comes after text-red-500. This rule applies as long as the classes have the same specificity. If there are classes with different specificity, the class with higher specificity will win, regardless of its order. However, most Tailwind classes have the same specificity, so the order is what generally matters.
This is almost right. What decides the class that will be applied is the order in which they appear on the *stylesheet*, not on the class list. For most cases, the way that tailwind builds the stylesheet follows the class list order, but if you apply a class that has already been declared somewhere else this will mess up the order.
I believe the original poster is still correct. Specificity would trump order. It doesn’t matter if .class comes after #id and a similar thing would happen with some of the classes that have higher specificity. Not sure which these actually are in tw, but it sounds correct especially for ad hoc classes.
Yes, this is correct. It’s intuitive to think the order in classlist matters, but it doesn’t, it’s about the generated stylesheet. Tailwind actually seems to sort them alphabetically
@@rickvian At least the current version of Tailwind has classes sorted alphabetically. So if your className is "text-red-500 text-green-500" you will get red text and if your className is "text-green-500 text-red-500" you will also get red text.
I really learn new things just by using Shadcn/ui. It's honestly way too amazing. If more people gets to know it it's gonna become the bootstrap of React/tailwind (which might be bad in a sense lol)
I've found this video very helpful and straight to the point. People in the comments wanted visual example, but I actually find it redundant. Your explanation was clear enough. Regarding the topic, I faced this issue myself. Ended up making whole diff components for every btn type I want. Its not that bad as it sounds I guess, it almost acts like storybook in terms of being able to see all forms of your software's buttons. But with your video I need to revisit it
This was one of my first negative impressions when I started my first project in ReactJS after previously working in VueJS. It seems crazy to me to have to use additional packages for something as simple as overwriting CSS classes in a component. I think this is one of the reasons why the VueJS template system shines
I agree with you, but I would like to notice it's not necessarily the framework Because the point here is class binding conflict, which is irrelevant of the framework Example : In vue, angular, react I can put a base bg-red-500 to a HTML element, then bind conditionally bg-blue-500 / bg-yellow-500 to it If the base bg-red-500 is not handled correctly, there WILL have conflict. So the solution here would not to use a lib because we are too lazy to handle our css, but just to architecture and handle your classes better, avoiding css conflicts Unfortunately, the common way in React is to use every lib available because it's "easier" or "simpler"
Not fair. Specificity problems occur with any styling approach, be it "pure CSS", CSS modules, BEM, etc. Tailwind-Merge is very good at solving it. And you don't need CLSX - it's just a fancy optional wrapper.
@@CharlesNiko-j3p An example: tailwind -> 1. create component for your button, think on a good semantic name for describing it 2. content is: 3. use and that's done, versus simple css approach -> 1. create component for your button, think on a good semantic name for describing it 2. think on a good name for the css file, should it be embedded? Should it be on the same directory as the button, follow the same naming conventions? Will you use scoped modules? If not, will the name you chose clash with other components in your site? 3. think on a good name for the component css class, what should it be, the same name as the component itself? Will this be composable or one time usage? Why I need to put the same exact name both in the button and then in the class in a separate css file that needs a name as well that probably is also the name of my button? Well, I put it 4. css content is: .my-button { background-color: #22c55e; width: 100%; height: 50%; &:hover { background-color: #86efac; } } 5. component content is: 6. use it -------------- I don't dislike entirely the simple css approach, but to say tailwind don't have a raison d'être is absurd. It has a point, it makes sense. It is not the panacea, absolutely not, it has it pains, but I don't know exactly why people are arguing for this like this is a sanguinary battle between the knights of good versus the evil witches.
I love your tutorial style, always love how everything is so well explained. Not a huge fan of Tailwind CSS personally but I do use it for singular projects. It's always good to know how something so popular is being used professionally. Great work, love all your tutorials. Glad I recently found your channel.
@@nadeemshareef451 There's no "perpose" set in stone for Tailwind. Devs made @apply possible so people can use it. You even can make a hybrid with bunch of global basic classes and modify those classes with utility classes. It may be effective strategy too.
@@nadeemshareef451No tailwind is more than just utility classes, the main reason that I use is convention. Use @apply is not just cleaner, is more performatic than every other alternative
@@andreilucasgoncalves1416@apply can be removed from TW in the future. It's super slow (at compilation) and super complex. Creator of TW regards @apply one of his biggest design mistakes. You better reconsider your approach.
Amazing demonstration and to the point. You have given me the perfect solution that I have been looking for, for a while :D, which is the coniditonal classes. Thank you!
Just use "class-variance authority", If that is too much for you, then you could use this: import { twMerge } from 'tailwind-merge' export const twix = (...classes: string[]) => (className?: string | string[]) => twMerge(classes, className)
Don't know. What is the point of having a `CustomButton` and allowing arbitrary changes to hit via className? Defeats the entire purpose of a UI component.
This is useful, but I take the approach of not having conflicts, forcing ourselves to design the components in such a way that we don't get conflicts provides a healthy maintability
Hi, sorry for buzzing, but I'd like to ask you one more question about this if you don't mind, please NextJS 13 doesn't support libs that apply CSS during runtime as styled-components does. One approach I found people using is adding className literals to JS object keys, then referencing it in the element className. However, this approach lacks support for tailwind sorting prettier plugin and vscode tailwind intellisense plugin, as we're no longer writing directly in the className prop. We need some extra configs that looks pretty hackish to me. (I.e creating a dumb function that accepts and returns the classname and adding this function to prettier config file) Do you have any experience with situations like this where we assign className to variables/objects? Or do you always write components passing className as a string/cn()? Also, have you ever heard about class-variance-authority (cva) lib? May it be a good replacement for clsx+twMerge in your opinion? Thank you in advance
Thank you for this great and straight to the point video. You know tailwind-merge has twJoin function. Do you think it can serve the same purpose as cn function?
I have difficulty in understanding why should I use another library instead of just doing the pending classes like this: twMerge("bg-gray-500", className, pending ? "bg-green-500" : ""); It works really well and you don't import any more libraries other than twMerge.
Yep, it’s a good point and the author of Tailwind-Merge also agrees. But if you have a lot of base classes and then a lot of conditional classes it looks better to use object syntax for the conditional classes (which is not possible with Tailwind-Merge alone, so you need clsx for that). So clsx is just there for syntactical reasons
@@ByteGrad With more classes and more conditions I would personally just separate all the style logic into a component and move the above ?: operator so that it loads variables, and then just pass those. I personally think that adding that library creates more confusion that solves problems, because if I don't know what it does suddenly I have to check and learn it just to discover that it could be easily replaced with ?: operator.
The problem is that patterns repeat through years. This approach tw uses is not scalable. It good to quickly drop and forget some html page. But it’s not good for teams nor medium projects. Bem is a good structure for css, module css is a scalable as well. Use proper tool for fitting tasks
u r explanation is great but when u explain tailwind or per say frontend in general . u must show the result & the learning curve is fast when we see thing. ok thanks
Hi, very helpful video. Just a suggestion, next time when you upload new video, pls don't chose video for kid category, because I cannot save it to my playlists. Thanks!
clsx is a good match for Tailwind, but I'm not sure about twMerge. I prefer to have some strict rules in place to control which classes or styles we can pass to a component, especially when working on a project with a design system and typescript For example, only classes like 'bg-danger' or 'bg-success' should be allowed to be passed to a button component For projects that prioritize freedom in styling, using twMerge can provide us with a better development experience
I don't think this is fair to say that every Tailwind user needs this or even has access to it. Some of us use Tailwind with twig or blade or other templating engines that don't run in a Node or JS environment. These libraries are specifically for JS projects that use Tailwind. For the rest of us, just add the ! to the prop class.
@@Tresla How is that inflexible? You should be designing your website using two or three colours at max so setting variants with primary/secondary would be fine. Unless you design your website using the colours of the rainbow
@Tresla yes, however, your component shouldn't be changing throughout your website. What's the point of creating the Button component in the first place then if you want to change it throughout the whole site?
@@genie_dev bruh have you ever built a website? There are always those little edge cases when a client ask you to do something weird. Better have it ready + it its not that hard to implement lol
What's your opinion about reusing styles? I read in the docs about utility-first concept that it's recommended we handle css and HTML as a singular resource, so if your CSS changes, your HTML should be different as well I.e. instead of creating a Button component that receives a className as prop, we would use N button elements with it's own styles variation. I heard it's counter intuitive, but it's helpful. Still, I find it so weird and wrong that I don't know if I should follow this pattern. Maybe I misunderstood something. Would you mind sharing your thoughts?
You can go either way I think. I like to be able to style the components very specifically and so prefer to be able to just pass Tailwind classes, not some variant
@@ByteGrad thank you. I like the idea of having a component with some base styles that can be overwritten by props. But as the docs discourages it I was afraid of facing issues in the future. But I'll go that way. Thanks again for taking your time
My Professional React & Next.js course is OUT NOW now! Find it here: bytegrad.com/courses/professional-react-nextjs -- this is the #1 resource to master the latest React & Next.js, my absolute best work.
import { twMerge } from "tailwind-merge";
import { clsx, ClassValue } from "clsx";
export function cn(...inputs: ClassValue[]) {
return twMerge(clsx(inputs));
}
As i am new to react and nextjs, but started right with typescript, tailwind, shadcn... It all is quite overwhelming. I didn't understand why they use cn() in the components and how to make components reusable. Thanks for the compact explanaitions. You are my todays hero ❤
Glad it was helpful
Reusability is the reason components were created. If it's quite overwhelming, well you did a bad choice. You should first get basic understanding of something before moving onto a next thing. If you'd know CSS then tailwind is really easy.
Amazing. RUclips recommended your video just when I saw Shadcn uses cn clsx twMerge
Ok, in one of my projects, the infrastructure code base has such utils that I am confused at first glance that I asked GPT, this video dives deep and clearly. THX.
Really good video. The progression through the details is perfect. The example you use is concise and to the point. Great teaching.
I'm literally binge watching your videos at night. It is 2:55 AM here and They really are like a movie 🤩🤩
It's obviously useful trick, but i think it has several disadvantages.
1. You need to additionally configure tailwind-merge, if your tailwind config file is different from the standard one.
2. We don't know anything about tw-merge perfomance.
3. It makes developers less vigilant when writing replacement classes.
Lol the performance argument. Is it still 2017?
1:50 In Tailwind CSS, if you have conflicting classes, the class that comes later in your class list will take precedence. This is because Tailwind CSS uses the "Cascading" part of CSS, meaning that if you have two conflicting styles, the one that is declared later is the one that will be applied.
For instance, if you have a text-red-500 text-green-500 class on an element, the text will be green, because text-green-500 comes after text-red-500.
This rule applies as long as the classes have the same specificity. If there are classes with different specificity, the class with higher specificity will win, regardless of its order. However, most Tailwind classes have the same specificity, so the order is what generally matters.
This is almost right. What decides the class that will be applied is the order in which they appear on the *stylesheet*, not on the class list. For most cases, the way that tailwind builds the stylesheet follows the class list order, but if you apply a class that has already been declared somewhere else this will mess up the order.
I believe the original poster is still correct. Specificity would trump order. It doesn’t matter if .class comes after #id and a similar thing would happen with some of the classes that have higher specificity. Not sure which these actually are in tw, but it sounds correct especially for ad hoc classes.
Yes, this is correct. It’s intuitive to think the order in classlist matters, but it doesn’t, it’s about the generated stylesheet. Tailwind actually seems to sort them alphabetically
@@brunopanizzi yes i meant appear in the stylesheet
@@rickvian At least the current version of Tailwind has classes sorted alphabetically. So if your className is "text-red-500 text-green-500" you will get red text and if your className is "text-green-500 text-red-500" you will also get red text.
zoned out, ended up staying just to listen to the voice. Very soothing.
honestly audio is pretty bad
exactly lmao@@HoNow222
I did wonder what this was all about. Thanks for the explanation.
thank you! this really cleared up how I am supposed to pass around options to components!
Great video. You covered all that had to be clarified and there's none unneseccary information. I'm glad yt suggested me Your channel.
Glad it was helpful!
I really learn new things just by using Shadcn/ui. It's honestly way too amazing. If more people gets to know it it's gonna become the bootstrap of React/tailwind (which might be bad in a sense lol)
I will definetely use it in my next project, its awesome! Also really beautiful
I've found this video very helpful and straight to the point.
People in the comments wanted visual example, but I actually find it redundant. Your explanation was clear enough.
Regarding the topic, I faced this issue myself. Ended up making whole diff components for every btn type I want. Its not that bad as it sounds I guess, it almost acts like storybook in terms of being able to see all forms of your software's buttons. But with your video I need to revisit it
Thanks 😊
Super helpful. Thanks. looking forward to check out your Next 13 tutorial.
Amazing tutorial! Do you have one on cva() for variants?
Thanks for this great video, just implemented into my side hustle. going to be very helpful
Well done! Looking forward for next video!
Thank you, more to come
This was one of my first negative impressions when I started my first project in ReactJS after previously working in VueJS. It seems crazy to me to have to use additional packages for something as simple as overwriting CSS classes in a component. I think this is one of the reasons why the VueJS template system shines
I agree with you, but I would like to notice it's not necessarily the framework
Because the point here is class binding conflict, which is irrelevant of the framework
Example :
In vue, angular, react I can put a base bg-red-500 to a HTML element,
then bind conditionally bg-blue-500 / bg-yellow-500 to it
If the base bg-red-500 is not handled correctly, there WILL have conflict.
So the solution here would not to use a lib because we are too lazy to handle our css, but just to architecture and handle your classes better, avoiding css conflicts
Unfortunately, the common way in React is to use every lib available because it's "easier" or "simpler"
I could be wrong, but I think this is how Post CSS works. The merge tool is simply removing the duplicate in a predictable way.
You can just use a template string with conditionals inside braces if you really want to, it works fine.
This is how you create a problem then build a fix for, I do believe using just css will be better
Not fair. Specificity problems occur with any styling approach, be it "pure CSS", CSS modules, BEM, etc. Tailwind-Merge is very good at solving it. And you don't need CLSX - it's just a fancy optional wrapper.
@@IvanKleshnin Not fair. Give examples of how can this be better compared to the simple css approach.
@@CharlesNiko-j3p
An example:
tailwind ->
1. create component for your button, think on a good semantic name for describing it
2. content is:
3. use
and that's done, versus
simple css approach ->
1. create component for your button, think on a good semantic name for describing it
2. think on a good name for the css file, should it be embedded? Should it be on the same directory as the button, follow the same naming conventions? Will you use scoped modules? If not, will the name you chose clash with other components in your site?
3. think on a good name for the component css class, what should it be, the same name as the component itself? Will this be composable or one time usage? Why I need to put the same exact name both in the button and then in the class in a separate css file that needs a name as well that probably is also the name of my button? Well, I put it
4. css content is:
.my-button {
background-color: #22c55e;
width: 100%;
height: 50%;
&:hover {
background-color: #86efac;
}
}
5. component content is:
6. use it
--------------
I don't dislike entirely the simple css approach, but to say tailwind don't have a raison d'être is absurd. It has a point, it makes sense. It is not the panacea, absolutely not, it has it pains, but I don't know exactly why people are arguing for this like this is a sanguinary battle between the knights of good versus the evil witches.
under rated channel. i love the algorithm
Thanks, appreciate it
I am using tailwind-variants package, which is an optimized version of cva for tailwind and does this automatically.
Interesting, will check it out
Yes, its an amazing library, and also easy to understand. I personally use it in my personal project.
Are you able to use the shadcn/ui library with tailwind-variants instead of cva?
@@aliventurous yes. It does exactly the same and more.
@@oemeraran8183 Would you mind sharing how you've set up your project? I'm curious how you've modified shad's default utils.ts
Front End is becoming such a hellish freaking mess
I love your tutorial style, always love how everything is so well explained. Not a huge fan of Tailwind CSS personally but I do use it for singular projects. It's always good to know how something so popular is being used professionally. Great work, love all your tutorials. Glad I recently found your channel.
Appreciate it, thanks
Brutal, made my morning! Thanks!!!
Glad you enjoyed it!
This is why I prefer to write my tw styles in a separate css file with @apply. It’s cleaner and solves the conflict issue
The reason for using tailwind, is not having to go outside HTML files. This goes against that.
@@nadeemshareef451 There's no "perpose" set in stone for Tailwind. Devs made @apply possible so people can use it.
You even can make a hybrid with bunch of global basic classes and modify those classes with utility classes.
It may be effective strategy too.
@@nadeemshareef451No tailwind is more than just utility classes, the main reason that I use is convention. Use @apply is not just cleaner, is more performatic than every other alternative
@@andreilucasgoncalves1416@apply can be removed from TW in the future. It's super slow (at compilation) and super complex. Creator of TW regards @apply one of his biggest design mistakes. You better reconsider your approach.
@@IvanKleshnin I am not even using TW in my projects nowdays, I am using sass and creating CSS files for simplicity
Amazing demonstration and to the point. You have given me the perfect solution that I have been looking for, for a while :D, which is the coniditonal classes. Thank you!
Glad it helped!
Cool, now I know the origins of this shadcn helper function
Exactly
Amazing explanation 🫡
Great video thanks man keep posting like this content
Unrelated to the topic of the video - "use strict" doesn't do anything inside module. Code evaluated in modules always runs in strict mode.
I started using this cn pattern a few months ago after a RUclips video by Mewtru
well explained! tnks!
Would be nice to see that video on completely reusable button component
Superb loved it..
Thank you man!
Thanks It was really helpful
Thanks, Amazing work
Just use "class-variance authority", If that is too much for you, then you could use this:
import { twMerge } from 'tailwind-merge'
export const twix =
(...classes: string[]) =>
(className?: string | string[]) =>
twMerge(classes, className)
Can you please give the link for your reusable button component video
"classnames": "^2.3.2", its good package usage like this
import cs from "classnames";
class=${cs(
" tw-inline-flex tw-items-center tw-justify-center tw-border tw-border-solid tw-border-default-600 tw-rounded-full tw-gap-2",
{
"tw-py-0.5": value?.length > 0,
"tw-text-default-600": !fill,
"tw-bg-default-600": fill
}
)}
Yep, similar to clsx. But it doesn’t do merging like twMerge
@@ByteGradwhat do you mean by it? How is it different?
Great video, so can you tell me what is your extension in your vscode, plz
Don't know. What is the point of having a `CustomButton` and allowing arbitrary changes to hit via className? Defeats the entire purpose of a UI component.
Thanks for the video. I had used shadcn but use to not understand how it's implemented.
Please make a video on how to create reusable button/component
Great. Will do! 😊
As far as I know tw megre implemented clsx funcionality so you shouldn’t need clsx anymore with tw merge.😊
twMerge doesn’t support object syntax for conditional classes, but clsx does. That’s why they’re still used together
Is it a bad practice to just use classNames library?
How would you handle dynamic values like this: `w-[${size}px] h-[${size}px]`?
Afaik twMerge does not cover this.
This should work in twMerge
I only recommend using tailwind-merge if absolutely necessary, as it introduces quite a large bundle to your project
Is there an alternate way to achieve such behaviour?
What about performance? I don’t know how they merge functions, but it’s probably some loops. And of that logic going to run on every render
That is probably the reason why twMerge does not use clsx by default
@@andreilucasgoncalves1416 i wathced code of tw merge, its actualy very impressive. It has in memory cahce and caches merge results
How does "tailwind-merge" differ from "classNames"?
This kind of stuff in the real job world would be ridiculous.
Been using Tailwind for about a week now. I can see the benefits but not sure i'll adopt it long term. It's just not as flexible as just using css.
why dont we just use a ternary operator, and depending on weather we have a prop on the button component we choose what color to use?
Great content ✅✅!!
Can i use this in react native apps ? How ?
how do we set different theme to each multiple (dynamic) pages ex: category pages, or maybe random themes for each blogpost?
New conecpt I learned.
superb explanation... can't find your reusable button tutorial ...will be glad if you share the link
Very nice explanation
Thanks 😊
Theme for vscode?
Hmm this way when i do not pass in a classname they wont be undefined ?
thanks so much!
Awesome :)
it's criminal how unknown this is!
Would this work in Blazor?
I have a small question, why we call it cn ?
Will Tailwind tree-shake the output of cn()?
thanks it was helpful
in my understanding, the "cn()" function is an implementation created by shadcn?
hi whats the difference of just using the twJoin function than combining both libraries?
This is useful, but I take the approach of not having conflicts, forcing ourselves to design the components in such a way that we don't get conflicts provides a healthy maintability
It's completely fine to have these kind of conflicts. It's not a bad design per se. This is just a way of allowing overrides
Hi, sorry for buzzing, but I'd like to ask you one more question about this if you don't mind, please
NextJS 13 doesn't support libs that apply CSS during runtime as styled-components does. One approach I found people using is adding className literals to JS object keys, then referencing it in the element className. However, this approach lacks support for tailwind sorting prettier plugin and vscode tailwind intellisense plugin, as we're no longer writing directly in the className prop. We need some extra configs that looks pretty hackish to me. (I.e creating a dumb function that accepts and returns the classname and adding this function to prettier config file)
Do you have any experience with situations like this where we assign className to variables/objects? Or do you always write components passing className as a string/cn()?
Also, have you ever heard about class-variance-authority (cva) lib? May it be a good replacement for clsx+twMerge in your opinion?
Thank you in advance
where do I add 'prefix' of tailwiind cofig 🤔
You don't currently have your own Tailwind CSS course. Will there be one in the future?
Yes, working on it 😉
Thank you for this great and straight to the point video. You know tailwind-merge has twJoin function. Do you think it can serve the same purpose as cn function?
Thanks a lot
What is your vscode Theme name?
More tailwind user than tailwind coder :)
Is the „classNames“ lib not also taking care of both problems?
Yeah that one is similar to clsx. They don’t do intelligent merging when classes conflict, you need Tailwind-Merge for that
Wouldn't a ternary operator or "or" operator be able to solve this anyway?
That would be the same as &&. It works but syntax-wise a lot of people prefer object
tailwind-variants? anyone?
It does merging automatically
cool vid :)) but anyone know the issue about tailwind intellisense using cva (clsx+twMerge)? now I'm struggle with it :(
thanks!
Concize and helpful
I have difficulty in understanding why should I use another library instead of just doing the pending classes like this:
twMerge("bg-gray-500", className, pending ? "bg-green-500" : "");
It works really well and you don't import any more libraries other than twMerge.
Yep, it’s a good point and the author of Tailwind-Merge also agrees. But if you have a lot of base classes and then a lot of conditional classes it looks better to use object syntax for the conditional classes (which is not possible with Tailwind-Merge alone, so you need clsx for that). So clsx is just there for syntactical reasons
@@ByteGrad With more classes and more conditions I would personally just separate all the style logic into a component and move the above ?: operator so that it loads variables, and then just pass those.
I personally think that adding that library creates more confusion that solves problems, because if I don't know what it does suddenly I have to check and learn it just to discover that it could be easily replaced with ?: operator.
Yeah you can go either way I think. There’s a discussion about this at the Tailwind-Merge repo on GitHub
@Suplen is right
i would suggestion you all to try tailwind-styled-component
@@Suplen all you do is create the variants within the button components... i've never had a problem with classes being overwritten ever.
The problem is that patterns repeat through years. This approach tw uses is not scalable. It good to quickly drop and forget some html page. But it’s not good for teams nor medium projects.
Bem is a good structure for css, module css is a scalable as well. Use proper tool for fitting tasks
Great video. Fast paced but covers all the background and detail. Keep doing more of these please 🙏
Thanks, will do!
Hi, tailwind variants make this in unique lib!
u r explanation is great but when u explain tailwind or per say frontend in general . u must show the result & the learning curve is fast when we see thing. ok thanks
Noted 😁
Hi, very helpful video. Just a suggestion, next time when you upload new video, pls don't chose video for kid category, because I cannot save it to my playlists. Thanks!
I’ve set the video to ‘Not made for kids’. Are you sure that is it?
Could you please redo this video with cva?
So all of this is required to overwrite some base styles? This is nuts.
Tks u so much
clsx is a good match for Tailwind, but I'm not sure about twMerge.
I prefer to have some strict rules in place to control which classes or styles we can pass to a component, especially when working on a project with a design system and typescript
For example, only classes like 'bg-danger' or 'bg-success' should be allowed to be passed to a button component
For projects that prioritize freedom in styling, using twMerge can provide us with a better development experience
I don't think this is fair to say that every Tailwind user needs this or even has access to it. Some of us use Tailwind with twig or blade or other templating engines that don't run in a Node or JS environment. These libraries are specifically for JS projects that use Tailwind. For the rest of us, just add the ! to the prop class.
I am surprised I have to download a third party Library just to overide a className, A simple if check or spread operator should do it.
You can also solve the override problem with passing class with `!important`. It seems easier, in tailwind it just one symbol `!p-5`
!important bad
@@Programmer_Progamer It's probably not as bad with tailwind as in plain css but you can still only use it once and not override !p-5 again.
Just don't allow owerwrite. Make a property like variant = "primary" | "secondary"... and style based on the property
That's very inflexible
@@Tresla How is that inflexible? You should be designing your website using two or three colours at max so setting variants with primary/secondary would be fine. Unless you design your website using the colours of the rainbow
@@genie_dev Color isn't the only style you might want to override...
@Tresla yes, however, your component shouldn't be changing throughout your website. What's the point of creating the Button component in the first place then if you want to change it throughout the whole site?
@@genie_dev bruh have you ever built a website? There are always those little edge cases when a client ask you to do something weird. Better have it ready + it its not that hard to implement lol
js for your css in your js
What's your opinion about reusing styles? I read in the docs about utility-first concept that it's recommended we handle css and HTML as a singular resource, so if your CSS changes, your HTML should be different as well
I.e. instead of creating a Button component that receives a className as prop, we would use N button elements with it's own styles variation.
I heard it's counter intuitive, but it's helpful. Still, I find it so weird and wrong that I don't know if I should follow this pattern. Maybe I misunderstood something. Would you mind sharing your thoughts?
You can go either way I think. I like to be able to style the components very specifically and so prefer to be able to just pass Tailwind classes, not some variant
@@ByteGrad thank you. I like the idea of having a component with some base styles that can be overwritten by props. But as the docs discourages it I was afraid of facing issues in the future. But I'll go that way. Thanks again for taking your time