A quick overview of React Server Components and some of the mental models that are useful when thinking about how they might be applied, in context.

On how server components now need to be much more granular in what gets put in each file, and how splitting is the new paradigm:

Don’t try to build everything in one component, or even in one file. As soon as you get an inkling that some markup or logic should be in its own component, don’t hesitate - just split it out

On when to use client components rather than server ones:

If you need interactivity, like event handlers, useState, useRef, or useEffect, don’t hesitate to break that component into its own file, and add use client to the top.

On the new hierarchy of server > client components:

Once a client component is rendered on the client, how does it execute that server code? Is the client magically able to make calls to the database? No, that’s silly. One of the immutable rules of RSC is that client components can’t render server components.

On how you can get around that hierarchy (sort of):

But there is a literal loophole in this: Using component composition, you can render a server component on the server, but as a child of a client component. Just like you can pass server-fetched data as props from a server component to a client component, you can pass rendered server components as props to client components too.

On how static components shouldn't automatically be regarded as client components, but rather client status should be a last resort only used where absolutely necessary:

So even if a component isn’t fetching any data, there’s no need to slap a use client at the top of the file. In fact, you should only do that if the component is explicitly using client-only features