Page specific javascript files in Rails 3.1

Question

I've been doing research on this:

Using Rails 3.1, where do you put your "page specific" javascript code?

But I have yet to see a satisfactory answer, which also makes me question whether I'm doing something wrong.

Here's my mental model: for different views, I'm going to have different

$(document).ready(....)

blocks, that obviously reference elements that are very specific to that page. I don't want to pollute things by loading that code for every single page and somehow trying to figure out how to only execute it when on specific pages; that seems pretty ugly.

My intuition, admittedly not backed up by any preliminary experiments, is that the ideal thing would be to:

1. Load application wide code from application.js.
2. Load shared controller code from something like assets/controller_name/shared.js
3. Load view-specific code from something like assets/controller_name/show.js

Off the top of my head. The helper would, the first time it ran, check if the file exists and, if so, do a javascript_include for it.

Perhaps this has some performance issues compared to the "let's just wrap the whole thing up in a big sticky ball and send it all" approach, but seems like a better approach to compartmentalizing code.

However, as above, I get the feeling I'm missing something. Is $(document).ready on a per-page basis a bad idea? Should that just be in the template and call a page specific bit of JS from application.js? The linked article above comes to that conclusion, but I don't like the image I'm getting in my head of one huge $(document).ready riddled with if this, if that, if the other thing.

Answer 1

Background

(Why Use The Asset Pipeline At All?)

One of the basic premises behind the Rails asset pipeline is the idea that it is preferable to load all the JS and CSS for a site up front once, and then cache them indefinitely (at least until the site is updated). The Asset Pipeline allows you to do this relatively automatically while still organizing your JS and CSS src files in a logical fashion.

This of course carries an upfront load cost, at the promise of saving time on additional roundtrips loading individual files. If that premise doesn't sit well then the asset pipeline is probably not for you.

The Nut Of The Problem

Ok, so we want to combine all our JS into one file to load it more efficiently. Just because we are going to load all of our JS doesn't mean we want to run all of our JS.

In the reality of a complex webapp you will probably have lots of page specific functionality that you won't want to spend resources executing when the user is not viewing the corresponding page. What we need is a uniform strategy for executing only the portion of our big monolithic JS file that is applicable to the current page.

Convention To The Rescue

I'm not aware of an official Rails strategy to deal with this, but there are some great solutions that establish and then leverage a good convention (which makes things feel "railsy"). The general idea is to define all your page specific JS code into an object literal, and then run only the code relevant to the current page on load.

For the specifics great strategy on how to organize and conditionally execute your JS code, see the answer by @welldan97 on this question:
Using Rails 3.1, where do you put your "page specific" javascript code?

which in turn is based on this article by Jason Garber:
http://viget.com/inspire/extending-paul-irishs-comprehensive-dom-ready-execution

Answer 2

What you propose is sound, but not the rails 3.1 way.

They say to divide the JS into many files, but serve as a whole single piece to the user. This allows better performance and scalability, so is a good thing if the final big piece of mud is not so big. Really 3 http requests give worse performance than 1 http request.

So you have already dipartimentized your code, because you have different Coffeescript files, which have different scopes.

To load in your app, just standardize a way to initialize the single piece of code, like calling a "myapp.users.init()" method-.

You could even automatize that peace of code using an helper, so it will be transparent for the controller.