Using Rails 3.1, where do you put your “page specific” JavaScript code?

Using Rails 3.1, where do you put your “page specific” JavaScript code?

To my understanding, all of your JavaScript gets merged into 1 file. Rails does this by default when it adds //= require_tree . to the bottom of your application.js manifest file.
This sounds like a real life-saver, but I am a little concerned about page-specific JavaScript code. Does this code get executed on every page? The last thing I want is for all of my objects to be instantiated for every page when they are only needed on 1 page.
Also, isn’t there potential for code that clashes too?
Or do you put a small script tag at the bottom of the page that just calls into a method that executes the javascript code for the page?
Do you no longer need require.js then?
Thanks
EDIT: I appreciate all the answers… and I don’t think they are really getting at the problem. Some of them are about styling and don’t seem to relate… and others just mention javascript_include_tag… which I know exists (obviously…) but it would appear that the Rails 3.1 way going forward is to wrap up all of your JavaScript into 1 file rather than loading individual JavaScript at the bottom of each page.
The best solution I can come up with is to wrap certain features in div tags with ids or classes. In the JavaScript code, you just check if the id or class is on the page, and if it is, you run the JavaScript code that is associated with it. This way if the dynamic element is not on the page, the JavaScript code doesn’t run – even though it’s been included in the massive application.js file packaged by Sprockets.
My above solution has the benefit that if a search box is included on 8 of the 100 pages, it will run on only those 8 pages. You also won’t have to include the same code on 8 of the pages on the site. In fact, you’ll never have to include manual script tags on your site anywhere ever again.
I think this is the actual answer to my question.

Solutions/Answers:

Solution 1:

The Asset Pipeline docs suggest how to do controller-specific JS:

For example, if a ProjectsController is generated, there will be a new file at app/assets/javascripts/projects.js.coffee and another at app/assets/stylesheets/projects.css.scss. You should put any JavaScript or CSS unique to a controller inside their respective asset files, as these files can then be loaded just for these controllers with lines such as <%= javascript_include_tag params[:controller] %> or <%= stylesheet_link_tag params[:controller] %>.

Link to: asset_pipeline

Solution 2:

For the page-specific js you can use Garber-Irish solution.

So your Rails javascripts folder might look like this for two controllers – cars and users:

javascripts/
├── application.js
├── init.js
├── markup_based_js_execution
├── cars
│   ├── init .js
│   ├── index.js
│   └── ...
└── users
    └── ...

And javascripts will look like this:

// application.js

//= 
//= require init.js
//= require_tree cars
//= require_tree users

// init.js

SITENAME = new Object();
SITENAME.cars = new Object;
SITENAME.users = new Object;

SITENAME.common.init = function (){
  // Your js code for all pages here
}

// cars/init.js

SITENAME.cars.init = function (){
  // Your js code for the cars controller here
}

// cars/index.js

SITENAME.cars.index = function (){
  // Your js code for the index method of the cars controller
}

and markup_based_js_execution will contain code for UTIL object, and on DOM-ready UTIL.init execution.

And don’t forget to put this to your layout file:

<body data-controller="<%= controller_name %>" data-action="<%= action_name %>">

I also think that it is better to use classes instead of data-* attributes, for the better page-specific css. As Jason Garber have mentioned: page-specific CSS selectors can get really awkward (when you use data-*attributes)

I hope this will help you.

Solution 3:

I see that you’ve answered your own question, but here’s another option:

Basically, you’re making the assumption that

//= require_tree .

is required. It’s not. Feel free to remove it. In my current application, the first I’m doing with 3.1.x honestly, I’ve made three different top level JS files. My application.js file only has

//= require jquery
//= require jquery_ujs
//= require_directory .
//= require_directory ./api
//= require_directory ./admin

This way, I can create subdirectories, with their own top level JS files, that only include what I need.

The keys are:

  1. You can remove require_tree – Rails lets you change the assumptions it makes
  2. There’s nothing special about the name application.js – any file in the assets/javascript subdirectory can include pre-processor directives with //=

Hope that helps and adds some details to ClosureCowboy’s answer.

Sujal

Solution 4:

Another option: to create page- or model-specific files, you could create directories inside your assets/javascripts/ folder.

assets/javascripts/global/
assets/javascripts/cupcakes
assets/javascripts/something_else_specific

Your main application.js manifest file could be configured to load its files from global/. Specific pages or groups of pages could have their own manifests which load files from their own specific directories. Sprockets will automatically combine the files loaded by application.js with your page-specific files, which allows this solution to work.

This technique can be used for style_sheets/ as well.

Solution 5:

I appreciate all the answers… and I don’t think they are really getting at the problem. Some of them are about styling and don’t seem to relate… and others just mention javascript_include_tag… which I know exists (obviously…) but it would appear that the Rails 3.1 way going forward is to wrap up all of your Javascript into 1 file rather than loading individual Javascript at the bottom of each page.

The best solution I can come up with is to wrap certain features in div tags with ids or classes. In the javascript code. Then you just check if the id or class is on the page, and if it is, you run the javascript code that is associated with it. This way if the dynamic element is not on the page, the javascript code doesn’t run – even though it’s been included in the massive application.js file packaged by Sprockets.

My above solution has the benefit that if a search box is included on 8 of the 100 pages, it will run on only those 8 pages. You also won’t have to include the same code on 8 of the pages on the site. In fact, you’ll never have to include manual script tags on your site anywhere ever again – except to maybe preload data.

I think this is the actual answer to my question.

Solution 6:

I realize I’m coming to this party a bit late, but I wanted to throw in a solution that I’ve been using lately. However, let me first mention…

The Rails 3.1/3.2 Way (No, sir. I don’t like it.)

See: http://guides.rubyonrails.org/asset_pipeline.html#how-to-use-the-asset-pipeline

I’m including the following for the sake of completeness in this answer, and because it’s not an unviable solution… though I don’t care much for it.

The “Rails Way” is a controller-oriented solution, rather than being view-oriented as the original author of this question requested. There are controller-specific JS files named after their respective controllers. All of these files are placed in a folder tree that is NOT included by default in any of the application.js require directives.

To include controller-specific code, the following is added to a view.

<%= javascript_include_tag params[:controller] %>

I loathe this solution, but it’s there and it’s quick. Presumably, you could instead call these files something like “people-index.js” and “people-show.js” and then use something like "#{params[:controller]}-index" to get a view-oriented solution. Again, quick fix, but it doesn’t sit well with me.

My Data Attribute Way

Call me crazy, but I want ALL of my JS compiled and minified into application.js when I deploy. I don’t want to have to remember to include these little straggler files all over the place.

I load all of my JS in one compact, soon-to-be browser cached, file. If a certain piece of my application.js needs to be fired on a page, I let the HTML tell me, not Rails.

Rather than locking my JS to specific element IDs or littering my HTML with marker classes, I use a custom data attribute called data-jstags.

<input name="search" data-jstag="auto-suggest hint" />

On each page, I use – insert preferred JS library method here – to run code when the DOM has finished loading. This bootstrapping code performs the following actions:

  1. Iterate over all elements in the DOM marked with data-jstag
  2. For each element, split the attribute value on space, creating an array of tag strings.
  3. For each tag string, perform a lookup in a Hash for that tag.
  4. If a matching key is found, run the function that is associated with it, passing the element as a parameter.

So say I have the following defined somewhere in my application.js:

function my_autosuggest_init(element) {
  /* Add events to watch input and make suggestions... */
}

function my_hint_init(element) {
  /* Add events to show a hint on change/blur when blank... */
  /* Yes, I know HTML 5 can do this natively with attributes. */
}

var JSTags = {
  'auto-suggest': my_autosuggest_init,
  'hint': my_hint_init
};

The bootstrapping event is going to apply the my_autosuggest_init and my_hint_init functions against the search input, turning it into an input that displays a list of suggestions while the user types, as well as providing some kind of input hint when the input is left blank and unfocused.

Unless some element is tagged with data-jstag="auto-suggest", the auto-suggest code never fires. However, it’s always there, minified and eventually cached in my application.js for those times that I need it on a page.

If you need to pass additional parameters to your tagged JS functions, you’ll have to apply some creativity. Either add data-paramter attributes, come up with some kind of parameter syntax, or even use a hybrid approach.

Even if I have some complicated workflow that seems controller-specific, I will just create a file for it in my lib folder, pack it into application.js, and tag it with something like ‘new-thing-wizard’. When my bootstrap hits that tag, my nice, fancy wizard will be instantiated and run. It runs for that controller’s view(s) when needed, but is not otherwise coupled to the controller. In fact, if I code my wizard right, I might be able to provide all configuration data in the views and therefore be able to re-use my wizard later for any other controller that needs it.

Anyway, this is how I’ve been implementing page specific JS for a while now, and it has served me well both for simple site designs and for more complex/rich applications. Hopefully one of the two solutions I’ve presented here, my way or the Rails way, is helpful to anyone who comes across this question in the future.