RSC para desenvolvedores Astro

 (overreacted.io)
2 pontos por GN⁺ 2025-05-10 | 3 comentários | Compartilhar no WhatsApp
  • Astro e React Server Components (RSC) implementam de forma semelhante a separação entre código de servidor e de cliente
  • No Astro, Astro Component e Client Island dividem entre si seus papéis funcionais
  • O RSC separa o mesmo conceito em Server Component e Client Component, definindo a fronteira com a diretiva 'use client'
  • Em comparação com o Astro, o RSC oferece mais flexibilidade para compor UIs interativas e compartilhar código
  • Ambos os modelos têm uma estrutura em que os dados fluem em mão única do servidor para o cliente

Introdução e conceitos básicos

  • O Astro oferece dois tipos principais de componente: Astro Component e Client Island
  • Astro Component usa a extensão .astro, roda apenas no servidor ou em tempo de build, e pode fazer coisas que o cliente não consegue, como acessar o sistema de arquivos, consultar banco de dados e chamar serviços internos
  • Client Island é um componente para React, Vue etc., executado no navegador e responsável pela parte de interação com o usuário
  • É possível renderizar um Client Island dentro de um Astro Component, mas não é possível chamar um Astro Component a partir de um Client Island
  • Essa estrutura garante a unidirecionalidade, em que os dados sempre fluem apenas do servidor para o cliente

Exemplo de código e separação de papéis

  • No código de exemplo, PostPreview.astro lê um arquivo no servidor e obtém o título, depois repassa esses dados para o Client Island
  • LikeButton, escrito em React, passa a cuidar de mudanças de estado e eventos de clique do usuário depois que o navegador é carregado
  • Astro Component e Client Island operam em mundos diferentes, e a passagem de dados também acontece apenas de cima para baixo a partir do Astro Component

Comparação com React Server Components (RSC)

  • No RSC, assim como no Astro, há uma separação entre Server Component e Client Component
  • Em React Server Components, os componentes de servidor são declarados como funções JavaScript, e a diretiva 'use client' marca claramente onde o código de cliente começa
  • No RSC, o mesmo arquivo de componente pode atuar tanto no servidor quanto no cliente; diferente do Astro, não é preciso separar por extensão de arquivo ou por estrutura distinta, e a fronteira pode ser movida conforme a necessidade apenas declarando 'use client'
  • Se um componente usar recursos exclusivos do cliente (como useState) ou exclusivos do servidor (como acesso a DB), ocorre um erro de build quando ele é usado no ambiente errado, oferecendo um feedback claro

Diferenças visuais e estruturais entre Astro e RSC

  • O Astro tem uma fronteira clara ao separar arquivos .astro de arquivos JS/TS
  • No RSC, como tudo é React por padrão, a capacidade de compartilhar código e a flexibilidade são muito maiores
  • Por exemplo, componentes neutros que não usam estado nem recursos de servidor, como um parser de Markdown, podem ser usados em qualquer um dos lados
  • No RSC, o caminho de import determina automaticamente em qual mundo aquele componente vai rodar

Vantagens e limitações do modelo RSC

  • O principal benefício do RSC está na reutilização de código e na flexibilidade para mover responsabilidades
    • Qualquer componente pode atravessar a fronteira com facilidade quando necessário, bastando declarar 'use client'
    • No Astro, quando a UI muda de estática para dinâmica ou vice-versa, a adaptação do código pode ser trabalhosa; no RSC, isso é resolvido de forma simples
  • A desvantagem do RSC é a curva de aprendizado mais alta
    • O desenvolvedor precisa pensar o tempo todo em “em qual mundo está”, mas erros geram feedback rápido por meio do build
  • No Astro, conforme aumentam as partes dinâmicas da UI, a estrutura tende a ficar mais complexa; no RSC, toda a árvore React é integrada, então estado e passagem de contexto (Context) acontecem de forma natural

Astro centrado em HTML e RSC centrado na árvore React

  • O resultado final do Astro é HTML; a cada navegação, a página é totalmente recarregada, então ele não oferece uma experiência SPA completa
  • O resultado do RSC é uma árvore React (inicialmente em HTML, e durante a navegação enviada como JSON etc.)
    • Isso permite combinar as vantagens de SPA e MPA
  • É possível fazer um refresh parcial, atualizando diretamente apenas parte da UI no servidor, o que também facilita receber dados dinâmicos e preservar o estado no cliente

Suporte a recursos avançados do React

  • Com uma estrutura de árvore mista entre servidor e cliente, recursos avançados do React (como <Suspense>, view transitions etc.) são integrados de forma natural
  • Também é possível gerenciar estados de carregamento tratados de forma declarativa no cliente, além de atrasos de fonte/imagem/JavaScript/estilo
  • Todos os recursos do React funcionam de ponta a ponta sem que a fronteira entre servidor e cliente interrompa esse fluxo

A posição de RSC e Astro

  • Astro é um framework completo, enquanto RSC está mais para um bloco de construção de frameworks ou um padrão
  • As implementações oficiais de RSC incluem Next.js App Router e Parcel RSC

Conclusão e recomendação

  • A experiência de desenvolvimento (DX) do RSC ainda é meio bruta, mas vale a pena aprender
  • Se você ainda não experimentou Astro, ele é recomendável, e pode ser uma porta de entrada mais suave para quem acha RSC difícil
  • Mesmo para quem só usou React no client-side, o Astro pode trazer experiências inesperadas de resolução de problemas

Leituras relacionadas

3 comentários

 
hakoiko 2025-05-13

No momento, estou refatorando um app React antigo para Astro.
No texto, enfatiza-se o "contexto unificado". É preciso saber que o "contexto unificado" ajuda a construir serviços rapidamente, mas um dia pode se tornar dívida técnica.
Do ponto de vista da manutenção de longo prazo do serviço, "acoplamento forte integrado" é pior do que o "acoplamento frouxo entre módulos independentes".
E o Astro é o framework mais flexível para isso.
 
GN⁺ 2025-05-10
Comentários do Hacker News
  • O único motivo para eu usar RSC em vez de Astro é poder compartilhar contexto entre as ilhas, fora isso não há nenhuma vantagem especial, e, como ponto menor, eu gostaria que este texto mencionasse e explicasse claramente o conceito de "code fence" do Astro, essa ideia define muito mais claramente a fronteira entre servidor e cliente do que o 'use client' do React
    • Na minha opinião, o code fence não representa de fato a fronteira, o código abaixo da fence também necessariamente roda no servidor, caso contrário não seria possível referenciar componentes Astro ali, pelo que entendo a fence apenas indica a distinção entre "binding vs template", não "servidor vs cliente"
    • Compartilhar contexto entre ilhas é algo realmente fácil no Astro, veja este link https://docs.astro.build/en/recipes/sharing-state-islands/
  • Astro é um framework web para sites centrados em conteúdo, https://github.com/withastro/astro
    • Quem usava Gatsby vai se lembrar para sempre do dia em que se livrou do frágil pipeline de processamento de imagens conectado via GraphQL, (estavam na frente do computador naquele momento), não tenho provas, mas é um fato científico que o net promoter score do Astro tem cinco noves
    • Astro é muito bom, há alguns anos virou minha escolha padrão para SSG, e agora estou considerando seriamente usar Astro também para criar apps, alguém aqui já usou Astro em app?, estou pensando em usar Astro só para renderizar HTML baseado em ilhas e deixar o backend em non-JS
    • "Um framework web para sites centrados em conteúdo"? Então existem sites movidos não por conteúdo, mas por geradores de números aleatórios?
  • Eu realmente amo o Astro, uso desde o primeiro lançamento, fiz tanto meu site pessoal quanto a landing page do meu primeiro produto com Astro, o build é rápido, dá para fazer deploy sem JS e você pode usar qualquer biblioteca de frontend, então é o melhor framework na minha opinião