TanStack vient de corriger la pire idée de React

Les Server Components (RSCs) de React ont déclenché une guerre civile parmi les développeurs. Introduits comme une primitive puissante, leur implémentation généralisée est plutôt devenue une source d'intense frustration, suscitant des débats où le sentiment « la plupart du temps, on déteste ça ces jours-ci » prévaut souvent. Beaucoup considèrent les RSCs non pas comme une amélioration, mais comme une imposition complexe.

Next.js, le framework dominant exploitant les RSCs, a largement dicté ce paradigme controversé. Son approche server-first a contraint les développeurs à un modèle où le serveur « possède l'arbre », et la directive `use client` est devenue une échappatoire nécessaire pour l'interactivité. Cette conception a transformé les RSCs d'une « primitive utile en une chose autour de laquelle toute votre application doit orbiter », comme souligné dans une récente Annonce.

Maintenant, un nouveau concurrent est entré en jeu, promettant de changer fondamentalement ce récit. TanStack Start vient de livrer sa propre implémentation des Server Components, adoptant une approche radicalement différente qui pourrait enfin convaincre les sceptiques. Ce framework remet en question l'idée que les développeurs doivent s'engager pleinement dans une architecture server-first pour bénéficier des RSCs.

Au lieu de s'appuyer par défaut sur un modèle centré sur le serveur, TanStack Start défend une philosophie client-first. Il permet aux développeurs d'opter pour les server components avec une granularité sans précédent, les traitant « aussi granulairement que vous pourriez récupérer du JSON côté client ». Cela signifie intégrer le rendu et la logique côté serveur uniquement là où cela apporte une valeur claire, sans restructurer une application entière.

Cette stratégie délibérée et opt-in vise à démystifier les React Server Components et à libérer leur potentiel sans la complexité associée. En offrant une voie qui respecte les modèles de développement client-side existants, TanStack Start pourrait redéfinir la conversation autour des RSCs, transformant le scepticisme généralisé en un véritable enthousiasme. Le framework offre une alternative convaincante au paradigme server-first prédominant et souvent décrié.

L'introduction récente des Server Components par TanStack Start redéfinit radicalement leur intégration dans les applications React. Au lieu d'imposer un changement de paradigme, TanStack défend une philosophie client-first, permettant aux développeurs d'opter pour les capacités serveur avec une précision chirurgicale. Cette approche contraste fortement avec le modèle « server-first » popularisé par Next.js, où chaque composant est par défaut un server component à moins d'être explicitement marqué par une directive `'use client'`.

Next.js présente les Server Components comme le propriétaire par défaut de l'arbre de composants, avec des segments `'use client'` désignant des îles interactives côté client. Cette architecture contraint souvent les développeurs à restructurer des applications entières autour du rendu côté serveur, même lorsque seules de petites parties en bénéficient. TanStack rejette cette proposition tout ou rien, affirmant que les développeurs ne devraient pas « avoir à adhérer à tout ce modèle d'emblée juste pour tirer de la valeur des React server components ».

La vision de TanStack traite les Server Components comme une primitive puissante, utilisable « aussi granulairement que vous pourriez récupérer du JSON côté client ». Cela signifie que les développeurs peuvent introduire sélectivement la logique et le rendu côté serveur précisément là où cela offre des avantages tangibles, tels que la réduction de la taille des bundles clients ou la gestion sécurisée des données sensibles. Le framework facilite cela grâce aux fonctions serveur et à l'API renderServerComponent.

Considérez un scénario où un composant client a besoin de données uniquement côté serveur, comme un nom d'hôte de système d'exploitation ou des variables d'environnement. TanStack Start permet aux développeurs d'encapsuler cette logique dans une fonction serveur, qui renvoie ensuite un composant serveur rendu via `renderServerComponent`. Ce composant peut ensuite être récupéré et intégré dans un chargeur de route côté client, tout comme n'importe quelle autre donnée.

Ce mécanisme explicite et opt-in maintient le contrôle fermement entre les mains du développeur. Il permet aux équipes de tirer parti de la puissance du serveur pour des tâches spécifiques sans modifier fondamentalement leur modèle mental React établi. L'objectif est d'augmenter, et non de bouleverser, l'expérience de développement React traditionnelle côté client, en veillant à ce que les capacités du serveur améliorent plutôt qu'elles ne dictent l'architecture de l'application.

La création de votre premier TanStack Server Component révèle un flux de travail rafraîchissant et explicite. Pour commencer, définissez un simple composant React, comme un `Greeting` qui nécessite des données côté serveur, telles que le nom d'hôte du système d'exploitation. Tenter d'accéder directement aux API Node.js comme `os.hostname()` dans un composant client standard échouera, car ces fonctions ne sont pas disponibles dans l'environnement du navigateur.

TanStack introduit les fonctions serveur pour encapsuler la logique côté serveur. Considérez une fonction `getGreeting`, qui devient votre passerelle vers le code exécuté sur le serveur. À l'intérieur de cette fonction serveur, vous invoquez la primitive `renderServerComponent`, en enveloppant votre composant `Greeting`. Cette fonction cruciale prépare le composant pour le rendu côté serveur, le transformant efficacement en une unité autonome et rendable.

```typescript // server/functions/getGreeting.ts import { renderServerComponent } from '@tanstack/start'; import { Greeting } from '../components/Greeting'; import os from 'os';

export async function getGreeting() { const hostname = os.hostname(); const serverOnlyVar = process.env.SECRET_KEY || 'N/A'; return renderServerComponent(<Greeting hostname={hostname} secret={serverOnlyVar} />); }

Ensuite, intégrez ce composant rendu côté serveur dans le flux de données de votre application. Dans un chargeur de route, qui s'exécute purement sur le serveur, vous `await getGreeting()` simplement. Cela récupère le composant pré-rendu de votre fonction serveur, tout comme vous le feriez pour n'importe quelle autre donnée. Le chargeur renvoie ensuite ce composant, prêt à être consommé.

```typescript // app/routes/index.tsx import { createFileRoute, useLoaderData } from '@tanstack/react-router'; import { getGreeting } from '../../server/functions/getGreeting';

export const Route = createFileRoute('/')({ loader: async () => { return { serverGreeting: await getGreeting(), }; }, component: function Index() { const { serverGreeting } = useLoaderData<typeof Route.loader>(); return ( <div> {serverGreeting} </div> ); }, }); ```

Côté client, utilisez `useLoaderData` pour récupérer le composant serveur. Vous pouvez ensuite le rendre directement dans votre JSX, exactement comme un composant client régulier. Cette intégration transparente met en évidence la philosophie client-first de TanStack ; les Server Components fonctionnent comme un autre type de données que vous récupérez et affichez, et non comme une architecture par défaut. Pour une compréhension plus large des concepts des composants serveur, y compris l'approche server-first, explorez Getting Started: Server and Client Components - Next.js.

La puissance de cette approche devient immédiatement apparente. À l'intérieur de votre fonction serveur `getGreeting`, vous pouvez accéder en toute confiance aux ressources réservées au serveur. Imaginez récupérer `os.hostname()` ou lire en toute sécurité des variables d'environnement inaccessibles au client. Ces opérations s'exécutent purement sur le serveur, avec seulement le HTML rendu livré au navigateur, améliorant à la fois la sécurité et les performances. Cette séparation explicite indique clairement où votre code s'exécute, un contraste frappant avec les modèles implicites 'server-first'.

Cette méthode simplifie radicalement le modèle mental des développeurs. Votre application React reste centrée sur le client par défaut, vous permettant d'opter pour des capacités serveur de manière granulaire. Les développeurs bénéficient de tailles de bundle réduites et d'un accès direct aux ressources backend sans la surcharge cognitive d'un paradigme 'server-forced'. L'implémentation est intuitive, traitant les composants serveur comme une fonctionnalité puissante et opt-in plutôt qu'une contrainte globale sur l'architecture de votre application.

Les avantages de l'expérience développeur du modèle explicite de TanStack sont immédiats et profonds, dissipant l'ambiguïté courante des React Server Components. Le code destiné au serveur s'exécute sans équivoque à l'intérieur d'une server function dédiée, éliminant tout doute quant à son environnement d'exécution. Cette démarcation claire, souvent en utilisant le wrapper `renderServerComponent`, garantit que les développeurs savent instantanément où la logique spécifique liée au serveur – telle que la récupération de `os.hostname()` ou l'accès à des variables d'environnement sensibles réservées au serveur – s'exécutera. Cette clarté élimine la surcharge mentale liée à l'inférence des contextes d'exécution, offrant une clarté essentielle dès la première ligne de code.

Cette conception explicite améliore radicalement la réutilisabilité et la maintenabilité des composants au sein d'une application. Un composant React lui-même peut rester « bête », ignorant totalement s'il est rendu côté client ou côté serveur. Toute la logique côté serveur, la récupération de données et le traitement sont proprement encapsulés dans les server functions, puis transmis au composant via des props standard. Ce modèle puissant découple efficacement la logique de rendu du composant de sa source de données, rendant les composants intrinsèquement plus portables, testables et adaptables à divers contextes d'application sans nécessiter de modifications internes pour la connaissance du serveur.

Contrastez cela avec le potentiel de confusion inhérent à Next.js, où le modèle par défaut « server-first » brouille souvent la frontière client/serveur. Sans un wrapper de fonction serveur explicite, les développeurs doivent s'appuyer fortement sur la directive `use client` et souvent sur des conventions de framework subtiles pour inférer les contextes d'exécution. Cela peut entraîner des erreurs d'exécution inattendues, un gonflement inutile du bundle côté client dû au code réservé au serveur, et une compréhension fragmentée du comportement des composants. L'approche client-first de TanStack, traitant les Server Components comme une fonctionnalité opt-in, aussi granulaire que la récupération de JSON, favorise un modèle mental intuitif où la logique serveur est invoquée délibérément, et non implicitement supposée ou accidentellement déclenchée par le placement des composants.

TanStack Start maintient un support explicite pour la directive `use client`, assurant la compatibilité et offrant une échappatoire familière aux développeurs en transition depuis d'autres frameworks. Placer cette directive en haut d'un fichier marque sans équivoque un composant et tout son sous-arbre comme côté client, permettant une interactivité complète, y compris la gestion de l'état local via `useState` et la gestion des événements DOM.

Cependant, s'appuyer de manière extensive sur `use client` pour intégrer des composants interactifs au sein d'une arborescence de composants majoritairement côté serveur présente des défis architecturaux considérables, particulièrement évidents dans le modèle Next.js. Là, un composant serveur assume fréquemment la responsabilité directe du rendu et de l'orchestration de la présence des composants client, créant une hiérarchie implicite où la logique serveur dicte l'interactivité client.

Cette propriété directe des composants du serveur au client cultive un arbre de dépendances désordonné. Un composant serveur, fondamentalement conçu pour la diffusion de contenu statique et la récupération de données, devient directement responsable du rendu, du flux de contrôle et même de l'existence de ses enfants interactifs côté client. Ce couplage étroit rend inutilement difficile le traçage des cycles de vie des composants et la compréhension du flux de données explicite à travers la frontière serveur/client.

Naviguer dans cette logique entrelacée diminue rapidement la productivité des développeurs et rend opaque le raisonnement sur les responsabilités des composants. Par exemple, diagnostiquer un problème avec un `CounterButton` interactif pourrait impliquer de traverser plusieurs composants serveur avant d'identifier finalement le composant marqué `use client`. Ce chemin tortueux brouille la distinction cruciale entre les préoccupations du serveur et du client, entravant la maintenabilité.

Au-delà de la navigation, ce modèle implique intrinsèquement qu'un composant serveur *contrôle* un composant client. Si un composant serveur rend conditionnellement un composant client, le serveur dicte effectivement quand et comment cette interactivité côté client apparaît. Ce paradigme peut sembler contre-intuitif lorsque l'objectif principal est de décharger entièrement l'interactivité et ses frais généraux associés vers le client, et non de gérer sa présence depuis le serveur.

TanStack envisage une approche différente, une approche qui remet fondamentalement en question ce mandat axé sur le serveur concernant l'interactivité client. Il pose une question cruciale qui change le paradigme : Et si le serveur n'avait pas du tout besoin de décider de chaque partie de l'interface utilisateur façonnée par le client ? Cette redéfinition radicale de l'interaction serveur-client promet une architecture plus explicite, gérable et, en fin de compte, plus intuitive pour les applications React modernes.

TanStack introduit les Composite Components, une solution novatrice qui aborde les complexités inhérentes à la composition client-serveur dans React. Alors que la directive familière `use client` offre une échappatoire nécessaire pour intégrer des éléments interactifs dans les Server Components, les limites `use client` profondément imbriquées conduisent souvent à un modèle mental alambiqué, brouillant la ligne claire entre l'exécution côté serveur et côté client et rendant la propriété des composants difficile. L'approche de TanStack offre une séparation radicalement plus nette.

Au lieu qu'un Server Component tente de rendre directement un Client Component—un modèle qui échoue car les environnements serveur ne peuvent pas exécuter les hooks côté client—les Composite Components inversent cette relation. Ici, le Server Component définit explicitement un "slot" ou un espace réservé conceptuel. Ce slot, souvent représenté par des props `children` standard ou des render props nommées spécifiquement, indique précisément où le contenu interactif côté client *sera* placé. Le serveur dicte la structure statique et les données, laissant explicitement des zones désignées pour l'interactivité client.

Les développeurs implémentent ce puissant modèle en utilisant l'aide `createCompositeComponent`, exécutée sur le serveur. Cette fonction prend un composant rendu côté serveur et définit ses slots côté client attendus, en spécifiant leurs types. L'aide construit ensuite une "source composite"—une charge utile légère, déclarative et sérialisable. Le serveur transmet cette "source composite" au client, décrivant efficacement la structure rendue par le serveur et ses zones interactives désignées.

Côté client, le wrapper spécial `<CompositeComponent>` reçoit cette "source composite". Le code côté client rend ensuite le composant récupéré du serveur *à travers* ce wrapper, permettant au rendu statique du serveur de s'afficher. De manière cruciale, tout Client Component interactif est passé *dans* le slot défini du `<CompositeComponent>`, plutôt que d'être imbriqué directement dans le JSX du composant serveur. Cela garantit que le composant client s'exécute dans son environnement approprié, conservant la propriété de son interactivité.

Ce modèle explicite, basé sur des slots, élimine l'ambiguïté "où ce composant s'exécute-t-il ?" qui afflige souvent les arborescences profondes de `use client`. Il renforce la philosophie client-first centrale à TanStack Start, permettant aux développeurs d'intégrer les Server Components aussi finement que de récupérer du JSON sans sacrifier la clarté. Pour une compréhension plus approfondie du rendu côté serveur de React, consultez Server Components - React. Les Composite Components assurent un flux clair et unidirectionnel, le client contrôlant ses éléments interactifs, même lors de l'intégration de structures fournies par le serveur.

Les Composite Components remodèlent fondamentalement l'architecture de React, inversant le flux de contrôle conventionnel établi par des frameworks comme Next.js. Cette approche novatrice inverse entièrement le script : le code client dicte désormais où résident les éléments interactifs, plutôt que le serveur ne dicte où les composants clients peuvent être placés. Au lieu de cela, les composants serveur fournissent des "slots" bien définis, agissant comme des modèles flexibles pour le contenu côté client.

Ce changement de paradigme rétablit une séparation des préoccupations vitale. Le code serveur peut se concentrer purement sur la récupération de données, la logique métier et le rendu d'interfaces utilisateur statiques ou dépendantes du serveur. Il fournit l'ossature structurelle et le contenu initial, offrant efficacement une base performante. Le code client, à l'inverse, prend entièrement en charge l'interactivité, la gestion de l'état et les éléments d'interface utilisateur dynamiques, remplissant les slots désignés par le serveur.

Les développeurs obtiennent un modèle puissant et explicite pour définir la frontière client-serveur. Les composants clients, tels que l'exemple de compteur souvent utilisé pour démontrer l'interactivité, ne nécessitent plus la directive souvent déroutante `'use client'` lorsqu'ils sont intégrés via des Composite Components. Leur contexte est intrinsèquement côté client, rendant leur nature interactive évidente et éliminant le code passe-partout.

La vision de TanStack, telle que décrite dans leur Announcement, traite les Server Components comme une primitive puissante à laquelle opter, et non comme une valeur par défaut. Cette philosophie client-first transparaît à travers les Composite Components, permettant aux développeurs de construire des applications hybrides complexes avec une clarté sans précédent. Le client devient l'orchestrateur de sa propre expérience interactive, intégrant de manière transparente les segments rendus par le serveur.

Cette inversion architecturale évite le "désordre" des composants clients profondément imbriqués dans les arborescences de serveur, un point douloureux courant dans les modèles server-first. Elle offre un modèle mental plus intuitif, s'alignant sur le développement React traditionnel tout en tirant parti des avantages de performance du rendu côté serveur. Le contrat explicite entre les slots serveur et les remplisseurs client clarifie l'intention et simplifie le débogage.

En donnant au code client le contrôle sur son domaine interactif, TanStack Start offre une voie radicalement différente et plus conviviale pour les développeurs pour l'intégration des Server Components. Cette approche promet un avenir où les capacités serveur de React augmentent, plutôt que de dicter, l'expérience client.

Au-delà de la prop `children` de base, qui offre un simple point d'injection de contenu, les TanStack Server Components débloquent des modèles de composition significativement plus sophistiqués. Ces « slots » avancés permettent aux développeurs de concevoir des composants serveur qui façonnent dynamiquement l'expérience de rendu côté client, en transmettant des données calculées par le serveur directement dans des composants client imbriqués. Cette capacité va bien au-delà du contenu statique, permettant une véritable collaboration client-serveur au sein de l'arbre de composants.

Un modèle puissant implique les Render Props. Ici, un composant serveur définit une prop qui accepte explicitement une fonction comme valeur. Lorsque le composant serveur se rend, il invoque cette fonction, transmettant des données calculées par le serveur — comme un `postID` ou un `authorID` — comme arguments. Le composant client fourni à ce slot reçoit et utilise ensuite ces données provenant du serveur, permettant une génération d'interface utilisateur client hautement dynamique et pilotée par les données à partir d'un parent rendu par le serveur.

Une alternative plus simple, souvent plus ergonomique, apparaît via les Component Props. Au lieu d'une fonction, le composant client lui-même est passé directement comme prop au composant serveur. Le composant serveur, pré-configuré avec la connaissance de la forme de données attendue, injecte alors intelligemment les props de données côté serveur pertinentes directement dans ce composant client. Cela réduit le code répétitif, simplifiant le processus de composition de la logique client avec le contexte fourni par le serveur.

Une nuance architecturale critique de ces slots dynamiques est leur nature opaque pour le serveur. Le composant serveur comprend qu'il doit fournir des données spécifiques à un slot donné ; il n'a cependant aucune connaissance inhérente du composant client réel qui y sera finalement rendu. Cette stricte séparation des préoccupations assure une flexibilité maximale, permettant aux développeurs client de remplacer les implémentations d'interface utilisateur sans nécessiter de modifications du composant côté serveur fournissant les données.

Ces mécanismes de slot avancés redéfinissent fondamentalement la manière dont les composants client et serveur interagissent. Ils fournissent un contrat précis pour le flux de données, permettant aux composants serveur d'orchestrer la charge utile de données initiale pour les éléments client interactifs sans jamais avoir besoin de comprendre ou de gérer leur état interne ou leur logique de rendu. Cette approche explicite, axée sur les données, consolide la philosophie « client-first » de TanStack, offrant une solution robuste pour les architectures d'applications complexes.

Les avantages en termes de performance vont bien au-delà de l'expérience développeur avec l'approche de TanStack en matière de Server Components. En traitant les RSCs comme des flux de données granulaires et récupérables, ils s'intègrent de manière transparente aux outils côté client établis, débloquant des gains significatifs en vitesse et en efficacité. Ce modèle aborde directement les goulots d'étranglement de performance courants dans les applications web modernes.

De manière cruciale, cette architecture permet des stratégies robustes de mise en cache côté client. TanStack Query, une pierre angulaire de l'écosystème, peut désormais gérer ces composants rendus par le serveur comme n'importe quelle autre donnée. Les développeurs bénéficient de primitives puissantes pour la récupération, l'invalidation et le préchargement des données, garantissant que les composants sont toujours à jour et disponibles avec un minimum de surcharge réseau. Cela améliore considérablement les temps de chargement perçus et la réactivité.

Des gains de performance substantiels proviennent de la réduction des charges utiles JavaScript. Les dépendances lourdes, telles que les `Markdown parsers` ou les `syntax highlighters`, s'exécutent entièrement sur le serveur, n'atteignant jamais le bundle du navigateur client. Cela se traduit par des pages plus petites et plus rapides à charger qui consomment moins de bande passante et traitent moins de scripts sur l'appareil de l'utilisateur.

De plus, TanStack Start utilise le progressive streaming, envoyant l'UI au navigateur au fur et à mesure qu'elle est rendue sur le serveur. Les utilisateurs bénéficient de temps de chargement perçus plus rapides, car le contenu apparaît de manière incrémentielle, plutôt que d'attendre l'hydratation d'une page entière. Ce feedback immédiat améliore considérablement la satisfaction et l'engagement des utilisateurs.

Une sécurité renforcée représente un autre avantage clé. Les données sensibles, y compris les API keys et les requêtes directes à la base de données, restent sécurisées sur le serveur, n'étant jamais exposées au client. Cette protection architecturale minimise les surfaces d'attaque et protège les opérations backend critiques contre l'inspection ou la manipulation côté client, une amélioration significative par rapport aux applications traditionnelles fortement axées sur le client.

La flexibilité de la stack sous-jacente de TanStack amplifie encore ces avantages. Construites sur des primitives puissantes comme Vite et Nitro, les applications peuvent être déployées sur un large éventail de fournisseurs d'hébergement, des fonctions serverless aux environnements Node.js traditionnels. Cette adaptabilité garantit que les développeurs peuvent choisir l'infrastructure la mieux adaptée à leurs besoins de performance et de scaling. Pour une exploration plus approfondie des capacités du framework, consultez le TanStack Start Overview | TanStack Start React Docs. Cette approche complète consolide la position de TanStack en tant qu'alternative puissante pour la construction d'applications React performantes et sécurisées.

TanStack a apporté une réponse profonde au dilemme des Server Components de la communauté React. Son implémentation offre la puissance brute des Server Components – récupération de données côté serveur, tailles de bundle client réduites, sécurité renforcée et performances de chargement initial améliorées – sans l'approche dogmatique et tout-ou-rien popularisée par Next.js. Les développeurs peuvent désormais adopter le rendu et la logique côté serveur comme une fonctionnalité opt-in, l'intégrant aussi granulairement que la récupération de JSON, plutôt que d'être contraints à un paradigme par défaut « server-first » pour l'ensemble de leur application.

Ceci positionne TanStack Start non pas simplement comme une alternative, mais comme une vision convaincante pour l'avenir du développement React. Il s'adresse directement aux ingénieurs qui privilégient un contrôle explicite, des modèles mentaux clairs et un framework qui s'adapte aux besoins spécifiques de leur projet, et non l'inverse. En rétablissant une philosophie « client-first », TanStack Start permet aux server components d'augmenter, plutôt que de dicter, l'architecture des applications, offrant une séparation des préoccupations plus nette et réduisant la charge cognitive.

La question de savoir si TanStack Start est un « Next.js killer » est souvent hyperbolique dans le monde de la tech, pourtant TanStack a indéniablement abordé les principaux points douloureux du paysage actuel des RSC. La fonction explicite `renderServerComponent` et les Composite Components offrent une frontière considérablement plus claire entre la logique client et serveur. En offrant une solution rafraîchissante, pragmatique et puissante, qui respecte l'autonomie des développeurs et privilégie la clarté, TanStack Start pourrait en effet gagner les cœurs et les esprits de la communauté React. Il déplace la conversation au-delà des paradigmes forcés, offrant une approche véritablement adaptable et centrée sur le développeur pour les applications web modernes, que beaucoup attendaient.

Quelle est la principale différence entre les Server Components de TanStack et de Next.js ?

TanStack utilise un modèle « client-first », vous permettant d'opter pour les Server Components de manière granulaire. Next.js utilise un modèle « server-first » où les composants sont rendus côté serveur par défaut, nécessitant une directive « use client » pour l'interactivité.

Que sont les Composite Components dans TanStack Start ?

C'est un modèle puissant qui permet aux Server Components de définir des 'slots' (comme des children ou des props) qui sont remplis par des Client Components. Cela maintient la frontière client/serveur claire, car le Server Component n'a pas besoin de connaître les Client Components spécifiques qu'il contiendra.

Le 'use client' est-il nécessaire dans les TanStack Server Components ?

Bien que TanStack prenne en charge la directive 'use client' par souci de familiarité, ce n'est pas l'approche recommandée. Le framework encourage l'utilisation de Composite Components pour éviter la dépendance complexe des Server Components qui rendent et contrôlent directement les Client Components.

Comment TanStack gère-t-il la logique côté serveur avec les RSCs ?

Il utilise des fonctions serveur explicites, souvent en enveloppant l'aide 'renderServerComponent'. Cela rend sans ambiguïté le fait que la logique s'exécute sur le serveur, offrant une expérience développeur claire et prévisible.