Les RSC pour les développeurs Astro

 (overreacted.io)
2 points par GN⁺ 2025-05-10 | 3 commentaires | Partager sur WhatsApp
  • Astro et les React Server Components (RSC) implémentent de façon similaire la séparation entre le code serveur et le code client
  • Dans Astro, Astro Component et Client Island se partagent chacun un rôle fonctionnel
  • Les RSC reprennent le même concept en le divisant entre Server Component et Client Component, avec la directive 'use client' pour définir la frontière
  • Par rapport à Astro, les RSC offrent plus de souplesse pour composer des UI interactives et partager du code
  • Les deux modèles reposent sur une structure où les données circulent à sens unique, du serveur vers le client

Introduction et concepts de base

  • Astro fournit deux grands types de composants : Astro Component et Client Island
  • Un Astro Component utilise l’extension .astro, s’exécute uniquement sur le serveur ou au moment du build, et peut effectuer des opérations impossibles côté client, comme accéder au système de fichiers, interroger une base de données ou appeler des services internes
  • Un Client Island est un composant destiné à React, Vue, etc., qui s’exécute dans le navigateur et prend en charge les interactions utilisateur
  • Un Astro Component peut rendre un Client Island, mais un Client Island ne peut pas appeler un Astro Component
  • Cette structure garantit une unidirectionnalité où les données circulent toujours du serveur vers le client

Exemple de code et séparation des rôles

  • Dans l’exemple de code, PostPreview.astro lit un fichier sur le serveur, en récupère le titre, puis transmet ces données à un Client Island
  • LikeButton, écrit en React, prend ensuite en charge les changements d’état et les clics utilisateur une fois le navigateur chargé
  • Astro Component et Client Island fonctionnent dans deux mondes distincts, et le passage des données se fait uniquement vers le bas à partir de l’Astro Component

Comparaison avec les React Server Components (RSC)

  • Comme Astro, les RSC distinguent composants serveur (Server Components) et composants client (Client Components)
  • Avec React Server Components, on déclare les composants serveur sous forme de fonctions JavaScript, et la directive 'use client' indique explicitement où commence le code client
  • Dans les RSC, un même fichier de composant peut jouer à la fois un rôle serveur et un rôle client : contrairement à Astro, il n’y a pas besoin d’extension de fichier spécifique ni de séparation distincte, et la frontière peut être déplacée selon le besoin par une simple déclaration 'use client'
  • Lorsqu’un composant utilise une fonctionnalité réservée au client (par exemple useState) ou au serveur (comme l’accès à la base de données), une erreur de build se produit s’il est utilisé dans le mauvais environnement, ce qui fournit un retour clair

Différences visuelles et structurelles entre Astro et les RSC

  • Astro possède une frontière claire grâce à la séparation entre fichiers .astro et fichiers JS/TS
  • Les RSC, où tout repose fondamentalement sur React, offrent une bien meilleure capacité de partage de code et davantage de souplesse
  • Par exemple, un composant neutre (comme un parseur Markdown) qui n’utilise ni état ni fonctionnalité serveur peut être utilisé des deux côtés
  • Dans les RSC, l’endroit où un composant s’exécute est déterminé automatiquement selon son chemin d’import

Avantages et limites du modèle RSC

  • L’intérêt des RSC réside dans la réutilisation du code et la souplesse de déplacement des rôles
    • N’importe quel composant peut franchir facilement la frontière selon les besoins avec une simple déclaration 'use client'
    • Dans Astro, quand la nature statique ou dynamique d’une UI évolue, la transformation du code peut devenir fastidieuse ; les RSC simplifient ce point
  • Le principal inconvénient des RSC est leur courbe d’apprentissage plus élevée
    • Le développeur doit en permanence se demander « dans quel monde suis-je ? », mais une erreur de build fournit un retour rapide en cas d’erreur
  • Dans Astro, plus les parties dynamiques d’une UI augmentent, plus la structure se complexifie ; avec les RSC, tout l’arbre React est unifié, ce qui rend plus naturels la gestion de l’état et la transmission du contexte (Context)

Astro centré sur le HTML et RSC centré sur l’arbre React

  • Le résultat produit par Astro est du HTML : à chaque navigation, la page est entièrement rechargée, ce qui n’offre pas une expérience SPA complète
  • Le résultat des RSC est un arbre React (d’abord en HTML, puis transmis en JSON, etc. lors de la navigation)
    • Cela permet de combiner les avantages des SPA et des MPA
  • Il est possible de ne rafraîchir et répercuter directement depuis le serveur qu’une partie de l’UI, ce qui facilite les rafraîchissements partiels, la réception de données dynamiques et la conservation de l’état côté client

Prise en charge des fonctionnalités avancées de React

  • Grâce à une structure d’arbre hybride serveur-client, les fonctionnalités avancées de React (comme <Suspense>, les view transitions, etc.) s’intègrent naturellement
  • Il est aussi possible de gérer de manière déclarative côté client les états de chargement, ainsi que les retards liés aux polices, images, JavaScript et styles
  • Toutes les fonctionnalités de React fonctionnent de bout en bout, sans rupture à la frontière entre serveur et client

Place respective des RSC et d’Astro

  • Astro est un framework complet, tandis que les RSC se rapprochent davantage d’un bloc de construction ou d’un standard pour les frameworks
  • Les implémentations officielles des RSC incluent Next.js App Router et Parcel RSC

Conclusion et recommandation

  • L’expérience développeur (DX) des RSC reste encore un peu brute, mais mérite d’être explorée
  • Si vous n’avez pas encore essayé Astro, c’est recommandé : pour les développeurs qui trouvent les RSC difficiles, Astro offre une porte d’entrée plus douce
  • Même pour les développeurs qui n’ont utilisé que React côté client, Astro peut apporter une expérience de résolution de problèmes inattendue

À lire aussi

3 commentaires

 
hakoiko 2025-05-13

Je refactorise actuellement une ancienne application React vers Astro.
L’article met l’accent sur le « contexte intégré ». Le « contexte intégré » aide à créer rapidement un service, mais il faut savoir qu’il peut devenir une dette technique un jour.
Du point de vue de la maintenance à long terme du service, un « couplage lâche entre modules indépendants » vaut mieux qu’un « couplage fort intégré ».
Et Astro est justement le framework le plus flexible pour cela.
 
GN⁺ 2025-05-10
Avis Hacker News
  • La seule raison pour laquelle j’utiliserais RSC plutôt qu’Astro, c’est la possibilité de partager du contexte entre les îles, à part ça il n’y a pas vraiment d’avantage particulier ; et, détail mineur, j’aurais aimé que cet article mentionne clairement et explique le concept de "code fence" dans Astro, cette idée délimite bien plus nettement la frontière entre serveur et client que le use client de React
    • Je ne pense pas que le code fence représente réellement une frontière ; le code sous la fence doit lui aussi s’exécuter sur le serveur, sinon on ne pourrait pas y référencer des composants Astro ; si j’ai bien compris, la fence signifie seulement la distinction entre « binding » et « template », pas entre « serveur » et « client »
    • Partager du contexte entre les îles est vraiment facile dans Astro, voir ce lien : https://docs.astro.build/en/recipes/sharing-state-islands/
  • Astro est un framework web pour les sites centrés sur le contenu, https://github.com/withastro/astro
    • Ceux qui utilisaient Gatsby se souviendront toute leur vie du jour où ils ont enfin échappé à un pipeline de traitement d’images instable relié via GraphQL (ils étaient alors devant leur ordinateur) ; je n’ai aucune preuve, mais c’est un fait scientifique que le net promoter score d’Astro contient cinq 9
    • Astro est vraiment excellent, c’est mon choix par défaut pour le SSG depuis des années, et maintenant j’envisage sérieusement Astro aussi pour construire des apps ; quelqu’un a-t-il de l’expérience avec Astro pour des apps ? J’envisage de n’utiliser Astro que pour rendre du HTML basé sur des îles et de garder le backend en non-JS
    • « Un framework web pour les sites centrés sur le contenu » — donc il existe aussi des sites pilotés non par du contenu mais par des générateurs de nombres aléatoires ?
  • J’adore vraiment, vraiment Astro ; je l’utilise depuis sa première sortie, j’ai créé mon site personnel et la landing page de mon premier produit avec Astro ; les builds sont rapides, on peut déployer sans JS, et on peut utiliser n’importe quelle bibliothèque frontend, donc pour moi c’est le meilleur framework