Three helpful Rails console tips

The topic is a free translation of the article on 37signals .

Yesterday, I delved into the Rails API documentation and noticed some useful features of the console rails, which I had not seen before . There have been many publications on irb and Rails before, but I hope that you will learn something new from this one. The examples above are made using Basecamp Next on Rails version 3.2.3.

Immerse yourself in your app.

Using the app method in the console creates an instance of the session, as a result of which you can use the capabilities of the usual integration test .
')
>> app.class
=> ActionDispatch::Integration::Session

To form routes has always been stressful. What module was there to connect? Did you remember to specify default_url_options? Stop google and just use the app:

>> app.project_path(Project.first)
=> "/projects/130349783-with-attachments"

It can also create queries within the application:

>> app.get "/735644780/projects/605816632-bcx.atom"
=> 200

>> app.response.body
=> "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<feed xml:lang=\"en-US\" ...

Look at ActionDispatch :: Integration :: Session and ActionDispatch :: Integration :: RequestHelpers to find out how this object can be useful.

Try helper

Linking a console session with Rails helpers is also painful, but the helper can fix it! You can also use it to play with the creation of HTML tags or any other Rails helper that ActionView knows about.

>> helper.truncate("Testing", length: 4)
=> "T..."

>> helper.link_to "Home", app.root_path
=> "Home"

Another helper idea is to use instance variables inside the helper method. Yes, I know that this is a Bad Idea ™ for helpers as a whole, but none of my Rails applications have done without it. Here is a small example of the method:

def title_tag(title = nil)
if @project.present? && title.nil?
content_tag :title, @project.name
elsif @project.present?
content_tag :title, "#{@project.name}: #{title}"
else
content_tag :title, title
end
end

You can use the help of an old buddy of Object # instance_variable_set to break the basic principle of OOP, let’s try the helper in the console:

>> helper.title_tag "Testing!"
=> "Testing!"

>> helper.instance_variable_set :@project, Project.first
=> #<Project id: 130349783, ...

>> helper.title_tag
=> "With attachments!"

>> helper.title_tag "Posts"
=> "With attachments!: Posts"

Working with a helper using params is also not too easy. However, with a tiny hack, we can make ActionView obey us. This is the console, after all! Suppose we have a helper method:

def javascript_debugging_options
if params[:javascript_debugging] == "enabled"
{ debug: true, digest: false }
else
{}
end
end

Typically, ActionView requires the entire ActionDispatch :: Request from the controller to determine which parameters came from the user. You can trick it using a small OpenStruct :

>> helper.controller = OpenStruct.new(params: {})
=> #<OpenStruct params={}>

>> helper.javascript_debugging_options
=> {}

>> helper.controller = OpenStruct.new(params: {javascript_debugging: "enabled"})
=> #<OpenStruct params={:javascript_debugging=>"enabled"}>

>> helper.javascript_debugging_options
=> {:debug=>true, :digest=>false}

Where did this method come from?

Track the exact location of the desired method is not always easy. Fortunately, Ruby can point in the right direction with Method # source_location:

>> Project.instance_method(:trash).source_location
=> ["/Users/qrush/37s/apps/bcx/app/models/project.rb", 90]

Whoa! You will get an array containing the full path to the method, along with the line number of this method in the file.

I used it when I was looking for a code buried deep in gems. Let's check on the app:

>> app.method(:get).source_location
=> ["/Users/qrush/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/rails-7d95b814583b/actionpack/lib/action_dispatch/testing/integration.rb", 32]

This method has saved me from the immense number of dives in the source. Use!