Anyone feels RSCs is kinda leaky abstraction? This isnt any strong opinion or statement, but i have this feeling that with RSCs we spend a lot of time thinking about how to organize code due to the server and client boundaries instead of the domain we are tackling. I cant quite articulate why but it makes me feel uncomfortable. Thanks for video though, appreciate it as usual.
That's neat, but then there's (apparently?) no intellisense or type safety between the `highlight` in the caller vs the Highlight component. If I change `highlight` to `highlighted` on one side vs the other, nothing will alert me of an issue. Btw, I love your videos, they are well explained. I think the extraction of that very general single-focused wrapping component is very clean otherwise.
Great point! I like the simplicity of data attributes (flexible in many environments) but if you wanted to lock it down I guess you could expose some props instead: - highlightEnterClassName - highlightLeaveClassName then wire those up inside the component 👍
Loved the video sir. Your videos helped me a lot to learn framer motion. Will you please create a framer-motion video taking Imperative coding approach using useAnimate hook
If I understand the question correctly, if you rename the variable using F2 or right click -> rename, all the instances within the scope automatically get the correctly renamed.
Masterful video as always. I’m trying to wrap my head around the refactor to being server component-compliant and what benefits that produces. Am I correct in assuming that the refactor will allow it to initially render in the DOM on load versus needing JS to load and hydrate the component if it remained a client component?
Nope - Client Components are pre-rendered so you'd still have HTML for the initial response. The benefit is being able to use Highlight within a Server Component. Highlight itself is still client, so still ships React and hydrates. But the page is RSC, so it can do things only RSC can do, like read data from a database. Being able to use Highlight as a component rather than a hook means you could highlight parts of an RSC if a prop changed, for example dynamic data from a database, or data from a cookie (as in the Build UI demo). RSC is not about reducing JS or initially rendering HTML. It's about letting you write React components that do things we previously needed framework-specific APIs for, like getServerSideProps from Next.js or loader() from Remix. That's the benefit of RSC, and so the benefit of giving Highlight an interface that's easy to use from either a SC or a CC is that it's the kind of thing you'd likely want to use in both places.
How did you create multiple cursors in each of the occurances of the word "visitors" (but exclude some of them) at 2:36? Blew my mind! (Looks like youre using vim, i also use vim but didnt know about that!)
Object styles with something like chakra is better than tailwind because tailwind feels like a whole new language to learn and looks like a wall of text rather just an extension of js like react is
Super neat! Love that data attribute pattern. I can see it being very flexible for component libraries.
I was literally stalking your channel for new videos and you dropped this haha
Thanks Sam!
your content is always so effective and really useful. thanks
nice job dude! tks a lot! I will definetly look for use more data atributes!!
Anyone feels RSCs is kinda leaky abstraction? This isnt any strong opinion or statement, but i have this feeling that with RSCs we spend a lot of time thinking about how to organize code due to the server and client boundaries instead of the domain we are tackling. I cant quite articulate why but it makes me feel uncomfortable. Thanks for video though, appreciate it as usual.
I feel you get that with practice, or just mark all as server component and forget about it
That's neat, but then there's (apparently?) no intellisense or type safety between the `highlight` in the caller vs the Highlight component. If I change `highlight` to `highlighted` on one side vs the other, nothing will alert me of an issue.
Btw, I love your videos, they are well explained. I think the extraction of that very general single-focused wrapping component is very clean otherwise.
Great point! I like the simplicity of data attributes (flexible in many environments) but if you wanted to lock it down I guess you could expose some props instead:
- highlightEnterClassName
- highlightLeaveClassName
then wire those up inside the component 👍
I was wondering the same... Thanks for giving some insight into a type safe approach Sam and awesome video!
The goat. Learned a lot of useful stuff
Thank you so much
Awesome job. As always
Simply awesome!
this is superb
Why you use let instead of const?
Nice video, but those 'let' instead of 'const' is killing me!
Great video and design as always, Sam, inspire me with your lessons. Tell me, what app do you use to record video and screen?
amazing. thanks Sam.
great as always 🔥
Loved the video sir. Your videos helped me a lot to learn framer motion. Will you please create a framer-motion video taking Imperative coding approach using useAnimate hook
loved the video, how does your naming always get converted to camel case automatically??
If I understand the question correctly, if you rename the variable using F2 or right click -> rename, all the instances within the scope automatically get the correctly renamed.
@@serveshchaturvedi2034 Yep F2 to rename, or for useState I use this snippet: gist.github.com/samselikoff/846f48370086fc502a66a7df7dd0a7cb
Masterful video as always. I’m trying to wrap my head around the refactor to being server component-compliant and what benefits that produces. Am I correct in assuming that the refactor will allow it to initially render in the DOM on load versus needing JS to load and hydrate the component if it remained a client component?
Nope - Client Components are pre-rendered so you'd still have HTML for the initial response. The benefit is being able to use Highlight within a Server Component. Highlight itself is still client, so still ships React and hydrates. But the page is RSC, so it can do things only RSC can do, like read data from a database.
Being able to use Highlight as a component rather than a hook means you could highlight parts of an RSC if a prop changed, for example dynamic data from a database, or data from a cookie (as in the Build UI demo). RSC is not about reducing JS or initially rendering HTML. It's about letting you write React components that do things we previously needed framework-specific APIs for, like getServerSideProps from Next.js or loader() from Remix. That's the benefit of RSC, and so the benefit of giving Highlight an interface that's easy to use from either a SC or a CC is that it's the kind of thing you'd likely want to use in both places.
@@samselikoff Ahh. Really great explanation. Appreciate the great work 👍
@@kevinpruettyou got it!
How did you create multiple cursors in each of the occurances of the word "visitors" (but exclude some of them) at 2:36? Blew my mind! (Looks like youre using vim, i also use vim but didnt know about that!)
Just curious about which extensions you use in your VS Code, Please mention it 🔥
why did you set value type to unknown?
Object styles with something like chakra is better than tailwind because tailwind feels like a whole new language to learn and looks like a wall of text rather just an extension of js like react is
so basically we could handle dark/light mode with that approach? It would be a lote harderd to maintain tho