Understanding nuances in React Server Components
Original email from May 9th, 2025
I went to see System of a Down last Saturday 🤘
They came here to Argentina as part of their "Wake Up" tour, where they played in the Velez Stadium, relatively close to where I live. It was AWESOME. So awesome and loud in fact that, according to my mother, she could hear it from her own house
What wasn't awesome was that even before the concert, I felt like I was starting to get a little sick. I had managed it well leading up to it... but the next day, the fever started coming in.
I went to see System Of A Down, but just ended up going Down With The Sickness
Budumm tsssss 🥁
(And also a completely unrelated song from another band )
On top of the health challenge of recovering from the flu and the fevers, I was also tasked with quite a few frontend problems and challenges this week relating to RSC. So it seemed fitting to share a few insights I got around it in today's newsletter. So without further ado...
How I adjusted my mental models while working with Server Components:
Lately, I've been getting more and more used to working in Next with the new way of thinking with RSC (React Server Components). While a little late to the party, I'm happy that there are so many resources now that I can just look up and fully understand.
While I had fully understood the main idea of RSC, I did run into a few tiny hiccups in how I was going about it.
I understand that server components only render on the server and just send the finished HTML to the client. You can't use things like useEffect or state because they don't rerender. To do that, you'd need to turn them into client components.
One of the little adjustments in how I approached them was made while reading what Josh Comeau, in his amazing article on the subject, refers to as "Client Boundaries".
You can think of React projects as a giant tree of components. Components render other components, which render others, and so on. Some of these components render only on the server. Others are "client" components and can be rendered in both.
I had thought of client components as being the "leaves" of this tree. This brings out a sort of rule: "If you use client components, all components inside must be client components as well". Which made sense. Since server components can only be rendered on the server, you can't directly import them inside of client components. Otherwise, you'd have a weird situation where if a client component rerenders, it'll try to rerender its server components as well (which it can't do because the browser doesn't have that code), and everything breaks.
But then there's nuance. I learned two things this week:
When you use 'use client', you're implicitly converting all children of that component into client components themselves in that instance. Josh's article teaches this, and I ❤️ him for it. There is one "exception" to this, though.
That "exception" is outlined in Next's docs, where you're allowed to use server components inside client ones if the component is passed through by props.
This last point makes sense. As long as the server component has been rendered, why not allow it to be inside a client component? After all, once the server has done its job, you just end up with HTML. It would be functionally the same as pasting that HTML inside the client component.
Then things finally clicked into place. Things got easier from there.
I still haven't been fully convinced of this way of thinking (this intermingled approach of mixing server with client code has huge pros and cons), but if I ever fully form an opinion on it, I'm sure I'll share it with you all.
As always, have a wonderful Friday and weekend
Please don't get sick like I did.