Digging Into Rails 4

PATCH is now the new HTTP verb for updating resources.

You’re trading time for space, as this generates a lot of cruft in your cache. But, as DHH points out, cache stores like Memcached just chuck out old data to make space for new data. So this isn’t an issue in most cases.

Cache Digests

Cache digests are Rails 4′s solution for tracking the changes of aggressively cached templates. Rails 4 tracks templates and their dependencies, and it suffixes fragment cache keys with the MD5 digest of the template (and its dependencies). When you edit one of your templates, its cache key recieves the update, and you won’t have to manually version your templates.

For more information (and for use in Rails 3), check out the README for the cache digests gem.

Streaming, via ActionController::Live

The new ActionController::Live module provides the ability to stream data to clients. Simply include the module into a controller to enable your app to send arbitrary streamed data. You’ll have to use a threaded server, like thin and puma, in order to stream data; actions from streaming controllers run in a separate thread.

Here’s an example from the Rails 4 documentation:

class MyController < ActionController::Base  include ActionController::Live  def stream    response.headers['Content-Type'] = 'text/event-stream'    100.times {      response.stream.write "hello world\n"        sleep 1    }    response.stream.close  endend

As the docs note, there are three things to keep in mind:

• You must write any headers before you call write or close on the response stream.
• You have to call close on the response stream when you’re finished writing data.
• Ensure that your actions are thread-safe, as they will run in a separate thread.

Niceties and Other Things

We’ve talked about the “headline” features in Rails 4. But this release is a big one, and includes a number of smaller changes to be aware of.

PATCH

As described in the Rails blog, PATCH is now the HTTP verb for updating resources.

This change will typically be transparent to developers, as PUT requests will still route to the update action for RESTful-style routes.

But it is a change that you should be aware of; PUT routing may change in the future.

Custom Flash Types

This small feature may help clean up some code. You can register your own flash types to use in redirect_to calls and in templates. For example:

# app/controllers/application_controller.rbclass ApplicationController  add_flash_types :error, :catastropheend# app/controllers/things_controller.rbclass ThingsController < ApplicationController  def create    # ... create a thing  rescue Error => e    redirect_to some_path, :error => e.message  rescue Catastrophe => e    redirect_to another_path, :catastrophe => e.message  endend# app/views/layouts/application.html.erb<div class="error"><%= error %></div><div class="catastrophe"><%= catastrophe %></div>

Deprecated Finders

Rails 4 deprecates the old-style finder option hashes, as well as all dynamic finder methods (with the exception of find_by_... and find_by_...). Instead, you’ll use where:

• find_all_by_... can be rewritten using where(...).
• find_last_by_... can be rewritten using where(...).last.
• scoped_by_... can be rewritten using where(...).
• find_or_initialize_by_... can be rewritten using where(...).first_or_initialize.
• find_or_create_by_... can be rewritten using find_or_create_by(...) or where(...).first_or_create.
• find_or_create_by_...! can be rewritten using find_or_create_by!(...) or where(...).first_or_create!.

The deprecated finders gem will be included as a dependency in 4.0. and removed in 4.1. The gem, however, will be around and maintained until 5.0.

Routing Concerns

Routing Concerns is an attempt to DRY up your config/routes.rb. The basic idea is to define common sub-resources (like comments) as concerns and include them in other resources/routes. Here’s the obvious example:

concern :commentable do  resources :commentsendconcern :remarkable do  resources :remarksendresources :posts, :concerns => :commentable  resources :articles, :concerns => [:commentable, :remarkable] # can include several  

The above is equivalent to the following Rails 3 code:

resources :posts do  resources :commentsendresources :articles do  resources :comments  resources :remarksend

Personally, I’m not sure this adds much value; perhaps it makes sense for large applications with hundreds of routes.

Renamed Callbacks

Action callbacks in controllers have been renamed from *_filter to *_action. For example:

class UsersController < ApplicationController  before_action :set_user, :except => [:index, :new, :create}  before_action :require_the_president, :only => [:fire_the_missiles]  private  def set_user    @user = somehow_find_and_set_the_user(params[:id])  end  def require_the_president    @user.is_the_president?  endend

The old *_filter callbacks still work and are not deprecated; so, you can still use them if you wish. DHH’s reason for the change was:

“To avoid the misconception that these callbacks are only suited for transforming or halting the response. With the new style, it’s more inviting to use them as they were intended, such as setting shared ivars for views.”

Wrapping Up

Rails 4 is coming, bringing with it a slew of changes. I hope that this article has given you a sense of what to expect, and perhaps a launching point into investigating what this new version has to offer.

If you really want to wade into the deep end, check out our Tuts+ Premium course on Rails 4!