This content originally appeared on DEV Community and was authored by Cirdes Henrique
Introdução
No primeiro artigo sobre essa migração do React para o Hotwire, eu abordei como chegamos à nossa stack atual em React. Nesta Parte II, vou falar sobre o retorno às views do Rails na Linkana.
Evolução do Rails e o SSR
Uma das características mais brilhantes do Rails é sua obsessão pela simplicidade. Como o Rails nasceu dentro do Basecamp, uma empresa que escolheu ter poucos funcionários, faz parte do DNA do Rails buscar maneiras de manter o desenvolvimento web simples. Por isso, o Rails é o Framework de uma pessoa só.
Ter participado da última edição do Rails World e assistido à palestra do DHH me fez perceber que gerar views no backend com Rails já não era mais sinônimo de interfaces lentas, feias e que não se preocupam com UX. Com Hotwire, através do Turbo e do Stimulus, era possível criar aplicações tão complexas como o Gmail, Hey ou Slack, Campfire. E isso ficou ainda mais surreal com o Turbo 8.
Mas o grande benefício do retorno ao Server Side Rendering (SSR) é não precisar de APIs. Criar uma API, seja ela REST ou GraphQL, torna o desenvolvimento mais lento. E não é apenas o Rails que está percebendo isso, é o Elixir com o Liveview, PHP com o Livewire, e até mesmo o próprio JS com HTMX, além do próprio React. Como diz o Deno.js: O Futuro (e o Passado) da Web é a Renderização do Lado do Servidor.
Componentes vieram para ficar
Como vimos na Parte I desse artigo, views em React/Vue/etc. introduziram o conceito de componentes. Esses componentes são pequenos blocos de interface que condensam "Estilo (Tailwind)", "Estrutura (HTML)" e "Comportamento/JavaScript". Componentizar, além de promover o reuso e facilitar o teste, permite customização ou utilização para criar seu próprio Design System. Mas o mais importante, eles já estão prontos. Você não precisa reinventar a roda. Um grande exemplo é o Shadcn, lançado apenas em março de 2023 e que já conta com 60k estrelas no Github.
Infelizmente, as views do Rails foram criadas no contexto pré-componentes. O html.erb é muito bom para se escrever HTML, mas não é bom para escrever comportamento. Já os partials são ótimos para se escrever comportamento, mas são péssimos para HTML.
Para tentar resolver isso, a primeira solução que surgiu foi o ViewComponents, um framework criado pelo pessoal do Github. O ViewComponent é o nosso React, permitindo que o frontend seja pensado na forma de componentes. Ele é a solução mais popular hoje. Apesar de eu nunca ter usado, sinto que faltou ousadia. Ele me parece uma fusão dos partials com o erb. Mas o que mais me decepcionou foi que o Gihub está migrando do Rails para o React e os próprios mantenedores do ViewComponents não me parecem muito empolgados.
Como alternativa ao ViewComponent, encontrei o Phlex. Ele vem com a ousadia de criar componentes utilizando somente código Ruby. Esse é o tipo de ousadia que assusta. Eu me assustei quando vi pela primeira vez o React colocar HTML, JS e CSS (StyledComponents) dentro de um componente. Eu me assustei ao ver o Tailwind criar classes para cada propriedade do CSS e termos HTML criados com dezenas de classes em um elemento. Abrir mão desse "preconceito" e testar o Phlex foi importante aqui. Mas o fator decisivo foi acompanhar o criador do Phlex, o Joel Drapper, nas redes sociais e perceber o quão motivado ele está.
Biblioteca de componentes
Como não gostamos de reinventar a roda aqui na Linkana, resolvemos buscar bibliotecas de componentes que pudéssemos usar e chegamos a avaliar:
- https://phlexui.com/
- https://primer.style/guides/rails
- https://shadcn.rails-components.com/
- https://railsdesigner.com/
- https://zestui.com/
- https://railsui.com/
- https://protos.inhouse.work/
Acabamos escolhendo a Phlex UI não por acreditar que ela está pronta, mas por acreditar que o caminho que ela escolheu é o mais adequado à premissa de componentes reutilizáveis e de fácil customização. Ela é uma biblioteca que foi claramente inspirada na Shadcn](https://ui.shadcn.com/) e trouxe para o mundo Rails algumas inovações do Shadcn.
Incentivar que você customize os componentes copiando-os para a sua codebase.
Uma estrutura de componentes muito parecida com o React:
Shadcn
Accordion type="single" collapsible className="w-full">
<AccordionItem value="item-1">
<AccordionTrigger>Is it accessible?</AccordionTrigger>
<AccordionContent>
Yes. It adheres to the WAI-ARIA design pattern.
</AccordionContent>
</AccordionItem>
</Accordion>
PhlexUI
render PhlexUI::Accordion.new do
render PhlexUI::Accordion::Item.new do
render PhlexUI::Accordion::Trigger.new do
p{ "What is PhlexUI?" }
end
render PhlexUI::Accordion::Content.new do
p { "PhlexUI is a UI component library for Ruby devs who want to build better, faster." }
end
end
end
Todo o CSS é escrito com Tailwind dentro do próprio componente. É muito fácil fazer pequenos ajustes/mudanças.
Os componentes são formados por várias classes Ruby muito simples. É um código muito fácil de entender.
- Integração com Stimulus através de controllers específicos de cada componente.
Colocando em produção
O primeiro passo para começar a migração para SSR com Phlex e Hotwire foi mapear os componentes do PhlexUI e colocá-los no Lookbook dentro da nossa aplicação com as cores da nossa marca.
O segundo passo foi criar uma versão em Rails de todos os elementos de navegação. Sidebar, tabs, etc.
Dessa forma, conseguimos ir reescrevendo rota por rota usando SSR ao mesmo tempo que as rotas em React (SPA) continuam funcionando. Por exemplo:
Tudo que faz parte do Dashboard já está utilizando SSR. Navegar entre as abas "Resumo" e "Lead time" é uma navegação que utiliza o Turbo do Hotwire.
Quando o usuário clica na aba de pendências, desabilitamos o Turbo e é feita uma requisição de HTML ao backend que carrega nossa SPA em React e a página é exibida. Com isso, a aplicação muda para o modo SPA e as requisições voltam a ser via nossa API GraphQL com troca de JSON.
Se o usuário clicar num link que já está em Hotwire, fazemos com que o React realize uma requisição de HTML e a aplicação volte a ser uma SSR.
A transição do SPA para o SSR é praticamente imperceptível, mas do SSR para o SPA é um pouco mais demorada, sem atrapalhar a experiência do usuário. Nossa ideia é finalizar essa transição até a próxima edição do Tropical.rb.
Desde o dia 11 de junho, estamos rodando o Phlex em produção e, como forma de agradecimento, a Linkana passou a ser um dos sponsors do projeto. Também já começamos a contribuir com o projeto do PhlexUI.
Se você também está trabalhando com componentes em Rails, deixe nos comentários o que você tem feito.
This content originally appeared on DEV Community and was authored by Cirdes Henrique
Cirdes Henrique | Sciencx (2024-06-16T15:44:26+00:00) Do React ao Hotwire – Parte II – [PT-BR]. Retrieved from https://www.scien.cx/2024/06/16/do-react-ao-hotwire-parte-ii-pt-br/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.