Do React ao Hotwire

Do React ao Hotwire
As aventuras de uma migração de frontend em uma aplicação Rails 7

Transcript

1. Do React ao Hotwire Weldys Santos - Software Engineer @ Give Lively As aventuras de uma migração de frontend
2. • Sou de backend, mas normalmente trabalho como fullstack • Tenho dois f ilhos. Miguel com 6 anos e Victoria com 4 meses. • Sou fullstack engineer na Give Lively há dois anos; • Trabalho com Ruby e Rails desde 2006, mas fui pra gestão entre 2014 e 2021.
3. Razões para mudar
4. • Às vezes trabalhar com frontend em um monolito deixa as coisas um pouco mais complicadas • Chamadas de API dentro da mesma aplicação • Dois sistemas de rotas (react-routes e Rails Routes) • Renderização de serializers no backend e renderização no frontend com javascript
5. Nossas chamadas para o React # any view <%= render 'partials/render_react', component: ‘CustomQuestionsEditForm', props: @props %> # _render_react.html.erb <%= javascript_include_tag "frontend/ #{ component.underscore}" %> <div id="<%= component %>_container" class="react-component <%= defined?(html_class) ? html_class : "" %>”> </ div> <script> window.render<%= component %>( '<%= component %>_container', <%= props.to_json.html_safe %> ) </ script>
6. SPA vs Fullstack Rails • Queríamos reduzir a complexidade do nosso frontend • Aproveitar que já estávamos fazendo upgrade do app Rails (6 para 7) e do Ruby ( 2 para 3) ao mesmo tempo; • Enxugar o codebase era fundamental, uma vez que temos um monte de código legado (rails, haml com erb, react e até jquery) • Os componentes react estavam f icando tão complexos que era impossível escalar a aplicação no frontend • Suportar browsers antigos em sistemas antigos
7. Árvore de componentes React • Começamos a perceber que estava f icando muito complexo ter os componentes passando dados de um componente para outro. Tínhamos um useE ff ectHell na aplicação com chamadas externas, props de um lado pro outro sem necessidade • Começamos a usar algumas views do rails para simpli f icar ao menos as chamadas de renderizações do react
8. Novas chamadas para Ruby Partials # any view <%= render 'partials/render_react', component: ‘CustomQuestionsEditForm', props: @props %> # any view <%= render 'custom_questions/form', locals: { custom_question: @props } %>
9. Primeiro: Styled Components • Os styled-components simples, onde somente html era chamado, trazendo diversas props foram migrados para partials rails simples, sem a necessidade de usar nenhuma tecnologia diferente de HTML e CSS (usamos o bootstrap como base) • Passamos a utilizar alguns controllers stimulus para manipular DOM (como validações mais complexas em formulários ou mudança no comportamento de algum bloco)
10. Segundo: Turbo drive • Manipular carregamento de paginas entre navegação (navigation stack) • Possibilitar que páginas fossem carregadas sem que houvesse um reload da página • En f im, transformar em um SPA básico. • Todas as requisições assíncronas ainda permaneceram no React.
11. Exemplo de chamada button_to 'Send to contacts', notification_change_status_path(notification, :sent), method: :patch, class: 'btn', data: { status: :submitted, turbo_method: :patch }
13. Terceiro: Turbo Frames • Com as páginas funcionando com links sem reload (em boa parte delas), precisávamos componentizar novamente nossas páginas, fazendo requisições assíncronas e carregando informações dinamicamente • Após criar mais "componentes" em (ainda mais) shared partials, onde poderíamos utilizar as mesmas tabelas, listagens e diferentes tipos de componentes reutilizáveis. • Não, não tentamos o Phlex
14. Exemplo de chamada # button to call <%= button_to "Refresh", refresh_custom_questions_path, method: :post, remote: true %> # calling frame <turbo-frame id="custom-questions-frame"> <%= render partial: 'custom_questions/table', locals: { questions: @questions } %> </ turbo-frame>
15. Mas emperramos em alguns pontos… • Como migrar para o importmaps? Encontramos diversos problemas com navegadores antigos. Por isso, compilar assets ainda é nossa sina. • Consistencia dos testes. Testes em Jest precisaram migrar para testes de views, o que não agradou muito o time. • Em alguns controllers, precisavamos continuar respondendo usando os serializers, o que não melhorou em nada a performance das chamadas • Migrar é caro!
16. Ganhos • Muito mais ruby no código • Developer Happiness foi pro alto, uma vez que o trabalho de full-stack é quase 100% ruby, com exceção dos pontos em usamos stimulusJS • Boa parte das validações agora são mais simples, sem bibliotecas elaboradas (yup e react-validations) que derrubavam a performance principalmente em mobile • O sistema de componentização não precisa mais ser top-down como no react. • Desenvolvimento de f initivamente mais rápido!
17. É sobre isso! Obrigado! Weldys Santos https://bolha.us/@weldyss https://github.com/weldyss https://linkedin.com/in/weldyss