Au-delà de Next.js : Exploration des cadres de composants alternatifs du serveur React

Quel est l’accord actuel avec React Server Components (RSC) ?

Lorsque fin 2020, l'équipe React a introduit le concept de « composants de serveur React de taille zéro », de nombreuses personnes ont eu et ont encore du mal à le comprendre. Aucun des frameworks existants ne prenait en charge le nouveau concept et les prototypes ne fournissaient pas une base utilisable pour créer des applications réelles.

Aujourd'hui, plus de 4 ans plus tard, la version requise de React est toujours en version bêta et n'est pas publiée pour la production et le seul framework important et bien connu qui la prend en charge est composé d'anciens membres de l'équipe React. C'est une situation très triste pour les quelques développeurs qui ont essayé de proposer des frameworks alternatifs basés sur RSC.

Pourquoi aurais-je besoin de RSC ?

Le React normal est une bibliothèque qui vise uniquement à fournir une solution déclarative rapide pour créer une application dans le navigateur. Les applications du navigateur ont toujours besoin d'un serveur pour récupérer et stocker leur état. Sur la base de ce fait, un grand nombre de solutions ont été développées et existent dans l'écosystème client React. Lorsque de plus en plus de personnes ont commencé à créer leur backend avec Typescript, la tendance suivante a été une renaissance du RPC avec des interfaces typées qui ont créé les points finaux de l'API en arrière-plan.

En regardant le RSC avec ces exigences, il devient rapidement clair que tout cela faisait partie du champ d'application des RSC car ils fournissent :

• actions de serveur typées qui peuvent renvoyer des valeurs et des promesses typées
• Demande de serveur unique pour muter les données sur le serveur et mettre à jour l'interface utilisateur côté client
• restituer les composants sur le serveur et diffuser uniquement au client un arbre de rendu sérialisé qui prend en charge le rendu dans le désordre

Cela permet aux développeurs d'applications d'utiliser React pour définir tous les composants utilisant React indépendamment de leur rendu sur le client ou sur le serveur. Cet environnement intégré réduit la complexité des applications modernes et supprime la redondance de la logique métier dupliquée dans le backend et le frontend.

Quels frameworks prennent en charge RSC ?

Comme la bibliothèque React est officielle, encore en version bêta, aucune d'entre elles ne devrait être considérée comme prête pour la production :

• Suivant.js v15
• Waku
• réagir-serveur
• RedwoodJS v9 - toujours en développement

Actuellement, seul Next.js est quelque peu utilisable pour la production. Leur version 15 est la 4ème itération sur RSC qui a débuté fin 2021 avec la version 12.

Au-delà du framework répertorié, voici quelques référentiels supplémentaires avec des plans pour créer un framework RSC - utilisez-les si vous souhaitez en savoir plus sur les composants internes :

• Vinxi
• Double
• Kotekan
• r19

Si vous connaissez d'autres frameworks, veuillez fournir des liens vers eux dans les commentaires.

Qu’est-ce qui rend RSC difficile à mettre en œuvre dans les frameworks ?

La transcription et le regroupement, basés sur les excellents bundles existants d'une application client React, sont simples. Il existe plusieurs options pour ce faire et l'une des plus utilisées consiste à utiliser ViteJs comme serveur de développement et bundler. Les frameworks qui fournissaient une pile frontend et backend JavaScript devaient encore fournir leur propre solution pour gérer la dactylographie et le regroupement en développement et en production.

Avec RSC, un bundler doit gérer au moins trois pipelines de transcription et de regroupement :

1. Client du navigateur
2. Serveur SSR
3. Rendu de composants RSC et API de stérilisation
4. middleware optionnel

Jusqu'à la sortie de la version 6 de Vite, cela nécessitait beaucoup de code spécial pour fournir une solution fonctionnelle. Next.js vient de passer à Turbopack dans la version 15 pour corriger les retards qu'ils ont obtenus en fonction de la complexité et de l'utilisation de webpack qui n'a jamais été conçu pour gérer ce genre de problèmes.
Les nouvelles fonctionnalités de Vite 6 ciblent de nombreux auteurs de framework et fournissent une excellente solution avec leur nouvelle API environnementale.

Sur la base du fait que les composants sont désormais rendus dans un environnement complètement différent, chaque bibliothèque de réaction doit être construite pour gérer les restrictions de chacun de ces environnements en fournissant un contenu alternatif. Actuellement, la plupart des bibliothèques peuvent gérer le rendu sur le serveur pour créer du contenu SSR, là où de nombreuses API spécifiques aux navigateurs manquent. Le rendu des composants RSC apporte une limitation supplémentaire avec une bibliothèque de serveur de réaction différente qui, par exemple, ne prend pas en charge le contexte de réaction et les bibliothèques d'état et de rupture qui en ont besoin pour fournir une thématique à tous les composants enfants. Et les bibliothèques ont besoin d'une option d'exportation appropriée dans packages.json et ESM-Modules pour la bibliothèque et toutes les sous-bibliothèques associées.

La deuxième pièce non fournie par la bibliothèque React pour RSC est le routeur. Sans un routeur qui gère le routage client et serveur, le composant serveur React ne sait pas quel état afficher sur le serveur. C'est la raison pour laquelle chacun des frameworks est livré avec sa propre implémentation de routeur et jusqu'à ce que l'API correspondante soit standardisée, les composants serveur et clients développés pour un framework devront être modifiés pour fonctionner avec un autre framework.

Toutes les exigences pour un véritable cadre RSC

• Composants du serveur React
  • Composants du serveur sans serveur
  • Composants du serveur avec un serveur
  • Composants asynchrones avec composants serveur
• Actions du serveur
  • Création d'une action serveur à partir d'un composant serveur
  • Importation d'actions serveur à partir de composants clients
  • Composer des actions de serveur avec des actions
  • Actions de formulaire avec actions de serveur
  • Actions du serveur avec useActionState
  • Amélioration progressive avec useActionState
  • Requête unique au serveur avec des données mises à jour pour l'interface utilisateur dans la réponse
• Directives
  • 'use client' vous permet de marquer quel code s'exécute sur le client.
  • 'utiliser le serveur' marque les fonctions côté serveur qui peuvent être appelées à partir du code côté client.
• regroupement pour les trois cibles dans DEV et PROD
• API de routage côté client
• API de routage côté serveur

plus de détails sur les composants du serveur React peuvent être trouvés dans la documentation officielle de React.

Exigences facultatives pour les méta-frameworks :

• Rendu côté serveur (SSR)
• Génération de sites statiques (SSG)
• Mise en page imbriquée
• Diffusion
• Routeur du système de fichiers
• aucun point de terminaison de l'API React
• Middleware
• Cibles de déploiement multiples
• Prise en charge des environnements d'exécution Edge (AWS Lambda@Edge, Cloudflare)

Next.js - pourquoi chercher des options alternatives ?

Sur la base du fait que Next.js 15 est le framework RSC le plus spécialisé, pourquoi devrais-je avoir besoin de rechercher des frameworks alternatifs ?

Les raisons de faire cela sont toujours basées sur l'objectif à atteindre, mais je vais essayer d'énumérer quelques raisons pour lesquelles il est logique d'examiner les autres options :

1. Next.js est un framework complexe qui tente de couvrir de nombreux cas d'utilisation différents qui pourraient ne pas être pertinents pour le projet donné
2. en fonction de la complexité et de l'utilisation de toutes les fonctionnalités fournies, le déploiement sur d'autres environnements cloud en dehors de Vercel n'est pas officiellement pris en charge et nécessite d'énormes efforts pour rester en phase avec les changements apportés à ces exigences d'hébergement avec chaque version mineure et majeure.
3. jusqu'à la version 15, qui change le bundler en Turbopack, l'expérience de développement était lente et lente

Veuillez garder à l'esprit que cet article se concentre uniquement sur les alternatives qui fournissent RSC, mais il existe de nombreux autres frameworks qui fournissent des fonctionnalités presque similaires à RSC et pourraient être de bien meilleures alternatives que les frameworks RSC répertoriés dans cet article.

Waku - Le framework React minimal

Développé par Daishi Kato :

Waku (wah-ku) ou わく signifie « cadre » en japonais. En tant que framework React minimal, il est conçu pour accélérer le travail des développeurs des startups et des agences créant des projets React de petite et moyenne taille. Il s'agit notamment des sites Web de marketing, du commerce électronique léger et des applications Web.

Nous recommandons d'autres frameworks pour les applications lourdes de commerce électronique ou d'entreprise. Waku est une alternative légère apportant une expérience de développement amusante à l'ère des composants serveur. Oui, rendons le développement de React à nouveau amusant !

Démarrer un nouveau projet avec Waku est simple et vous obtiendrez un modèle de démarrage configuré avec tailwind :
npm créer waku@latest

Toutes les exigences de base sont couvertes sauf le renvoi des mises à jour des composants côté client en une seule requête lors de l'utilisation d'actions de serveur en mutation. Actuellement, toute mutation du serveur nécessite une actualisation du routeur client avec router.reload() dans le composant client, ce qui conduit à une deuxième requête au serveur pour charger les données mises à jour sous forme de flux RSC.

Les exigences facultatives suivantes sont encore en développement :

• Routes du système de fichiers imbriquées
• aucun point de terminaison de l'API React

Prend en charge de nombreuses cibles de déploiement : Vercel, Netlify, Cloudflare, PartyKit, Deno, AWS Lambda, NodeJS

En raison de la complexité du regroupement, préparez-vous à avoir des problèmes avec de nombreuses bibliothèques tierces :
https://github.com/dai-shi/waku/issues/423

@lazarv/react-server - Le moyen le plus simple de créer des applications React avec un rendu côté serveur

Développé par Viktor Lázár :

J'ai créé @lazarv/react-server parce que je voulais utiliser les composants React Server et les actions serveur à l'aide de Vite ❤️. Pour la plupart des petites applications, Next.js était trop lourd, trop lourd et trop lent. Je voulais avoir la même expérience lorsque vous exécutez un simple fichier JavaScript à l'aide de node.js. Ce cadre essaie d'être autant que possible sans opinion. Vous pouvez réaliser éventuellement tout ce que vous voulez. La seule restriction est qu'il utilisera sa propre version de React. Vous n'avez même pas besoin d'installer React dans votre projet. Tout est inclus dans le cadre. J'espère que vous apprécierez utiliser ce framework autant que j'ai aimé le créer et l'utiliser également pour créer cette documentation. - lazarv

Apprendre les composants du serveur React est un jeu d'enfant avec ce framework ! Un seul fichier avec un composant de serveur React valide et l'exécution de la commande sont tout ce dont vous avez besoin :

./App.jsx

export default function App() {
  return <h1 id="Hello-World">Hello, World!</h1>
}

npx @lazarv/react-server ./App.jsx

Il existe une bonne documentation sur la façon de démarrer et quelques exemples de projets dans la section tutoriel.

Toutes les exigences de base sont couvertes sauf le renvoi des mises à jour des composants côté client en une seule requête lors de l'utilisation d'actions de serveur en mutation.

Comme le runtime dépend des API NodeJS, d'autres runtimes, par ex. (AWS Lambda@Edge, Cloudflare) ne sont actuellement pas pris en charge.

De plus, la fonctionnalité suivante existe :

• Accéder au contexte HTTP dans les composants et actions du serveur
• Mise en cache de toutes les données du serveur et réponse du serveur avec revalidation basée sur les balises ord clés
• Gestion des erreurs
• Pré-rendu partiel - définir des parties d'une page JSX comme shell statique
• Mode cluster NodeJS
• Micro-frontends : divisez votre application en éléments plus petits et plus faciles à gérer. Utilisez le composant RemoteComponent pour charger une micro-frontend à partir d'une URL distante et la restituer dans votre application à l'aide du rendu côté serveur

Cibles de déploiement : NodeJS, Vercel - Adaptateurs en développement : Netlify, Cloudflare, sst

Prend en charge Tailwind CSS, TanStack Query, Mantine UI, Material UI.

RedwoodJS - Le framework de développement unique qui fonctionne tout simplement

Fourni par Tom Preston-Werner :

Redwood est le framework d'application JavaScript full-stack.
Batteries, backend, React, conventions et opinions inclus.

Toujours en développement et fonctionne uniquement avec Node v20 et Yarn 4 :

export default function App() {
  return <h1 id="Hello-World">Hello, World!</h1>
}

Vous devrez ensuite activer quelques fonctionnalités expérimentales :

npx @lazarv/react-server ./App.jsx

Enfin, construisez et servez :

npx -y create-redwood-app@canary -y ~/rsc_app
cd ~/rsc_app

Dans le cadre de la commande setup-rsc, une application RSC barebones est créée pour vous, démontrant le rendu d'un composant client à l'intérieur d'un composant serveur

Cibles de déploiement : Vercel, Netlify, Render, GCP ou AWS via Coherence, AWS via Flightcontrol, NodeJS

Comparaison : Next.js et Alternatives

	Next.js	WAKU	React-server	RedwoodJS
DEV-Environment / Bundling	Turbopack	Vite 5	Vite 6	Vite
Rendering	SSR, ISR, SSG, CSR	SSR, SSG, CSR	SSR, SSG, CSR, Micro-Frontends	SSR, SSG, CSR
Caching Layers	Yes	No	Yes	??
Deployment Target	Vercel, NodeJS	Vercel, Netlify, Cloudflare, Deno, AWS Lambda, PartyKit, NodeJS	Vercel, NodeJS, sst (AWS Lambda)	Vercel, Netlify, AWS, NodeJS
Community	Very Big	Tiny	Just Starting	Small
Open Source Financing	Vercel	Donations	Donations	Privately Funded by a Rich Guy

Conclusion

Récapitulatif des principaux points à retenir :

• RSC fournit un paradigme puissant pour le développement Web moderne.
• Next.js est excellent mais ce n'est pas le seul choix.
• Les alternatives offrent diverses fonctionnalités pour différents besoins, mais manquent les mises à jour de l'interface utilisateur de mutation à demande unique.
• Les bibliothèques de l'écosystème React ne sont toujours pas prêtes à adopter RSC

Essayez les frameworks pour trouver celui qui convient le mieux à votre projet.

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!