TanStack Acabou de Corrigir a Pior Ideia do React

Os Server Components (RSCs) do React acenderam uma guerra civil entre os desenvolvedores. Introduzidos como uma primitiva potente, a sua implementação generalizada tornou-se, em vez disso, uma fonte de intensa frustração, desencadeando debates onde o sentimento "principalmente ódio hoje em dia" muitas vezes prevalece. Muitos veem os RSCs não como uma melhoria, mas como uma imposição complexa.

O Next.js, o framework dominante que utiliza RSCs, ditou em grande parte este paradigma controverso. A sua abordagem server-first forçou os desenvolvedores a um modelo onde o servidor "possui a árvore", e a diretiva `use client` tornou-se uma saída de emergência necessária para a interatividade. Este design transformou os RSCs de uma "primitiva útil numa coisa em torno da qual toda a sua aplicação tem de orbitar", como destacado num Anúncio recente.

Agora, um novo concorrente entrou no jogo, prometendo mudar fundamentalmente esta narrativa. O TanStack Start acaba de lançar a sua própria implementação de Server Components, adotando uma abordagem radicalmente diferente que poderá finalmente conquistar os céticos. Este framework desafia a noção de que os desenvolvedores devem comprometer-se totalmente com uma arquitetura server-first para beneficiar dos RSCs.

Em vez de adotar um modelo centrado no servidor por padrão, o TanStack Start defende uma filosofia client-first. Ele permite que os desenvolvedores optem por componentes de servidor com uma granularidade sem precedentes, tratando-os "tão granularmente quanto se poderia buscar JSON no cliente." Isso significa integrar renderização e lógica do lado do servidor apenas onde isso proporciona valor claro, sem reestruturar uma aplicação inteira.

Esta estratégia deliberada e opt-in visa desmistificar os React Server Components e desbloquear o seu potencial sem a complexidade associada. Ao oferecer um caminho que respeita os padrões de desenvolvimento client-side existentes, o TanStack Start poderá redefinir a conversa em torno dos RSCs, transformando o ceticismo generalizado em entusiasmo genuíno. O framework oferece uma alternativa convincente ao paradigma server-first predominante e muitas vezes malvisto.

A recente introdução de Server Components pelo TanStack Start redefine radicalmente a sua integração em aplicações React. Em vez de forçar uma mudança de paradigma, a TanStack defende uma filosofia client-first, permitindo que os desenvolvedores optem por capacidades de servidor com precisão cirúrgica. Esta abordagem contrasta fortemente com o modelo "server-first" popularizado pelo Next.js, onde cada componente é por padrão um componente de servidor, a menos que seja explicitamente marcado com uma diretiva `'use client'`.

O Next.js enquadra os Server Components como o proprietário padrão da árvore de componentes, com segmentos `'use client'` denotando ilhas interativas do lado do cliente. Esta arquitetura muitas vezes obriga os desenvolvedores a reestruturar aplicações inteiras em torno da renderização server-side, mesmo quando apenas pequenas partes beneficiam dela. A TanStack rejeita esta proposta de tudo ou nada, afirmando que os desenvolvedores não deveriam "ter de aderir a todo esse modelo de antemão apenas para obter valor dos React server components."

A visão da TanStack trata os Server Components como uma primitiva poderosa, utilizável "tão granularmente quanto se poderia buscar JSON no cliente." Isso significa que os desenvolvedores podem introduzir seletivamente lógica e renderização server-side precisamente onde oferece vantagens tangíveis, como a redução do tamanho dos bundles do cliente ou o tratamento seguro de dados sensíveis. O framework facilita isso através de funções de servidor e da API renderServerComponent.

Considere um cenário onde um componente cliente precisa de dados apenas do servidor, como um hostname do sistema operacional ou variáveis de ambiente. TanStack Start permite que os desenvolvedores encapsulem essa lógica dentro de uma server function, que então retorna um server component renderizável via `renderServerComponent`. Este componente pode então ser buscado e integrado em um route loader do lado do cliente, assim como qualquer outro dado.

Este mecanismo explícito e opt-in mantém o controle firmemente nas mãos do desenvolvedor. Ele permite que as equipes aproveitem o poder do servidor para tarefas específicas sem alterar fundamentalmente seu modelo mental estabelecido do React. O objetivo é aumentar, não reformular, a experiência tradicional de desenvolvimento React do lado do cliente, garantindo que as capacidades do servidor aprimorem em vez de ditar a arquitetura da aplicação.

Construir seu primeiro TanStack Server Component revela um fluxo de trabalho explicitamente refrescante. Para começar, defina um componente React simples, como um `Greeting` que requer dados do lado do servidor, como o hostname do sistema operacional. Tentar acessar APIs do Node.js como `os.hostname()` diretamente em um componente cliente padrão falhará, pois essas funções não estão disponíveis no ambiente do navegador.

TanStack introduz server functions para encapsular a lógica do lado do servidor. Considere uma função `getGreeting`, que se torna sua porta de entrada para código executado no servidor. Dentro desta server function, você invoca a primitiva `renderServerComponent`, envolvendo seu componente `Greeting`. Esta função crucial prepara o componente para a renderização no servidor, transformando-o efetivamente em uma unidade autocontida e renderizável.

```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} />); } ```

Em seguida, integre este componente renderizado no servidor ao fluxo de dados da sua aplicação. Dentro de um route loader, que é executado puramente no servidor, você simplesmente `await getGreeting()`. Isso busca o componente pré-renderizado da sua server function, assim como faria com qualquer outro dado. O loader então retorna este componente, pronto para consumo.

```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> ); }, }); ```

No cliente, use `useLoaderData` para recuperar o server component. Você pode então renderizá-lo diretamente no seu JSX, exatamente como um componente cliente regular. Esta integração perfeita destaca a filosofia client-first da TanStack; os Server Components funcionam como outro tipo de dado que você busca e exibe, não uma arquitetura padrão. Para uma compreensão mais ampla dos conceitos de server component, incluindo a abordagem server-first, explore Getting Started: Server and Client Components - Next.js.

O poder desta abordagem torna-se imediatamente aparente. Dentro da sua função de servidor `getGreeting`, pode aceder com confiança a recursos apenas de servidor. Imagine buscar `os.hostname()` ou ler com segurança variáveis de ambiente indisponíveis para o cliente. Estas operações são executadas puramente no servidor, com apenas o HTML renderizado entregue ao navegador, melhorando tanto a segurança quanto o desempenho. Esta separação explícita deixa claro exatamente onde o seu código é executado, um contraste marcante com os modelos implícitos 'server-first'.

Este método simplifica radicalmente o modelo mental para os desenvolvedores. A sua aplicação React permanece centrada no cliente por padrão, permitindo que opte por capacidades de servidor de forma granular. Os desenvolvedores obtêm os benefícios de tamanhos de bundle reduzidos e acesso direto a recursos de backend sem a sobrecarga cognitiva de um paradigma forçado pelo servidor. A implementação parece intuitiva, tratando os componentes de servidor como uma funcionalidade poderosa e opcional, em vez de uma restrição abrangente na arquitetura de toda a sua aplicação.

Os benefícios para a experiência do desenvolvedor do modelo explícito da TanStack são imediatos e profundos, eliminando a ambiguidade comum dos React Server Components. O código destinado ao servidor é executado inequivocamente dentro de uma função de servidor dedicada, removendo qualquer dúvida sobre o seu ambiente de execução. Esta demarcação clara, muitas vezes utilizando o wrapper `renderServerComponent`, garante que os desenvolvedores saibam instantaneamente onde a lógica específica, ligada ao servidor — como buscar `os.hostname()` ou aceder a variáveis de ambiente sensíveis apenas de servidor — será executada. Esta clareza elimina a sobrecarga mental de inferir contextos de execução, fornecendo uma clareza essencial desde a primeira linha de código.

Este design explícito melhora radicalmente a reutilização e a manutenibilidade dos componentes numa aplicação. Um componente React em si pode permanecer "burro", totalmente alheio se é renderizado no cliente ou no servidor. Toda a lógica do lado do servidor, busca de dados e processamento são encapsulados de forma limpa dentro das funções de servidor e depois passados para o componente através de props padrão. Este padrão poderoso desacopla efetivamente a lógica de renderização do componente da sua origem de dados, tornando os componentes inerentemente mais portáteis, testáveis e adaptáveis em vários contextos de aplicação sem exigir modificações internas para a consciência do servidor.

Contraste isso com o potencial de confusão inerente ao Next.js, onde o modelo padrão "server-first" muitas vezes borra a fronteira cliente/servidor. Sem um wrapper explícito de função de servidor, os desenvolvedores devem depender fortemente da diretiva `use client` e, muitas vezes, de convenções sutis do framework para inferir contextos de execução. Isso pode levar a erros de tempo de execução inesperados, inchaço desnecessário do bundle do lado do cliente a partir de código apenas de servidor e uma compreensão fragmentada do comportamento do componente. A abordagem client-first da TanStack, tratando os Server Components como uma funcionalidade opcional, tão granularmente quanto buscar JSON, promove um modelo mental intuitivo onde a lógica do servidor é invocada propositadamente, não implicitamente assumida ou acidentalmente acionada pelo posicionamento do componente.

TanStack Start mantém suporte explícito para a diretiva `use client`, garantindo compatibilidade e fornecendo uma saída familiar para desenvolvedores em transição de outros frameworks. Colocar esta diretiva no topo de um arquivo marca inequivocamente um componente e toda a sua subárvore como do lado do cliente, permitindo total interatividade, incluindo gerenciamento de estado local via `useState` e manipulação de eventos DOM.

No entanto, depender extensivamente de `use client` para incorporar componentes interativos dentro de uma árvore de componentes predominantemente de servidor apresenta desafios arquitetónicos consideráveis, particularmente evidentes no modelo Next.js. Lá, um componente de servidor frequentemente assume a responsabilidade direta pela renderização e orquestração da presença de componentes de cliente, criando uma hierarquia implícita onde a lógica do servidor dita a interatividade do cliente.

Esta propriedade direta de componente de servidor para cliente cultiva uma árvore de dependências confusa. Um componente de servidor, fundamentalmente projetado para entrega de conteúdo estático e busca de dados, torna-se diretamente responsável pela renderização, fluxo de controle e até mesmo pela existência de seus filhos interativos do lado do cliente. Este acoplamento apertado torna o rastreamento dos ciclos de vida dos componentes e a compreensão do fluxo de dados explícito através do limite servidor/cliente desnecessariamente difícil.

Navegar nesta lógica interligada diminui rapidamente a produtividade do desenvolvedor e torna o raciocínio sobre as responsabilidades dos componentes opaco. Por exemplo, diagnosticar um problema com um `CounterButton` interativo pode envolver a travessia de múltiplos componentes de servidor antes de finalmente identificar o componente marcado com `use client`. Este caminho convoluto obscurece a distinção crucial entre as preocupações do servidor e do cliente, dificultando a manutenção.

Além da navegação, este modelo implica inerentemente que um componente de servidor *controla* um componente de cliente. Se um componente de servidor renderiza condicionalmente um componente de cliente, o servidor efetivamente dita quando e como essa interatividade do lado do cliente aparece. Este paradigma pode parecer contraintuitivo quando o objetivo principal é descarregar a interatividade e sua sobrecarga associada inteiramente para o cliente, e não gerenciar sua presença a partir do servidor.

TanStack vislumbra uma abordagem diferente, uma que questiona fundamentalmente este mandato impulsionado pelo servidor sobre a interatividade do cliente. Faz uma pergunta crucial e que muda o paradigma: E se o servidor não precisasse decidir cada parte da UI moldada pelo cliente? Esta redefinição radical da interação servidor-cliente promete uma arquitetura mais explícita, gerenciável e, em última análise, mais intuitiva para aplicações React modernas.

TanStack introduz os Composite Components, uma solução inovadora que aborda as complexidades inerentes da composição cliente-servidor no React. Embora a diretiva familiar `use client` forneça uma saída necessária para integrar elementos interativos em Server Components, limites `use client` profundamente aninhados frequentemente levam a um modelo mental convoluto, obscurecendo a linha clara entre a execução do servidor e do cliente e dificultando a propriedade do componente. A abordagem da TanStack oferece uma separação radicalmente mais limpa.

Em vez de um Server Component tentar renderizar um Client Component diretamente — um padrão que falha porque os ambientes de servidor não podem executar hooks do lado do cliente — os Composite Components invertem essa relação. Aqui, o Server Component define explicitamente um "slot" ou placeholder conceptual. Este slot, frequentemente representado por `children` props padrão ou render props especificamente nomeadas, indica precisamente onde o conteúdo interativo do lado do cliente *será* colocado. O servidor dita a estrutura estática e os dados, deixando explicitamente áreas designadas para a interatividade do cliente.

Os desenvolvedores implementam este padrão poderoso usando o helper `createCompositeComponent`, executado no servidor. Esta função recebe um componente renderizado no servidor e define seus slots esperados do lado do cliente, especificando seus tipos. O helper então constrói uma "composite source" — um payload leve, declarativo e serializável. O servidor transmite esta "composite source" para o cliente, delineando efetivamente a estrutura renderizada do servidor e suas áreas interativas designadas.

No cliente, o wrapper especial `<CompositeComponent>` recebe esta "fonte composta". O código do lado do cliente então renderiza o componente obtido do servidor *através* deste wrapper, permitindo que a saída estática do servidor seja renderizada. Crucialmente, qualquer Client Component interativo é passado *para* o slot definido do `<CompositeComponent>`, em vez de ser aninhado diretamente dentro do JSX do componente do servidor. Isso garante que o componente do cliente seja executado em seu ambiente adequado, mantendo a propriedade de sua interatividade.

Este modelo explícito, baseado em slots, elimina a ambiguidade "onde este componente está sendo executado?" que frequentemente assola árvores profundas de `use client`. Ele reforça a filosofia client-first central ao TanStack Start, permitindo que os desenvolvedores integrem Server Components tão granularmente quanto a obtenção de JSON sem sacrificar a clareza. Para uma compreensão mais aprofundada da renderização server-side do React, consulte Server Components - React. Composite Components garantem um fluxo claro e unidirecional, com o cliente controlando suas partes interativas, mesmo ao integrar estruturas fornecidas pelo servidor.

Composite Components remodelam fundamentalmente a arquitetura do React, invertendo o fluxo de controle convencional estabelecido por frameworks como Next.js. Esta nova abordagem inverte completamente o roteiro: o código do cliente agora dita onde os elementos interativos residem, em vez de o servidor ditar onde os componentes do cliente podem ser colocados. Em vez disso, os componentes do servidor fornecem "slots" bem definidos, atuando como modelos flexíveis para conteúdo do lado do cliente.

Esta mudança de paradigma restabelece uma vital separação de preocupações. O código do servidor pode focar puramente na obtenção de dados, lógica de negócios e renderização de UI estática ou dependente do servidor. Ele fornece a espinha dorsal estrutural e o conteúdo inicial, entregando eficientemente uma base de desempenho. O código do cliente, por outro lado, assume total propriedade da interatividade, gerenciamento de estado e elementos de UI dinâmicos, preenchendo os slots designados do servidor.

Os desenvolvedores ganham um modelo poderoso e explícito para definir o limite cliente-servidor. Componentes do cliente, como o exemplo de contador frequentemente usado para demonstrar interatividade, não exigem mais a diretiva `'use client'`, muitas vezes confusa, quando integrados via Composite Components. Seu contexto é inerentemente do lado do cliente, tornando sua natureza interativa autoevidente e eliminando o boilerplate.

A visão da TanStack, conforme delineada em seu Announcement, trata os Server Components como uma primitiva poderosa para optar, não como um padrão. Esta filosofia client-first brilha através dos Composite Components, capacitando os desenvolvedores a construir aplicações híbridas complexas com clareza sem precedentes. O cliente se torna o orquestrador de sua própria experiência interativa, integrando perfeitamente segmentos renderizados pelo servidor.

Esta inversão arquitetônica evita a "bagunça" de componentes de cliente profundamente aninhados dentro de árvores de servidor, um ponto problemático comum em modelos server-first. Ela oferece um modelo mental mais intuitivo, alinhando-se com o desenvolvimento tradicional do React enquanto aproveita os benefícios de desempenho da renderização do servidor. O contrato explícito entre slots do servidor e preenchimentos do cliente esclarece a intenção e simplifica a depuração.

Ao dar ao código do cliente controle sobre seu domínio interativo, o TanStack Start oferece um caminho radicalmente diferente e mais amigável ao desenvolvedor para integrar Server Components. Esta abordagem promete um futuro onde as capacidades de servidor do React aumentam, em vez de ditar, a experiência do cliente.

Além da prop básica `children`, que oferece um ponto simples de injeção de conteúdo, os TanStack Server Components desbloqueiam padrões de composição significativamente mais sofisticados. Esses "slots" avançados capacitam os desenvolvedores a projetar componentes de servidor que moldam dinamicamente a experiência de renderização do lado do cliente, passando dados computados no servidor diretamente para componentes de cliente aninhados. Essa capacidade vai muito além do conteúdo estático, permitindo uma verdadeira colaboração cliente-servidor dentro da árvore de componentes.

Um padrão poderoso envolve Render Props. Aqui, um componente de servidor define uma prop que aceita explicitamente uma função como seu valor. Quando o componente de servidor é renderizado, ele invoca essa função, passando dados computados no servidor — como um `postID` ou `authorID` — como argumentos. O componente de cliente fornecido a este slot então recebe e utiliza esses dados originados no servidor, permitindo uma geração de UI de cliente altamente dinâmica e orientada a dados a partir de um pai renderizado no servidor.

Uma alternativa mais simples, e muitas vezes mais ergonômica, surge através de Component Props. Em vez de uma função, o próprio componente de cliente é passado diretamente como uma prop para o componente de servidor. O componente de servidor, pré-configurado com conhecimento da forma de dados esperada, então injeta inteligentemente props de dados relevantes do lado do servidor diretamente neste componente de cliente. Isso reduz o boilerplate, otimizando o processo de composição da lógica do cliente com o contexto fornecido pelo servidor.

Uma nuance arquitetônica crítica desses slots dinâmicos é sua natureza opaca para o servidor. O componente de servidor entende que precisa fornecer dados específicos para um determinado slot; ele não tem conhecimento inerente, no entanto, do componente de cliente real que será renderizado ali. Essa estrita separação de preocupações garante máxima flexibilidade, permitindo que os desenvolvedores de cliente troquem implementações de UI sem exigir quaisquer alterações no componente do lado do servidor que fornece os dados.

Esses mecanismos de slot avançados redefinem fundamentalmente como os componentes de cliente e servidor interagem. Eles fornecem um contrato preciso para o fluxo de dados, permitindo que os componentes de servidor orquestrem a carga de dados inicial para elementos interativos do cliente sem nunca precisar entender ou gerenciar seu estado interno ou lógica de renderização. Essa abordagem explícita e orientada a dados solidifica a filosofia "client-first" da TanStack, entregando uma solução robusta para arquiteturas de aplicação complexas.

Os benefícios de desempenho se estendem muito além da experiência do desenvolvedor com a abordagem da TanStack para Server Components. Ao tratar os RSCs como fluxos de dados granulares e buscáveis, eles se integram perfeitamente com as ferramentas estabelecidas do lado do cliente, desbloqueando ganhos significativos em velocidade e eficiência. Este modelo aborda diretamente os gargalos de desempenho comuns em aplicações web modernas.

Crucialmente, esta arquitetura permite estratégias robustas de cache do lado do cliente. TanStack Query, uma pedra angular do ecossistema, agora pode gerenciar esses componentes renderizados no servidor como qualquer outro dado. Os desenvolvedores obtêm primitivas poderosas para busca de dados, invalidação e prefetching, garantindo que os componentes estejam sempre atualizados e disponíveis com sobrecarga mínima de rede. Isso melhora drasticamente os tempos de carregamento percebidos e a capacidade de resposta.

Ganhos substanciais de desempenho vêm da redução das cargas de JavaScript. Dependências pesadas, como parsers de Markdown ou syntax highlighters, são executadas inteiramente no servidor, nunca chegando ao bundle do navegador do cliente. Isso resulta em páginas menores e de carregamento mais rápido que consomem menos largura de banda e processam menos scripts no dispositivo do usuário.

Além disso, o TanStack Start aproveita o progressive streaming, enviando a UI para o navegador à medida que é renderizada no servidor. Os usuários experimentam tempos de carregamento percebidos mais rápidos, pois o conteúdo aparece incrementalmente, em vez de esperar que uma página inteira seja hidratada. Esse feedback imediato melhora significativamente a satisfação e o engajamento do usuário.

A segurança aprimorada representa outra vantagem fundamental. Dados sensíveis, incluindo API keys e consultas diretas ao banco de dados, permanecem seguros no servidor, nunca expostos ao cliente. Essa salvaguarda arquitetônica minimiza as superfícies de ataque e protege as operações críticas de backend contra inspeção ou manipulação do lado do cliente, uma melhoria significativa em relação às aplicações tradicionais pesadas no cliente.

A flexibilidade da stack subjacente do TanStack amplifica ainda mais esses benefícios. Construídas sobre primitivas poderosas como Vite e Nitro, as aplicações podem ser implantadas em uma vasta gama de provedores de hospedagem, desde serverless functions até ambientes tradicionais de Node.js. Essa adaptabilidade garante que os desenvolvedores possam escolher a infraestrutura mais adequada para suas necessidades de desempenho e escalabilidade. Para um mergulho mais profundo nas capacidades do framework, consulte o TanStack Start Overview | TanStack Start React Docs. Essa abordagem abrangente solidifica a posição do TanStack como uma alternativa potente para a construção de aplicações React de alto desempenho e seguras.

O TanStack entregou uma resposta profunda ao dilema dos Server Components da comunidade React. Sua implementação oferece o poder bruto dos Server Components – busca de dados no servidor, tamanhos de bundle do cliente reduzidos, segurança aprimorada e desempenho de carregamento inicial melhorado – sem a abordagem dogmática e tudo ou nada popularizada pelo Next.js. Os desenvolvedores agora podem adotar a renderização e lógica do lado do servidor como um recurso opt-in, integrando-o tão granularmente quanto buscar JSON, em vez de serem forçados a um paradigma padrão server-first para toda a sua aplicação.

Isso posiciona o TanStack Start não apenas como uma alternativa, mas como uma visão convincente para o futuro do desenvolvimento React. Ele atende diretamente a engenheiros que priorizam controle explícito, modelos mentais claros e um framework que se adapta às necessidades específicas de seus projetos, e não o contrário. Ao restabelecer uma filosofia client-first, o TanStack Start permite que os server components aumentem, em vez de ditar, a arquitetura da aplicação, oferecendo uma separação de preocupações mais limpa e reduzindo a carga cognitiva.

A questão de saber se o TanStack Start é um "Next.js killer" é frequentemente hiperbólica na tecnologia, mas o TanStack inegavelmente abordou os principais pontos problemáticos do cenário atual do RSC. A função explícita `renderServerComponent` e os Composite Components fornecem um limite dramaticamente mais claro entre a lógica do cliente e do servidor. Ao oferecer uma solução refrescantemente pragmática e poderosa, que respeita a autonomia do desenvolvedor e prioriza a clareza, o TanStack Start poderia de fato conquistar os corações e mentes da comunidade React. Ele move a conversa para além de paradigmas forçados, entregando uma abordagem verdadeiramente adaptável e centrada no desenvolvedor para aplicações web modernas que muitos desejavam.

Qual a principal diferença entre os Server Components do TanStack e do Next.js?

O TanStack usa um modelo 'client-first', permitindo que você opte por Server Components de forma granular. O Next.js usa um modelo 'server-first' onde os componentes são renderizados no servidor por padrão, exigindo uma diretiva 'use client' para interatividade.

O que são Composite Components no TanStack Start?

Eles são um padrão poderoso que permite que os server components definam 'slots' (como children ou props) que são preenchidos por client components. Isso mantém a fronteira cliente/servidor clara, pois o server component não precisa saber sobre os client components específicos que irá conter.

'use client' é necessário nos TanStack Server Components?

Embora o TanStack suporte a diretiva 'use client' para familiaridade, não é a abordagem recomendada. O framework incentiva o uso de Composite Components para evitar a dependência confusa de server components renderizando e controlando client components diretamente.

Como o TanStack lida com a lógica server-side com RSCs?

Ele usa funções de servidor explícitas, frequentemente envolvendo o helper 'renderServerComponent'. Isso torna inequívoco que a lógica está sendo executada no servidor, proporcionando uma experiência de desenvolvedor clara e previsível.