Highlight.io: monitoramento de aplicativos de código aberto para desenvolvedores
9 de abril de 2024
Usando RAG baseado em SQL para analisar melhor os dados do banco de dados com GenAI
10 de abril de 2024
Uau, tem havido muito barulho sobre os componentes do React Server (RSCs) ultimamente e, na maior parte, depois de ler todas as explicações realmente inteligentes das pessoas mais inteligentes da Internet, eu realmente não entendi nada. Mas desde então passei algum tempo experimentando o Waku e agora acho que os RSCs são muito mais simples do que pensei inicialmente.
O que é Waku?
Waku (wah-ku) ou わく significa “estrutura” em japonês. Como uma estrutura React mínima, ela foi projetada para acelerar o trabalho de desenvolvedores em startups e agências que criam projetos React de pequeno e médio porte. De acordo com o site Waku, isso inclui sites de marketing, comércio eletrônico leve e aplicativos da web.
O que falta na introdução do site, no entanto, é que o Waku suporta componentes do React Server – então, se você quiser experimentá-los por si mesmo, não precisa usar Next.js (pelo qual sou grato). Vale a pena mencionar que Waku está atualmente em rápido desenvolvimento e só deve ser usado em projetos que não sejam de produção.
Resumindo os componentes do servidor React
Então, aqui está minha opinião: os RSCs dão aos desenvolvedores do React acesso a assíncrono solicitações do lado do servidor e os dados resultantes, no nível do componente.
Antes dos RSCs, estruturas como Next.js, Gatsby, Remix e Astro exigiam que você fizesse solicitações do lado do servidor no nível da rota.
Aqui estão alguns exemplos de como você conseguiria isso em cada estrutura mencionada acima.
Rota Next.js (Roteador de aplicativo)
Dentro desta rota, existe uma função chamada getData que faz uma solicitação assíncrona à API do GitHub e retorna a resposta, que pode então ser extraída e disponibilizada para a rota ou página usando o getData função.
Veja o código no Gist.
Rota Next.js (roteador de páginas)
Dentro da rota, há uma função chamada getServerSideProps que faz uma solicitação assíncrona para a API do GitHub e retorna a resposta para a rota ou página por meio do data suporte.
Veja o código no Gist.
Rota Gatsby
Dentro desta rota, existe uma função chamada getServerData que faz uma solicitação assíncrona para a API do GitHub e retorna a resposta para a rota ou página por meio do data suporte.
Veja o código no Gist.
Rota de remix
Dentro desta rota, existe uma função chamada loader que faz uma solicitação assíncrona à API do GitHub e retorna a resposta, que pode então ser extraída e disponibilizada para a página usando o useLoaderData gancho.
Veja o código no Gist.
Rota Astrológica
Dentro desta rota, uma solicitação assíncrona é feita à API do GitHub a partir das cercas especiais “frontmatter” do Astro. O data pode então ser acessado diretamente pela rota ou página.
Veja o código no Gist.
Perfuração de hélice
Você notará que com todos esses exemplos, os dados são passados para um componente chamado ParentComponent por meio de uma propriedade chamada data.
ParentComponent
O ParentComponent pode ser parecido com isto, onde os dados são transmitidos novamente para outro componente chamado ChildComponent.
Veja o código no Gist.
Componente Filho
Finalmente, no ChildComponent é onde você talvez queira fazer algo com esses dados; e como você pode ver, os dados tiveram que percorrer uma pequena jornada antes de chegarem ao seu destino.
Veja o código no Gist.
Busca de dados em nível de componente
Como você provavelmente saberá, se refatorasse esse aplicativo ou movesse o componente Pai ou Filho, também precisaria reconectar a jornada de dados.
Não é incomum que isso aconteça ao longo da vida de um aplicativo e, dependendo da complexidade do seu aplicativo, determinará até que ponto você precisará descer antes que seus dados cheguem ao destino pretendido.
É aqui que os RSCs podem realmente ajudar. Veja como abordei isso usando o Waku.
Rota Waku
Usando o Waku ainda tenho uma rota, mas nenhuma busca de dados acontece neste nível.
Veja o código no Gist.
Waku ParentComponent
O ParentComponent ainda importa e retorna o ChildComponent, mas não há adereços e nada é passado para o ChildComponent.
Veja o código no Gist.
Waku ChildComponent
E aqui está o ChildComponent; mais uma vez, não há dados transmitidos por meio de acessórios. Em vez disso, toda a busca de dados acontece dentro do componente, no lado do servidor.
Veja o código no Gist.
Familiar para alguns
Esta abordagem de acesso a dados no nível do componente pode parecer familiar para alguns. Isso acontece comigo porque eu era um usuário ávido de Gatsby.
Gancho useStaticQuery de Gatsby
Em fevereiro de 2019, Gatsby introduziu o gancho useStaticQuery e, embora o método para buscar dados seja muito diferente (não estou tentando comparar isso com RSCs), a teoria é meio semelhante, e aqui está o porquê.
Veja o código no Gist.
Em Gatsby você nunca buscava dados usando GraphQL (um mal-entendido comum); em vez disso, você estava consultando. A busca de dados aconteceu em tempo de construção, mas com o useStaticQuery hook você foi capaz de acessar os dados de qualquer componente, em qualquer nível, sem precisar repassá-los por meio de adereços.
Com RSCs, a busca de dados acontece em tempo de execução, portanto, embora o método de busca de dados seja diferente entre RSCs e Gatsby’s useStaticQuery gancho, há algo a ser dito sobre as escolhas arquitetônicas que você poderia fazer ao acessar os dados de qualquer componente.
A busca de dados requer reflexão
No entanto, com RSCs você ainda terá que pensar em quais cenários faz sentido realizar a busca de dados em nível de componente, versus a busca de dados em nível de rota.
Por um lado, sim, é conveniente buscar e ter acesso aos dados ali mesmo no componente onde são necessários; mas, por outro lado, se você tiver vários componentes na mesma rota que buscam dados de forma independente, isso teria um impacto negativo no desempenho?
Em alguns casos, ainda pode fazer sentido fazer uma única solicitação no nível da rota e transmitir os dados resultantes por meio de props para os componentes que precisam deles, em vez de várias solicitações de dados no nível do componente. Vale a pena mencionar aqui que o emprego de estratégias de cache sensatas provavelmente limitaria o impacto de múltiplas solicitações de dados em nível de componente.
Pensamentos finais
RSCs, na minha opinião, são apenas mais uma opção disponível ao construir aplicativos React com uso intensivo de dados. Não acho que eles resolverão todos os casos de uso, nem é essa a intenção. Em muitos casos, provavelmente não serão a escolha certa, mas tudo bem.
Como todo desenvolvedor já disse sobre qualquer abordagem muitas vezes em sua carreira, isso depende.
Pela minha experiência com Gatsby, sei que há vantagens em ter dados facilmente acessíveis de dentro de um componente. Isso pode realmente ajudar a entender o que um aplicativo está fazendo porque a lógica, os dados e os elementos resultantes da interface do usuário estão perfeitamente localizados no mesmo arquivo e, quando comparados à busca de acessórios e à tentativa de seguir a jornada dos dados, o desenvolvedor a experiência geralmente é melhor.
Para concluir, gosto muito de RSCs e acho que com o tempo todos descobriremos as melhores práticas e coisas a serem observadas durante o desenvolvimento. Mas, por enquanto, acho que eles são um avanço muito legal e estou ansioso para experimentar mais. Se você estiver interessado em experimentar RSCs, experimente o Waku.
A postagem Resumindo os componentes do React Server apareceu pela primeira vez em The New Stack.
