What's new in Rails 5.1

Rails 5.1: Favorite JavaScript, system tests, encrypted secrets, and more

As part of celebrating the 12th RailsConf in Phoenix, Arizona this week, we are proud to announce that Rails 5.1 is ready in its final form! We’ve done more than 4,100 commits since the release of Rails 5.0, making it all EASIER, EASIER, and, uhh, FUN? (This is a RailsConf joke).

Key information has not changed since the first beta, but here’s a replay:

Favorite javascript

Over the years, we have had a tumultuous, perhaps even controversial relationship with JavaScript. But this time has passed. JavaScript has improved a lot over the past few years, especially with the advent of ES6, as well as with tools for building and compiling, such as Yarn and webpack. Rails embraces both of these solutions with open arms and passes any past stream of water under the bridge.
')
JavaScript and Ruby share a deep philosophical connection with language design, if not ecosystem management. Let's focus on the aspects that we have and help Rails programmers get the best of JavaScript with some key guidelines.

Improvements in Rails 5.1 focus on three main parts:

1. Manage JavaScript dependencies on NPM using Yarn. Think of Yarn as a JavaScript Bundler (even Yehuda Katz is involved!). This makes it easy to manage dependencies on libraries such as React or anything else from NPM. Everything that you need through Yarn becomes available for use in the asset pipeline, as well as resources belonging to third-party entities from the vendor/assets directory. Just use binstub bin/yarn to add dependencies.
   
   
2. Optionally compile javascript using webpack. Despite the fact that there are a million different modules / module compilers for JavaScript, webpack quickly became the best choice. We made it easy to use webpack with Rails with the new Webpacker gem , which you can automatically configure in new projects with --webpack (or even --webpack=react , --webpack=angular , or --webpack=vue for individual configuration) . This is fully compatible with the asset pipeline, which you can continue to use for images, fonts, sounds, etc. You may even have some javascript in the asset pipeline, and done via webpack. This is all controlled via Yarn, which is enabled by default.
   
   
3. Drop jQuery as a default dependency. We used to connect jQuery to provide functions such as data-remote, data-confirm, and other parts of Rails UJS. This dependency is no longer needed, since we rewrote rails-ujs to use vanilla javascript . Of course, you can still use jQuery, but you no longer need it.

Thanks to Liceth Ovalles for her work on integrating Yarn, Dangyi Liu for working on rails-ujs and Guillermo Iguaran for accompanying all this!

System tests

In my speech at RailsConf in 2014, I talked in detail about how excessive focusing on unit tests (and TDD) led us astray. Although unit tests are part of a complete test solution, they are not the most important. Integration tests that test behavior all the way from controllers through models and presentations should play a much larger role. Rails already has an excellent built-in response to this.

But integration tests do not help test the entire system if this system uses JavaScript. And most of the major web systems today rely to some degree on JavaScript. This is where the system tests run under the control of a real browser.

Responses to system tests like this are called Capybara in Ruby. It was just a kind of adventure to set it up correctly in Rails. So now we have built it right into the framework ! You get a great Capybara shell, which is pre-configured for Chrome and enhanced to provide screenshots of crashes within the Action Dispatch. You also no longer have to worry about additional database cleaning strategies , because embedded transactional tests now roll back test system changes.

These tests are not without compromise. Of course, it is even slower to run the entire browser setting than to just test the model with a stub-database. But he also checks much more. You should be familiar with the system tests and get them as part of your test answer.

Thanks to Eileen M. Uchitelle for her work, extracted from Basecamp !

Encrypted secrets

If you check the production passwords, API keys and other secrets hidden in your version control system, you do wrong. It is not safe and you must stop it! Now this is just an admonition, but without a coherent answer to what you should do instead, it is also not very useful.

People have downloaded ENV long ago to store these secrets or use many other solutions. There are all sorts of compromises and shortcomings in the ENV model, not least that you still need to keep these secrets somewhere else.

Inspired by the heme sekrets of Ara T. Howard , we created encrypted secrets management in Rails 5.1 . You can set up a new encrypted secrets file using the bin/rails secrets:setup . This will create a master key that you will store outside the repository, but will allow you to commit your current production secret to your version control system. Then they are decrypted in the process either through the key file entered or via RAILS_MASTER_KEY to ENV.

Thanks to Kasper Timm Hansen for working on this and Ara for inspiration!

Parameterized mailer

Action Mailer modeled on Action Controller. He supports the basics of Abstract Controller, but has long been at a disadvantage from his cousin controller in how he can share logic between actions.

In Action Controller, before_action and similar callbacks are typically used to extract logic applied to multiple actions. This is doable, since the params hash is available before invoking this action. But in Action Mailer, we used the usual method signatures with explicit arguments, so these arguments were not available for filters that were executed before the actions.

With the help of the parameterized mailer, we now give you the opportunity to call the mailer with parameters that, like in controllers, are available before invoking this action. This is combined with the default settings for / from / reply_to headers, which drastically reduces the actions of the mailer.

It has full backward compatibility, and you can only convert mailers that will benefit in the first place.

Direct and permitted routes

We have a great simple API for announcing new resource routes. But if you want to add new programmable routes that have logic that determines the final destination based on parameters, you will have to dig it out yourself with the help of helpers and other messy approaches.

With the help of directional routes, you can now announce programmatic routes that, with all the power of Ruby, will do different things depending on the parameters passed.

With allowed routes, you can reprogram a polymorphic search for models based directly on compatible methods. Thus, it will allow you to turn link_to @comment into a final route, such as
message_path(@comment.parent, anchor: "comment_#{@comment.id}") .

Thanks to Andrew White for doing all this work !

Merging form_tag / form_for with form_with

We already have two parallel structures for creating forms. Those that were based on the form_for , where we used the conditional configuration to extract the details, and manually configure them with form_tag . Now we merged these two hierarchies with form_with . One root tree, which you can configure using the output entry or manually. It is much better and easier.

Thanks to Kasper Timm Hansen for that too!

All the rest

In addition to the main part, we have hundreds of other fixes and improvements throughout the framework. Please read the CHANGELOG to get acquainted with all the useful things:

• Action Cable CHANGELOG
• Action Mailer CHANGELOG
• Action Pack CHANGELOG
• Action View CHANGELOG
• Active Model CHANGELOG
• Active Record CHANGELOG
• Active Support CHANGELOG
• Active Job CHANGELOG
• Railties CHANGELOG

We have a big summary of the high level changes in the release notes .

Your release manager for Rails 5.1 was Rafael França .

According to our maintenance policy, the release of Rails 5.1 means that bug fixes will only apply to 5.1.x, common security issues up to 5.1.x and 5.0.x, and serious security issues up to 5.1.x, 5.0.x, and 4.2.x . This means that 4.x and below essentially will not be supported!

Thanks to everyone in the community for their hard work testing beta versions and releasing candidates for Rails 5.1! We made more than 600 commits after reporting errors and problems caused by this process. Thank you! Gracias! Merci! So

Original article