¿Cómo cambian los React Server Components la forma de estructurar una aplicación?

Los Server Components se ejecutan solo en el servidor, no envían JavaScript al navegador y pueden hacer await de datos directamente, lo que elimina casi toda la fontanería de fetch más useEffect más estados de carga. Los Client Components, marcados con use client, siguen siendo dueños de la interactividad, el estado y las APIs del navegador. Empujas la obtención de datos hacia arriba, a los componentes de servidor, y dejas los de cliente como hojas pequeñas, lo que reduce el bundle y mueve la cascada de datos al servidor.

El modelo mental que me hizo clic es que la frontera es una frontera de serialización, no una carpeta. Los Server Components se renderizan en el servidor y su código nunca llega al navegador, así que una librería pesada de markdown o de fechas usada ahí cuesta cero kilobytes en el cliente. Pueden hacer await de una llamada a base de datos directamente en el cuerpo del componente. Cualquier cosa con estado, efectos o un manejador de eventos tiene que ser un Client Component con use client arriba, y las props que cruzan hacia él deben ser serializables, así que pasas datos y no funciones ni instancias de clase. En la práctica eso significa que mis árboles son componentes de servidor hasta abajo con pequeñas hojas interactivas, y paso los datos obtenidos en servidor como props. La compensación con la que me topé en un proyecto reciente fue la carga mental en la revisión de código, porque la gente seguía añadiendo use client a un padre por un botoncito y arrastraba en silencio todo un subárbol al cliente. Acabamos añadiendo una regla de lint y una comprobación de tamaño de bundle en CI para cazarlo.