Como os React Server Components mudam a forma como você estrutura uma aplicação?

Server Components rodam só no servidor, não mandam JavaScript para o navegador, e podem dar await em dados diretamente, o que elimina a maior parte do encanamento de fetch mais useEffect mais estado de carregamento. Client Components, marcados com use client, continuam donos da interatividade, do estado e das APIs do navegador. Você empurra a busca de dados para cima, nos server components, e mantém os client components como folhas pequenas, o que reduz o bundle e move a cascata de dados para o servidor.

O modelo mental que fez sentido para mim é que a fronteira é uma fronteira de serialização, não uma pasta. Server Components renderizam no servidor e o código deles nunca chega ao navegador, então uma biblioteca pesada de markdown ou de datas usada ali custa zero kilobyte no cliente. Eles podem dar await em uma chamada de banco direto no corpo do componente. Qualquer coisa com estado, efeitos ou um event handler precisa ser um Client Component com use client no topo, e as props que atravessam para dentro dele precisam ser serializáveis, então você passa dados e não funções ou instâncias de classe. Na prática isso significa que as minhas árvores ficam com server components até o fundo e folhas interativas pequenas, e eu passo os dados buscados no servidor como props. O tradeoff que eu enfrentei em um projeto recente foi carga mental no code review, porque as pessoas ficavam colocando use client em um pai por causa de um botãozinho e puxando em silêncio uma subárvore inteira para o cliente. A gente acabou adicionando uma regra de lint e uma checagem de tamanho de bundle no CI para pegar isso.