Composants du serveur React : l'évolution

Introduction

Une fois que j'ai commencé mon parcours en tant que développeur de logiciels il y a environ dix ans, je me contentais de coder du HTML, du CSS, du JavaScript et quelques scripts Python 2 ; à cette époque, nous dépendions uniquement de PHP et SQL pour la communication client-serveur côté serveur. Après cela, le niveau suivant était le mot magique « Réagir », comme réagir aux changements d'état ou d'effets. C'est ce que je comprends, sans approfondir le sujet, de la rumeur selon laquelle un ingénieur de Facebook l'aurait réalisé ; c'était une bombe dans la façon dont nous codions les parties frontales.

À mesure que le développement logiciel évoluait et que les systèmes backend devenaient complexes, les React Server Components (RSC) ont estimé que l'évolution de notre écosystème était désespérément nécessaire. Cela me rappelle l'époque où les bundles JavaScript massifs et les spinners de "chargement" étaient partout. Explorons comment RSC change la donne.

La révolution des performances

Le principal changement apporté par RSC n'est pas seulement technique mais aussi philosophique. Au lieu d'envoyer des arborescences de composants entières au client, RSC nous permet de restituer les composants sur le serveur tout en conservant l'interactivité que nous aimons dans React. J'avais l'habitude de migrer les applications de tableau de bord vers RSC, et c'est assez simple, rien d'extraordinaire, et l'impact évident sur les applications de tableau de bord a diminué de 60 %.

Voici un exemple concret que j'ai rencontré récemment :

 // Before: Client Component
 import { ComplexDataGrid } from 'heavy-grid-library';
import { format } from 'date-fns';

export default function Dashboard() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetchDashboardData().then(setData);
  }, []);

  return <ComplexDataGrid data={data} />;
}

Dans cette approche traditionnelle côté client, plusieurs choses se produisent :

• Nous importons une bibliothèque de grille de données lourde qui est fournie avec notre client JavaScript.
• Nous utilisons useState pour gérer nos données localement dans le navigateur.
• Nous récupérons les données après le montage des composants à l'aide de useEffect.
• L'utilisateur voit un état de chargement pendant la récupération des données.
• Tous les traitements de données s'effectuent dans le navigateur, ce qui peut potentiellement ralentir l'appareil de l'utilisateur.

Maintenant, regardons la version RSC :

import { sql } from '@vercel/postgres';
import { DataGrid } from './DataGrid';

export default async function Dashboard() {
  const data = await sql`SELECT * FROM dashboard_metrics`;

  return <DataGrid data={data} />;
}

• Le composant est asynchrone par défaut - pas besoin de useEffect ou useState.
• Accès direct à la base de données via des requêtes côté serveur.
• Aucun code de récupération de données côté client n'est nécessaire.
• Des états de chargement nuls sont requis pour les données initiales.
• Le traitement des données s'effectue sur des serveurs puissants plutôt que sur les appareils des utilisateurs.
• Le composant DataGrid importé peut être beaucoup plus léger car il n'a besoin que de gérer l'affichage, pas la récupération de données.

La transformation est frappante. Plus d'useEffect, plus de récupération de données côté client et, surtout, plus d'envoi inutile de JavaScript au client.

Avantages concrets

L'impact va au-delà des simples mesures de performances. Lorsque je travaille avec RSC, j'ai remarqué que les requêtes de base de données se rapprochent désormais de la source de données (dans l'exemple ci-dessus, ce n'est pas la meilleure pratique de codage), les composants sont plus simples et plus ciblés, les modèles d'authentification et d'autorisation deviennent plus simples et le référencement. les améliorations sont presque gratuites, ce qui n'était pas le cas auparavant dans le monde React.

Cependant, l'avantage le plus important est l'expérience du développeur. Écrire des composants pouvant accéder directement à votre base de données (sécurité !) ressemble à un super pouvoir. C'est comme avoir le meilleur des deux mondes : l'architecture basée sur les composants de React, avec les avantages en termes de performances du rendu côté serveur le plus avancé avec Next.js

Les compromis

Soyons honnêtes : RSC n’est pas parfait. Le modèle mental prend du temps à comprendre, notamment pour comprendre la frontière client/serveur ; pour moi, une sorte d’opération complexe dans la boîte noire. Je vais suivre mon exemple de migration précédent, nous avons rencontré des obstacles avec des bibliothèques tierces qui n'étaient pas compatibles RSC. La solution ? Une approche hybride :

 // Before: Client Component
 import { ComplexDataGrid } from 'heavy-grid-library';
import { format } from 'date-fns';

export default function Dashboard() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetchDashboardData().then(setData);
  }, []);

  return <ComplexDataGrid data={data} />;
}

Décomposons ce qui se passe dans cette approche hybride :

• La directive use client marque explicitement SearchFilter comme composant client.
• SearchFilter gère les interactions utilisateur (événements onChange) qui ne peuvent se produire que sur le client.
• ProductList reste un composant serveur, récupérant les données côté serveur.
• La composition des composants nous permet de mélanger le rendu serveur et client le cas échéant.
• Seules les parties interactives (SearchFilter) transportent JavaScript vers le client.
• Les parties gourmandes en données (ProductGrid avec produits) sont rendues sur le serveur.

Conclusion (L'avenir passe d'abord par le serveur)

RSC représente plus qu'une simple nouvelle fonctionnalité : c'est un paradigme véhiculé dans la façon dont nous construisons des applications React. La possibilité de déplacer des calculs coûteux et la récupération de données vers le serveur tout en conservant le modèle de composant de React est révolutionnaire.

Pour les équipes qui créent des applications gourmandes en données, RSC offre une voie vers de meilleures performances sans sacrifier l'expérience des développeurs. À mesure que l'environnement évolue et que de plus en plus de bibliothèques deviennent compatibles RSC, je m'attends à ce que ce modèle devienne la façon par défaut dont nous construisons des applications React.

Partagez votre expérience

Avez-vous commencé à utiliser les composants React Server dans vos projets ? J'aimerais avoir de vos nouvelles, vos défis et vos victoires dans les commentaires ci-dessous.
Envoyez un ❤️ si cet article vous a aidé à mieux comprendre RSC, et n'oubliez pas de me suivre pour une plongée plus approfondie dans les systèmes modernes.

À propos de l'auteur

Ivan Duarte est un développeur backend avec une expérience de travail indépendant. Il est passionné par le développement web et l’intelligence artificielle et aime partager ses connaissances à travers des tutoriels et des articles. Suivez-moi sur X, Github et LinkedIn pour plus d'informations et de mises à jour.

? Abonnez-vous à notre newsletter

Lisez les articles de ByteUp directement dans votre boîte de réception.

Abonnez-vous à la newsletter et ne manquez rien.

? Abonnez-vous maintenant ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!