Componentes CSS-in-JS e React Server: um guia do desenvolvedor

Com o ecossistema em evolução do React, especialmente com a mudança do Next.js para uma abordagem “server-first”, os aplicativos que usam soluções CSS-in-JS, como Emotion e styled-components, estão enfrentando desafios significativos. Essas bibliotecas CSS-in-JS são inerentemente incompatíveis com o novo paradigma React.

Embora se possa argumentar que essas bibliotecas poderiam ser atualizadas para se alinharem com a nova direção do servidor, é importante lembrar que elas são mantidas por colaboradores não remunerados de código aberto. Esperar que eles reformulem completamente suas bibliotecas para acomodar as mudanças no React é uma tarefa assustadora e potencialmente irrealista.

Vejamos por que algumas soluções CSS-in-JS não conseguem funcionar no novo mundo que prioriza o servidor. Em seguida, apresentarei uma alternativa, Linaria, que usa uma API quase idêntica aos componentes estilizados.

O Paradigma RSC

Isso se tornará uma explicação prolixa, mas é importante entender como o React funcionava (pré-React Server Components) e como funciona agora (pós-RSC).

Pré-RSC: Servidor e Cliente

Então vamos começar do início. Pré-RSC, o React renderizava um “componente” no servidor e no cliente. O React sempre renderizou as partes estáticas da página HTML no servidor e as enviou ao cliente para ser “hidratado”. A fase de hidratação é o JavaScript do lado do cliente responsável por lidar com referências ou anexar manipuladores de eventos, que normalmente permitem interatividade.

Se parece um pouco idiota fazer esse trabalho duas vezes – uma vez no servidor e depois reproduzi-lo novamente no cliente – é porque realmente é. Já discuti isso comparando a hidratação do React com a abordagem retomável do Qwik, o que para mim faz muito mais sentido.

Pós-RSC: somente servidor

No entanto, em um mundo pós-RSC, todos os componentes do React, por padrão, são apenas de servidor. O React renderiza as partes estáticas da página HTML, mas não as hidrata no cliente. Isso reduz/elimina qualquer JavaScript do lado do cliente. Esta é uma abordagem interessante porque em um mundo pós-RSC, somos capazes de fazer solicitações do lado do servidor a partir de qualquer componente, em qualquer nível da árvore, não apenas no nível da rota, que era como o Next.js funcionava anteriormente.

Nova diretiva de cliente de uso do React

Em um mundo pós-RSC, você ainda pode ativar o JavaScript do lado do cliente e métodos específicos do React, como useState, useEffectetc., mas você precisa ser explícito e adicionar o use client diretiva no topo do arquivo para que o React se comporte da mesma maneira que sempre.

Por que CSS-in-JS não funciona com RSC?

Para adicionar um pouco mais de contexto, é importante entender como, na falta de uma palavra melhor, as bibliotecas CSS-em-JS legadas funcionam antes de entender por que elas não funcionam em um mundo pós-RSC.

Bibliotecas como Emotion e componentes estilizados fazem grande parte do trabalho pesado em tempo de execução, no cliente usando JavaScript do lado do cliente, que estabelecemos que não existe mais em RSCs, ou componentes “somente servidor”.

Você provavelmente já viu isso em vigor. Se você inspecionar qualquer aplicativo ou site que use, por exemplo, componentes estilizados, você notará os nomes de classe de aparência estranha.

Veja o código no Gist.

Isso ocorre porque com styled-components, você, o desenvolvedor, não escreve classes CSS, você escreve componentes – e styled-components (a biblioteca) trata de extrair os estilos, convertê-los em CSS que o navegador possa entender e gerar um nome de classe aleatório, mas exclusivo, e aplicá-lo a um elemento DOM para vincular os dois.

Por exemplo, veja como você pode definir um elemento âncora HTML usando componentes estilizados para uso em um componente React.

Veja o código no Gist.

Quando styled-components é executado, ele cria o nome da classe (como visto acima), adiciona-o ao elemento DOM e converte os valores CSS conforme definido quando o styled.a foi criado em CSS que o navegador pode entender, como:

Veja o código no Gist.

Mas como mencionado, tudo isso acontece em tempo de execução, no cliente, usando JavaScript do lado do cliente.

Infelizmente, como os RSCs são projetados para serem renderizados no servidor e depois enviados como HTML ao cliente, eles têm características e limitações específicas – principalmente em relação ao JavaScript do lado do cliente, que impede o funcionamento de bibliotecas como componentes estilizados.

Nem tudo está perdido

Existem várias soluções mais recentes para esse problema que transferem o trabalho pesado do cliente para a construção. Já fazemos muito trabalho pesado aqui, convertendo TypeScript em “browser Js”, então fazer coisas CSS-in-JS neste momento parece uma ótima solução para o mundo pós-RSC.

No entanto, você pode se perguntar: isso não significa que os desenvolvedores de todo o mundo precisariam reescrever todos os seus styled. declarações usando alguma nova API sofisticada? Porque isso seria um pesadelo!

Felizmente, os criadores do Linaria, que existe desde 2017, optaram por usar uma API muito semelhante à dos componentes estilizados. O Pigment CSS da equipe MUI também seguiu um padrão semelhante, o que é uma ótima notícia.

Como funcionam as bibliotecas CSS-in-JS compatíveis com RSC?

No caso do Linaria, utiliza módulos CSS. Se eu usar o styled.a exemplo novamente:

Veja o código no Gist.

Em vez de se transformar em um nome de classe aleatório, mas único, Linaria cria um (component name).module.css arquivo e converte a declaração estilizada em uma classe CSS chamada real, por exemplo:

Veja o código no Gist.

Durante a etapa de construção do seu aplicativo, uma importação para os módulos CSS .css será adicionado ao componente, e a declaração estilizada será convertida no elemento HTML subjacente (neste caso, é um elemento âncora), e uma referência à classe será adicionada:

Veja o código no Gist.

Como tudo isso acontece durante a etapa de construção, não há nada que o navegador possa fazer — e, portanto, não é necessário nenhum JavaScript do lado do cliente. Na verdade, é uma solução muito legal para o problema e tudo o que é necessário para migrar seria desinstalar componentes estilizados, instalar o Linaria e executar uma localização e substituição de import styled from 'styled-components'; que import styled from '@linaria/react';.

Pensamentos finais

Então aí está, quando algo tão amplamente usado como o React muda completamente a forma como ele funciona fundamentalmente, muitos projetos de código aberto projetados para ele também precisarão mudar – ou, em alguns casos infelizes, serão retirados dos livros de história. No mundo do JavaScript, tudo muda com frequência e tudo o que podemos fazer é tentar acompanhar!

Dito isto, a dedicação da comunidade para reagir (trocadilho intencional) e evoluir quando ocorrem mudanças é incrível, e estou feliz por fazer parte desta comunidade maluca. Nunca há um momento de tédio!

A postagem Componentes CSS-in-JS e React Server: um guia do desenvolvedor apareceu pela primeira vez em The New Stack.