Do React ao Hotwire - Parte I - [PT-BR]

English version available

Parte II

Na última edição do Tropical.rb, anunciei que a Linkana iria iniciar a transição do React para o Hotwire. Essa transição já começou e quero contar para vocês quais desafios estamos encontrando. Antes de começar, gostaria de fazer uma retrospectiva de como tem sido minha experiência no Frontend das minhas aplicações nos últimos anos.

Passado - Server Side Rendering (SSR) - 2011/2017

Na minha primeira empresa, Eventick, usávamos apenas as views do Rails para criar nosso Frontend. O grande desafio era elaborar layouts em um mundo onde Flexbox ou Grid não existiam. Dependíamos de floats, posicionamento absoluto/relativo e tabelas. O JavaScript se resumia ao jQuery; tentar usar JS puro era uma loucura, já que cada navegador se comportava de maneira diferente.

Nessa época, o JavaScript começou a ser levado a sério. O Internet Explorer estava perdendo mercado e os primeiros frameworks/libs "modernos" começaram a surgir. Comecei a utilizar o AngularJS 1.0, ainda integrado com as views do Rails. O papel do Angular era criar interfaces mais interativas, sem que fosse necessário escrever várias linhas de código em JS ou jQuery apenas para ocultar ou exibir um elemento. O universo JavaScript estava ganhando força, enquanto no Rails era muito difícil usar os pacotes do NPM. O mindset era utilizar gems para adicionar arquivos JS e CSS, mas as libs recebiam atualizações mas as suas gems não. Foi o momento em que o Rails ficou para trás no Frontend.

Pouco tempo depois, o React apareceu e começou a chamar atenção, principalmente com o apelo do DOM Virtual. Era uma lib que prometia desempenho ao mesmo tempo que era leve. Nesse momento, o Google decidiu mudar toda a arquitetura do Angular com o Angular V2, tornando o V1 incompatível com o futuro do Framework. Vendo o Angular em crise e o React emergir, comecei a brincar com o React. Foi mais ou menos nessa época que a Eventick foi vendida para a Sympla e eu sabia que meu próximo projeto precisaria ser um SPA com React. Era inconcebível iniciar uma startup em 2018 utilizando o caminho do Rails.

Presente - SPA - 2017/2024

Na Linkana, optamos pelo GraphQL depois de ler um artigo do Airbnb mencionando que estavam avançando 10 vezes mais rápido com o GraphQL e o Apollo. Mas também devido à minha frustração com o Redux, que sempre me pareceu uma solução complexa e burocrática. Olhando para trás, acredito que foi uma decisão acertada. Com o Apollo e o GraphQL, conseguimos desenvolver APIs em menos tempo e nos livramos da complexidade de lidar com o estado usando Redux, Reflux, etc. No entanto, o principal ponto negativo do GraphQL é que ele torna o problema de N+1 bastante complexo, algo que ainda enfrentamos hoje. Além de dificultar a implementação de cache nas requisições, felizmente não é um problema que precisamos enfrentar na Linkana.

O React também se mostrou uma aposta acertada, devido à grande quantidade de bibliotecas disponíveis. Por outro lado, por ser uma biblioteca e não um framework, o código React geralmente tende a se tornar bagunçado. Falta a convenção do Rails. Isso é algo que enfrentamos na Linkana, mas não considero ser um dos problemas mais graves. Sempre tentamos organizar nossos componentes utilizando o Atomic Design e uma estrutura de pastas que acreditamos fazer sentido.

Outra aposta importante no início da Linkana foi o Grommet, um framework UI que oferece componentes React para criação de interfaces. Alguns podem pensar que foi uma aposta errada, já que eventualmente migramos dele e o Grommet nunca decolou, mas não foi o caso. Na época, tínhamos em mente que a "criação do nosso Design System" era uma vaidade comum em muitas empresas, grandes e pequenas. Essa mentalidade, acredito, foi um legado do Twitter Bootstrap. Embora o Bootstrap tenha sido a primeira biblioteca de UI a se popularizar, seu ponto forte nunca foi a personalização. Como resultado, muitos sites acabaram com uma aparência semelhante. O Grommet, além de ser um framework UI pronto, foi o único disponível em 2017/2018 que tinha o arquivo do Figma disponível. Outras opções mais populares, como MUI e Ant Design, não ofereciam esse recurso. Ter o arquivo do Figma significava que os projetos de design seriam realizados dentro do Sandbox do Grommet, evitando a necessidade de personalizações desnecessárias.

Essa arquitetura serviu bem à Linkana por alguns anos, até percebermos que o Grommet, que inicialmente facilitava nosso trabalho, estava se tornando um obstáculo quando precisávamos fazer customizações simples. Além disso, ele nos afastava do CSS; estávamos aprendendo Grommet, mas não CSS. Foi então que partimos em busca da Stack V2.

Stack V2 com Shadcn e Tailwind

A Stack V2 da Linkana precisava manter ou aumentar nossa produtividade, ao mesmo tempo que nos permitisse fazer as modificações mínimas que ainda desejávamos.

A primeira aposta que fiz foi no Tailwind. O Tailwind é conhecido por "looks ugly and feels good". A princípio, muitas pessoas podem sentir repulsa ao olhar as classes do Tailwind em uma tag HTML, mas depois de algumas horas de uso, percebe-se o quão conveniente é não precisar mais se preocupar com arquivos .css separados. Tudo está disponível através de classes. Para compreender isso, tive que trabalhar em um projeto paralelo.

Logo depois, descobri um conceito novo chamado "unstyled-ui", que são bibliotecas JS que implementam todo o comportamento dos componentes de uma biblioteca, deixando o CSS para ser aplicado por você. Bons exemplos são: Radix-ui, Headless-ui e Tanstack.

A ideia de ter componentes sem UI como o Radix permite que ele seja adicionado a qualquer projeto. Não é mais necessário "lutar" para remover o estilo do componente e fazê-lo se adequar ao seu projeto. Ou ter que reinventar a roda e fazer o componente do zero. Quando vi isso, essa direção fez muito sentido para mim.

Mas o grande achado mesmo foi o Shadcn. O Shadcn é uma biblioteca que reúne todos esses conceitos. Ele usa o Radix como base, incorpora o Tailwind para adicionar estilo ao Radix e possui um arquivo do Figma. Além disso, o Shadcn inovou em mais um aspecto: em vez de ser um pacote npm/lib, ele é apenas um conjunto de código reutilizável que você pode copiar e colar em seu projeto. Como ele mesmo diz:

Isto NÃO é uma biblioteca de componentes. É uma coleção de componentes reutilizáveis que você pode copiar e colar nos seus aplicativos

Embora isso possa parecer estranho, tenho visto esse modelo sendo aplicado cada vez mais em outros projetos, pois ele permite que você utilize componentes, mas ao mesmo tempo te dá uma possibilidade de personalização como nunca antes foi possível. Ele junta a praticidade de um Bootstrap com a customização de um "Design System" próprio. Além disso ele conta uma IA para gerar interfaces gráficas.

Ao juntar tudo isso, temos o Frontend SPA com React da Linkana.

Falarei sobre o Hotwire na parte II desse artigo.