Sounds like a great idea for a series! 😮 hopefully you will do form elements. Also does using that package still allow the code hinting of the tailwind plugin to work?
That's exactly the plan, to run through all the form elements and make them awesome. And yes! `CLSX` still allows all the tailwind extensions to work perfectly.
NIce video! My great question is how reuse components library on a any React Application beyond of Next.js, with the new React 18 features compatibility. You will teach to make a StyleProvider ?
You can either package the component up as an NPM module, or put it into a Monorepo and reference it from many projects. Both ways have pros and cons, depends on your need. And yes! I'll make a way to theme these components in the future so you can change the theme.
I'm going to add that in the next video. In general... I'm not totally sold on it, but doing variants without it is equally painful. It's a way to organize the chaos, but I'm not sure it's the best way. I don't have a better solution.
Also u should always wrap components in libraries in forwardRef, bcs other libraries in consumer code can rely on that behavior It would be great if u show in next video how to make button as link, how to type `ForwaredRef` and change `ButtonHTMLAttributes` to `AnchorHTMLAttributes` so consumer code can pass `href ` attribute
You're right! I messed this up! I was thinking "whichever is last" in the class list, but you're right, it's whichever is last in the stylesheet. The caller can always mark them as important to override if they want.
Yes, I'm going to add forwardRef in a later video -- for a basic "make a quick custom button" it felt like it was better to start simpler. The Button to Link discussion is honestly an interesting one to have. Is that the same component, or a different component? I *think* later on I'll end up making that a different component with some shared code between them, because I'll be using React Aria for the low level guts and that has a useButton and useLink hook as separate. We'll see!
@@ethan_mick Button as Link story always ended droping `as="a" ` in favor of composition : ``` See more ``` But it actually invalid, according to html spec, u cannot have nested interactive elements(button in links, button in button, etc)
@@nazarshvets7501 Yeah, I definitely don't want to do that (invalid HTML). I'm not a huge fan of "required props" -- if doing that changes the underlying element, it feels like a different component would be more natural. But I'm open to hearing all sides here :)
Hi You are doing great job by doing those videos. I have question not related to this specific video but about next auth one. I am using getserversession in layout.js file and pass to navbar so i don't have to show flicker effect of client side authentication. Is it good or i have to useSesssion must. Thanks a lot again for doing those awesome videos.
That's fine. If your NavBar is a server component itself you can just do the lookup in that component and isolate it from the Layout. I'd move the getServerSession call as close to where it's used as possible.
@@NotBeHaris It should be almost nothing -- the request isn't making any network request. It's simply reading the data from the network request. I'd always lean toward clean code that's easy to maintain and not worry about performance until it's actually a problem. Then you can profile to find the real bottlenecks.
I actually outlined a video for a Text Field with React Aria Components, but wasn't sure it provided enough value -- at that point it was basically just styling the component and talking through how React Aria works. Maybe that's still good??
I've been using TSUP tsup.egoist.dev/ to do the compiling into an NPM compatible package. I'm going to be putting all these components into a package + website where you can easily grab them soon.
