Simple, user-friendly cancel links for your Rails forms

The default Rails view generator includes back links on form-related view templates, so if users change their mind they can easily get out of the form and on to something else. However, these links are static. What do you do if you allow users to access the form from multiple views (say, an index and a show).

Here’s a simple but effective solution I came up with: Instead of passing a static URL, I pass the HTTP referrer environment variable as the location. That way users are taken back to the page from which they opened the form to begin with.

Here’s how it works. Most of the code resides in the application_helper.rb file:

  module ApplicationHelper
    include Rails.application.routes.url_helpers

    def cancel_link
      return link_to 'Cancel', request.env["HTTP_REFERER"], 
        :class => 'cancel', 
        :confirm => 'Are you sure? Any changes will be lost.'
    end
  end

You’ll need to include Rails.application.routes.url_helpers in order to access link_to from a helper method. Then you add the helper method itself, which does nothing more than return a cancel link. Mine uses an old-style :confirm message; you can spruce it up with some less obtrusive if you’d like.

If I need a cancel link in a view, I just add

  <%= cancel_link %>

The result: a flexible, reusable cancel option that’s much more user-friendly.

Counter Cache in Rails - Performance Tuning

If you need to display the record count for a has_many association, you can improve performance by caching that number in a column.

Below we have an application that shows a list of projects along with the number of tasks that each project has.

What is eager loading?

Eager loading is a great optimization strategy to reduce the number of queries that are made against the DB.

Say you are finding 10 employees and then you are looking for their post codes. Then your query would appear something like this:

clients = Client.limit(10)
clients.each do |client|
  puts client.address.postcode
end

This may seem fine at first look but really this implementation leaves much to be desired. It makes 11 DB calls just to get the results.

Now you can optimize this query by making a slight change in the request like this:

clients = Client.includes(:address).limit(10)
clients.each do |client|
  puts client.address.postcode
end 

This new request makes two SQL calls like this:

SELECT * FROM clients LIMIT 10
SELECT addresses.* FROM addresses
    WHERE (addresses.client_id IN (1,2,3,4,5,6,7,8,9,10))

So, as you can see it really loads a lot more upfront and therefore it is called eager loading.