Uma coisa que não é tão boa ao ter que lidar com projetos de clientes, é que a maioria deles leva tempo antes de fazer uma atualização completa do Framework. E você não pode culpá-los, já que muitas das dependências no ecossistema tomam o precioso tempo deles para fazer upgrade.

O Rails 5.2 Beta está quase entre nós, e eu aposto que a maioria dos projetos Rails está na versão 4.2, ainda pensando em fazer o salto para a 5.0 (o que não é uma atualização tão ruim).

Por sinal, no caso de você não saber, o site oficial Rails Guides possui uma seção dedicada às atualizações. É chamado A Guide for Upgrading Ruby on Rails. O processo de atualização não é realmente tão difícil se, e somente se:

• Você tem uma boa cobertura de teste. Você deve ter, no mínimo, especificações de recursos para as partes mais importantes do seu sistema.
• Você deve atualizar apenas uma versão subsequente de cada vez, nunca indo direto para a mais recente. Por exemplo, se você estiver no Rails 4.1, você deve primeiro atualizar para 4.2, e certificar-se de que tudo funciona. Em seguida, vá para 5.0. E só então vá para 5.1. Cada versão tem muitas deprecações, mudanças no comportamento, mudanças na configuração padrão do boilerplate, novos recursos adicionados. Você deve atender a cada uma com muito cuidado.

Então, o que você está perdendo se ainda estiver no Rails 4.2?

Novamente, no caso de você não saber, o site oficial Rails Guides também compila release notes detalhadas e fáceis de ler para cada nova versão. As mais recentes são as Ruby on Rails 5.1 Release Notes.

Começando um novo projeto

O comando rails new tem muitas novas flags. E eu acho que estas são as que a maioria das pessoas usará:

rails new --skip-action-mailer --skip-coffee --webpack=react my_fancy_new_project

Você pode desativar recursos de que não precisa, como ActionMailer ou acionáveis. Você pode desativar o CoffeeScript. Ele foi legal por um tempo, mas agora que o ES6 existe, devemos apenas usá-lo.

O Rails 5.1 vem com o suporte para webpack. Mas até o Rails 5.2 surgir, precisamos usar o webpack-dev-server manualmente no modo de desenvolvimento para que possamos recarregar ativos. Para esse fim, recomendo instalar o bom e velho Foreman. Instale-o assim:

gem install foreman

E adicione um arquivo Procfile.dev ao seu projeto com o seguinte conteúdo:

web: ./bin/rails s -b 0.0.0.0 -p 3000
webpack: ./bin/webpack-dev-server

Em produção, você não precisa do webpack-dev-server, já que a tarefa bin/rails assets:precompile deve ser capaz de compilar todos os ativos de que você precisa como arquivos estáticos e timestamped em public/assets.

Alterações específicas de front-end

Agora, você pode se alegrar com Yarn, Webpack e não mais jQuery pré-instalado. Samuel Muller tem um bom artigo, que resume a maioria dessas mudanças com mais detalhes.

E agora o Ruby on Rails suporta oficialmente todos os aspectos do ecossistema JavaScript. Não há mais nada que você possa perder.

Chega de vendedores manualmente de ativos JS no diretório vendor/assets/javascripts. Não há mais necessidade de usar o Rails Assets, que era uma fonte RubyGems secundária específica para o pacote de bibliotecas JS em RubyGems.

Digamos que, por algum motivo, você queira voltar para jQuery. Agora você pode fazer:

yarn add jquery

E, como de costume, você pode simplesmente adicioná-lo ao arquivo manifesto app/assets/javascripts/application.js:

// app/assets/javascripts/application.js
...
//= require jquery
...
//= require_tree .

O chamado “suporte para Yarn em Rails 5.1” resume-se a alguns wrappers e boilerplate. Então, você pode rodar rails yarn:install e ter as dependências instaladas, mas você pode facilmente digitar yarn, e ele irá instalar tudo o que você precisa que está declarado no arquivo package.json, como com qualquer outro projeto com apenas JavaScript.

Agora, toda a magia da integração vem da inclusão do gem do Webpacker. Ele acrescenta um monte de configurações boilerplate no webpack. E, como bônus, você pode incluí-lo hoje em seus atuais projetos Rails 4.2+ também. Basta começar adicionando o gem do webpacker ao seu Gemfile:

# Gemfile
gem 'webpacker', '~> 3.0'

Em seguida, instale o pacote como de costume e execute:

bundle exec rake webpacker:install

Se você não usou a flag –webpack=react para o novo comando rails, você pode adicioná-la mais tarde. Ou você também pode adicionar Angular:

bundle exec rake webpacker:install:angular
bundle exec rake webpacker:install:react

Você deve substituir o ramal bundle exec rake por bin/rails se você estiver no Rails 5.1.

Adicionar os componentes React adequados é um pouco mais complicado do que o comando acima. E os detalhes são mais do que eu quero cobrir neste artigo.

Andy Barnov tem um artigo bom sobre como seguir a convenção de packs do Rails 5.1 para adicionar seus componentes do React ao pipeline. Como ele recomenda, não lute contra as convenções para você ser bem-sucedido.

Curiosamente, apesar de eu ter usado a flag –webpack-react para o novo rails, ainda tive que rodar o seguinte comando para inicializar o webpack e reagir aos suportes:

./bin/rails webpacker:install:react

Mas uma vez que você faz isso, você terá um novo lugar para adicionar os componentes do React, e isso está em um apropriado app/javascripts/packs. E nas visualizações, em vez do habitual javascript_include_tag, você usará o novo javascript_pack_tag. Eu acredito que você pode descobrir o resto a partir do componente de exemplo hello_react.jsx que ele gera para você.

Considerações finais

Agora você tem mais opções para o JavaScript, já que o Rails 5.1 abraça completamente os padrões atuais.

Era uma vez ninguém que sabia como simplificar um Asset Pipeline. Foi muito confuso compilar todos os seus recursos em um único arquivo com timestamps de cancelamento de cache apropriados, mas o gem Sprockets fez isso.

Era uma vez o JavaScript 5, que era uma maldita bagunça. Bibliotecas como o JQuery realmente “corrigiram” a maior parte da situação DOM dos navegadores, e o CoffeeScript normalizou a linguagem de uma forma que a tornou agradável. O ES6 veio assumir o comando, mas é muito injusto criticar JQuery e Coffee, já que nem ES6 nem HTML5 estavam lá para resolver a situação há quase 10 anos. JQuery e Coffee estavam lá, e eles resolveram.

Quando Angular, Ember, React estavam começando, já tivemos uma solução boa o suficiente em site JavaScript pesado com Turbolinks. Essa ainda é uma solução muito boa que você deve considerar usar em vez de adicionar uma solução React/Redux completa (e às vezes desnecessária) de uma vez.

CSS é outro assunto. A comunidade Rails também criou o Sass (que, em seguida, o Twitter copiou com o Less para o framework Bootstrap).

É fácil ver o cenário atual e apenas repetir que Coffee é ruim ou Sprockets é ruim. Mas, nos últimos 10 anos, essas ferramentas foram as melhores em um momento em que as pessoas não tinham Yarn, Webpack, React e todas as ferramentas que surgiram nos últimos três anos ou mais.

O Rails 5.1 é uma versão muito boa para casar o melhor do Rails com o melhor que se estabilizou hoje na arena louca do JavaScript. E eu recomendo que qualquer projeto novo tenha início com o Rails 5.1 em mente.

Uma coisa que me levou a escrever este artigo, foi destacar que muitas pessoas fazem perguntas que são principalmente respondidas nos guias oficiais do Rails. Não apenas sobre como instalar e usar os muitos componentes do framework, mas também como atualizar e quais são os novos recursos de cada versão. Então, você definitivamente deveria dar uma olhada melhor lá.

***

Artigo traduzido com autorização do autor. Publicado originalmente em: http://www.akitaonrails.com/2017/10/24/beginner-trying-out-rails-5-1-x