123456789_123456789_123456789_123456789_123456789_

DO NOT READ THIS FILE ON GITHUB, GUIDES ARE PUBLISHED ON https://guides.rubyonrails.org.

Ruby on Rails 5.1 Release Notes

Highlights in Rails 5.1:

These release notes cover only the major changes. To learn about various bug fixes and changes, please refer to the change logs or check out the list of commits in the main Rails repository on GitHub.

Upgrading to Rails 5.1

If you're upgrading an existing application, it's a great idea to have good test coverage before going in. You should also first upgrade to Rails 5.0 in case you haven't and make sure your application still runs as expected before attempting an update to Rails 5.1. A list of things to watch out for when upgrading is available in the Upgrading Ruby on Rails guide.

Major Features

Yarn Support

Pull Request

Rails 5.1 allows managing JavaScript dependencies from npm via Yarn. This will make it easy to use libraries like React, VueJS or any other library from npm world. The Yarn support is integrated with the asset pipeline so that all dependencies will work seamlessly with the Rails 5.1 app.

Optional Webpack support

Pull Request

Rails apps can integrate with Webpack, a JavaScript asset bundler, more easily using the new Webpacker gem. Use the --webpack flag when generating new applications to enable Webpack integration.

This is fully compatible with the asset pipeline, which you can continue to use for images, fonts, sounds, and other assets. You can even have some JavaScript code managed by the asset pipeline, and other code processed via Webpack. All of this is managed by Yarn, which is enabled by default.

jQuery no longer a default dependency

Pull Request

jQuery was required by default in earlier versions of Rails to provide features like data-remote, data-confirm and other parts of Rails' Unobtrusive JavaScript offerings. It is no longer required, as the UJS has been rewritten to use plain, vanilla JavaScript. This code now ships inside of Action View as rails-ujs.

You can still use jQuery if needed, but it is no longer required by default.

System tests

Pull Request

Rails 5.1 has baked-in support for writing Capybara tests, in the form of System tests. You no longer need to worry about configuring Capybara and database cleaning strategies for such tests. Rails 5.1 provides a wrapper for running tests in Chrome with additional features such as failure screenshots.

Encrypted secrets

Pull Request

Rails now allows management of application secrets in a secure way, inspired by the sekrets gem.

Run bin/rails secrets:setup to set up a new encrypted secrets file. This will also generate a master key, which must be stored outside of the repository. The secrets themselves can then be safely checked into the revision control system, in an encrypted form.

Secrets will be decrypted in production, using a key stored either in the RAILS_MASTER_KEY environment variable, or in a key file.

Parameterized mailers

Pull Request

Allows specifying common parameters used for all methods in a mailer class in order to share instance variables, headers, and other common setup.

class InvitationsMailer < ApplicationMailer
  before_action { @inviter, @invitee = params[:inviter], params[:invitee] }
  before_action { @account = params[:inviter]. }

  def 
    mail subject: "#{@inviter.name} invited you to their Basecamp (#{@account.name})"
  end
end
InvitationsMailer.with(inviter: person_a, invitee: person_b)
                 ..deliver_later

Direct & resolved routes

Pull Request

Rails 5.1 adds two new methods, resolve and direct, to the routing DSL. The resolve method allows customizing polymorphic mapping of models.

resource :basket

resolve("Basket") { [:basket] }
<%= form_for @basket do |form| %>
  <!-- basket form -->
<% end %>

This will generate the singular URL /basket instead of the usual /baskets/:id.

The direct method allows creation of custom URL helpers.

direct(:homepage) { "http://www.rubyonrails.org" }

homepage_url # => "http://www.rubyonrails.org"

The return value of the block must be a valid argument for the url_for method. So, you can pass a valid string URL, Hash, Array, an Active Model instance, or an Active Model class.

direct :commentable do |model|
  [ model, anchor: model.dom_id ]
end

direct :main do
  { controller: 'pages', action: 'index', subdomain: 'www' }
end

Unification of form_for and form_tag into form_with

Pull Request

Before Rails 5.1, there were two interfaces for handling HTML forms: form_for for model instances and form_tag for custom URLs.

Rails 5.1 combines both of these interfaces with form_with, and can generate form tags based on URLs, scopes, or models.

Using just a URL:

<%= form_with url: posts_path do |form| %>
  <%= form.text_field :title %>
<% end %>

<%# Will generate %>

<form action="/posts" method="post" data-remote="true">
  <input type="text" name="title">
</form>

Adding a scope prefixes the input field names:

<%= form_with scope: :post, url: posts_path do |form| %>
  <%= form.text_field :title %>
<% end %>

<%# Will generate %>

<form action="/posts" method="post" data-remote="true">
  <input type="text" name="post[title]">
</form>

Using a model infers both the URL and scope:

<%= form_with model: Post.new do |form| %>
  <%= form.text_field :title %>
<% end %>

<%# Will generate %>

<form action="/posts" method="post" data-remote="true">
  <input type="text" name="post[title]">
</form>

An existing model makes an update form and fills out field values:

<%= form_with model: Post.first do |form| %>
  <%= form.text_field :title %>
<% end %>

<%# Will generate %>

<form action="/posts/1" method="post" data-remote="true">
  <input type="hidden" name="_method" value="patch">
  <input type="text" name="post[title]" value="<the title of the post>">
</form>

Incompatibilities

The following changes may require immediate action upon upgrade.

Transactional tests with multiple connections

Transactional tests now wrap all Active Record connections in database transactions.

When a test spawns additional threads, and those threads obtain database connections, those connections are now handled specially:

The threads will share a single connection, which is inside the managed transaction. This ensures all threads see the database in the same state, ignoring the outermost transaction. Previously, such additional connections were unable to see the fixture rows, for example.

When a thread enters a nested transaction, it will temporarily obtain exclusive use of the connection, to maintain isolation.

If your tests currently rely on obtaining a separate, outside-of-transaction, connection in a spawned thread, you'll need to switch to more explicit connection management.

If your tests spawn threads and those threads interact while also using explicit database transactions, this change may introduce a deadlock.

The easy way to opt out of this new behavior is to disable transactional tests on any test cases it affects.

Railties

Please refer to the Changelog for detailed changes.

Removals

Notable changes

Action Cable

Please refer to the Changelog for detailed changes.

Notable changes

Action Pack

Please refer to the Changelog for detailed changes.

Removals

Deprecations

Notable changes

Action View

Please refer to the Changelog for detailed changes.

Removals

Deprecations

Notable changes

Action Mailer

Please refer to the Changelog for detailed changes.

Notable changes

Active Record

Please refer to the Changelog for detailed changes.

Removals

Deprecations

Notable changes

Active Model

Please refer to the Changelog for detailed changes.

Removals

Notable changes

Active Job

Please refer to the Changelog for detailed changes.

Removals

Notable changes

Active Support

Please refer to the Changelog for detailed changes.

Removals

Deprecations

Notable changes

Credits

See the full list of contributors to Rails for the many people who spent many hours making Rails, the stable and robust framework it is. Kudos to all of them.