O que eu gostaria de ter sabido antes de migrar 50 mil linhas de código para React Server Components

• Artigo sobre as experiências e lições aprendidas pelo autor ao migrar 50.000 linhas de código para React Server Components (RSCs)
• RSCs são componentes React executados no servidor em vez do cliente e oferecem duas vantagens principais em relação ao server-side rendering (SSR)
  • Primeiro, os RSCs permitem que desenvolvedores definam onde o código é executado, reduzindo o tamanho do bundle e o trabalho durante a hidratação
  • Segundo, componentes de servidor tornam a busca de dados no React mais simples e eficiente ao buscar dados diretamente dentro do componente e transmiti-los por streaming ao cliente
• No entanto, há algumas limitações no uso de RSCs. CSS-in-JS não funciona em componentes de servidor, React Context só pode ser acessado em componentes de cliente, e a complexidade de gerenciar onde o código é executado pode ser desafiadora
• O autor propõe uma abordagem em 3 etapas para adotar RSCs gradualmente:
  • Adicionar a diretiva "use client" na raiz do app
  • Mover a diretiva para o ponto mais baixo possível na árvore de renderização
  • Adotar padrões avançados quando surgirem problemas de desempenho
• Apesar da complexidade adicional, o autor conclui que os benefícios dos RSCs, como bundles menores, execução mais rápida e padrões avançados de carregamento de dados, podem superar os custos quando as vantagens de desempenho forem valiosas para a equipe

[GN⁺]

Comentários do Hacker News

• O artigo discute a migração de 50 mil linhas de código para React Server Components (RSCs).
• Alguns usuários mencionaram a velocidade e a simplicidade da renderização no lado do servidor, destacando que o cliente recebe HTML que pode visualizar imediatamente.
• Há sugestões de que considerar frameworks full-stack ou web clássicos, como Rails, Django e Laravel, pode ser uma solução mais rápida e escalável do que usar RSCs.
• Alguns usuários expressaram preocupação com a complexidade dos frameworks modernos, mencionando pipelines extensos de build e compilação necessários até para tarefas simples.
• Os usuários compartilharam experiências pessoais com o next.js e sua nova configuração de diretório app, destacando a dificuldade de entender onde o trabalho acontece (no servidor ou no cliente) e problemas com bibliotecas React existentes que assumem funcionamento no lado do cliente.
• Alguns usuários apontaram bugs e arestas no novo paradigma de diretório app do next.js, incluindo problemas relacionados a rotas dinâmicas e rotas paralelas.
• Um usuário mencionou a semelhança entre PHP e JavaScript, observando que o JavaScript evoluiu para oferecer funcionalidades semelhantes no lado do servidor, embora com mais siglas e uma curva de aprendizado mais íngreme.
• Alguns usuários questionaram a necessidade de usar React para tarefas que poderiam ser resolvidas com ferramentas mais simples, como geradores de sites estáticos ou um CMS com cache.
• Há um sentimento de nostalgia pela época em que o servidor renderizava tudo e o CSS e o JavaScript apenas aprimoravam a página após a renderização.
• Alguns usuários expressaram a visão de que o React está se tornando mais complexo para acompanhar alternativas modernas que são mais fáceis e rápidas.
• Há debate sobre usar React no backend para renderizar HTML, com alguns usuários questionando essa necessidade e outros defendendo vantagens em relação aos métodos tradicionais de retorno do servidor.