React Server Components expliqués simplement (avec Next.js)

Les React Server Components m'ont aussi embrouillé, et j'écris du Next.js pour vivre. La doc explique le quoi ; ce qui a fait tilt chez moi vient de les avoir livrés en production — ce site inclus. Voici l'explication que j'aurais aimé lire en premier.

Un Server Component s'exécute une fois, côté serveur, et envoie du HTML plus zéro JavaScript. Un Client Component envoie du code au navigateur. Toute la compétence consiste à décider quelles parties de votre page ont vraiment besoin d'être vivantes.

Le modèle mental qui fonctionne

Arrêtez de penser « frontend vs backend ». Pensez votre arbre de composants comme majoritairement mort, sélectivement vivant. Un article de blog, une carte produit, un footer — morts : rendus une fois côté serveur, HTML envoyé, terminé. Une barre de recherche, un bouton panier, un formulaire — vivants : besoin de JavaScript dans le navigateur. Les RSC font que les parties mortes ne coûtent rien.

Qui tourne où, concrètement

• Server Component (le défaut dans l'App Router Next.js) : peut lire la base de données directement, utiliser des secrets, await n'importe quoi. N'envoie aucun JS. Ne peut pas utiliser useState, onClick ou les APIs navigateur.
• Client Component ("use client" en tête de fichier) : tout ce que React a toujours été — état, effets, événements. Coûte du poids de bundle pour chaque ligne importée.

La frontière est une porte à sens unique : le serveur peut rendre des enfants client, mais un composant client ne peut pas importer un composant serveur (il peut le recevoir en children — le pattern qui résout 80 % des questions « comment faire… »).

Les trois pièges rencontrés en production

• Le « use client » qui rampe : marquez un gros composant client pour un seul onClick, et tout ce qu'il importe part au navigateur. Le fix : poussez la directive vers les feuilles — un petit <LikeButton>, pas toute la page d'article.
• Les cascades : des await imbriqués rendent séquentiellement. Lancez les promesses ensemble (Promise.all) ou passez-les vers le bas et consommez-les avec use().
• Tout dynamique par accident : un seul appel à cookies() fait sortir la route du rendu statique. Isolez les morceaux dynamiques ; gardez la coquille statique et cachée.

Ce que ça change pour de vrais projets

Ce site est un exemple vivant : les pages d'articles sont des Server Components qui lisent Postgres directement — pas de couche API, pas de fetch client, ~0 JS pour le contenu — pendant que le widget de chat et les formulaires admin sont de petits îlots client. Ce mélange est la raison pour laquelle les pages sont rapides, et des pages rapides sont une histoire de SEO et de coûts, pas juste une préférence de développeur.

Faut-il migrer ?

Nouveau projet Next.js : oui, c'est le défaut et le bon. SPA existante : seulement page par page, en commençant par les routes riches en contenu où le gain (poids du bundle, SEO) est le plus grand. Si vous voulez que l'arbitrage soit fait pour votre base de code — ou la migration faite — c'est mon métier.