rails best practices where to place unobtrusive javascript
Asked Answered
L

3

31

my rails applications (all 2.3.5) use a total mix of inline javascript, rjs, prototype and jquery. Let's call it learning or growing pains. Lately i have been more and more infatuated with unobtrusive javascript. It makes your html clean, in the same way css cleaned it up.

But most examples i have seen are small examples, and they put all javascript(jquery) inside application.js

Now i have a pretty big application, and i am thinking up ways to structure my js. I like somehow that my script is still close to the view, so i am thinking something like

orders.html.erb
orders.js

where orders.js contains the unobtrusive javascript specific to that view. But maybe that's just me being too conservative :)

I have read some posts by Yehuda Katz about this very problem here and here, where he tackles this problem. It will go through your js-files and only load those relevant to your view. But alas i can't find a current implementation.

So my questions:

  • how do you best structure your unobtrusive javascript; manage your code, how do you make sure that it is obvious from the html what something is supposed to do. I guess good class names go a long way :)
  • how do you arrange your files, load them all in? just a few? do you use content_for :script or javascript_include_tag in your view to load the relevant scripts. Or ... ?
  • do you write very generic functions (like a delete), with parameters (add extra attributes?), or do you write very specific functions (DRY?). I know in Rails 3 there is a standard set, and everything is unobtrusive there. But how to start in Rails 2.3.5?

In short: what are the best practices for doing unobtrusive javascript in rails? :)

Lauralauraceous answered 23/5, 2010 at 11:31 Comment(0)
B
10

I do not think there is one best practice, but I'll let you know what I do.

  1. I have a series of js files each for with their own purpose in the public/javascripts/ directory. Some examples could be utility.js chat.js shopping_basket.js and so on.

  2. I use asset packager and define one big fat collection for all my general use functionality and another for admin only functionality. Round trips to the server cost way too much. I basically include all the js in on first page load minified into one blob (in general)

  3. I allow basic $(document).ready hooks inline in the pages, and keep them really short.

  4. Data that my js files needs to access is rendered inline with the page. (Usually in the DOM, sometimes as vars - Eg. var xyz = 100)

  5. I will usually develop my controllers with javascript off (and make sure it all works), then I turn it on and sprinkle a few if request.xhr? where needed.


Keep in mind, Rail 3.1 introduces a built-in best practice, see: http://guides.rubyonrails.org/asset_pipeline.html - on a personal note I have had performance and configuration issues with the new pipeline, however many others have had great success with it.

Brad answered 23/5, 2010 at 13:29 Comment(1)
This is very interesting. Complete. I am still interested what others have to say.Lauralauraceous
D
3

I recently documented how I have been managing javascript in Ruby on Rails. I basically break things down into many small, granular files, each with an appropriate namespace and then merge them all into a single file for production using asset_packager.

Dissected answered 29/5, 2010 at 13:16 Comment(1)
I like how you can automatically load a .js file with the same name as your controller for your views. That seems a good start at least :)Lauralauraceous
S
1

I found this post while trying to solve the same problem, but none of the existing solutions struck me as the right one. I wrote up my approach here. I love Rails' convention over configuration, so I wanted the same approach to including Javascripts that are applicable only to a particular action page. If nothing else, it's at least another approach to add to your options.

Spital answered 18/10, 2010 at 14:24 Comment(1)
I really like your suggestion, and it is very close to what i would really like. What i now do is seperate the js in files per controller anyway, but then chuck in one big combined js because that loads quicker (1 big js instead of ton of seperate files).Lauralauraceous

© 2022 - 2024 — McMap. All rights reserved.