React Server Components, un an plus tard : retour d'expérience

Un an après avoir migré trois applications en production vers les React Server Components, le bilan est nettement positif — mais pas pour les raisons que la documentation met en avant.

Les vraies victoires

Le gain le plus tangible n'est pas la performance brute : c'est la disparition d'une couche entière de code de synchronisation. Les écrans qui se contentaient de charger puis d'afficher n'ont plus ni état de chargement, ni cache client, ni hook de récupération de données.

• Environ 30 % de code en moins sur les écrans de consultation.
• Un bundle client réduit de façon nette sur les pages riches en données.
• Moins d'états intermédiaires à tester, donc moins de bugs d'affichage.

Les pièges

La frontière serveur / client est facile à franchir par accident. Un composant marqué client tire avec lui tout son arbre d'imports, et il suffit d'un utilitaire mal placé pour ramener côté navigateur ce qu'on venait d'en sortir.

La question n'est plus « ce composant a-t-il un état ? » mais « qui a besoin de ce code dans le navigateur ? ».

La migration progressive

Migrer écran par écran fonctionne, à condition de commencer par les pages les plus statiques. Attaquer un formulaire complexe en premier est le meilleur moyen de conclure que le modèle ne convient pas.