ChatGPT解决这个技术问题 Extra ChatGPT

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.

"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."—Only becase the Rails core team is, and has always been, really bad at knowing how to manage JavaScript. Small files are generally better (see my comments elsewhere). When it comes to JavaScript, the Rails way is rarely the right way (except for the asset pipeline, which kicks ass, and the encouragement of CoffeeScript).
So you'll include your page-specific js files on every page? I think that's a waste, I agree more with ClosureCowboy's answer.
Did you have a look at the accepted answer for this question? stackoverflow.com/questions/6571753/…
@DutGRIFF In other words: no, it's not best to do things the Rails way in this case (or at least, don't put everything in application.js), and in fact the reference you supplied points out why this is so: downloading is the slowest part of the JS execution process. Many little files are more cacheable than one big one. The Unholy Rails folks don't seem to realize, then, that their recommendations are inconsistent with the principles they're trying to adhere to, and therefore their recommendations should not be taken seriously.
@DutGRIFF No, a large JS file would not normally be a good thing even once cached. See my comments elsewhere on this page: small files can target specific pages better, and can be cached at a finer granularity. I don't see any good use case for a single large file unless there is no page-specific code at all.

a
ankit suthar

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


This is the most elegant way to do it. But also, you will need to remove the line //= require_tree . from the application.js.coffee
I totally agree with this method. The other methods seem very clunky and still end up loading a giant js file. The project im working on has almost 2mb worth of JS files / plugins etc AFTER being combined / minified.
I'm fairly new to Rails, but it seems to me that this should be the default behavior.
For action specific control I have this in my layout, as not every action for every controller has specific JS. page_specific_js = "#{params[:controller]}_#{params[:action]}" and then; javascript_include_tag page_specific_js if Rails.application.assets.find_asset page_specific_js
Do the controller specific actions still get minified? Are they added to the single js file that is created by sprockets, or elk this lead to multiple requests for asset files?
C
Chandru

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.


What if you need a variable available to all actions in the users controller, but not available in other controllers? Doesn't this method have some scoping issues?
@tybro0103, I think to implement this behavior you would like to write something like window.varForOneController='val' in this controller init function. Also gon gem can help here(github.com/gazay/gon). There can be other workarounds.
@welldan97 Downvoting not for your explanation -- which is excellent -- but because the Garber-Irish structure is evil. It loads all your JS on every page, and depends on classes and IDs on the <body> element to sort things out. That's a sure sign of fighting the DOM: under normal circumstances the <body> element should not need a class or ID, since there's only ever one in a document. The proper way to do this is simply to remove the //= require_tree . and use page-specific JavaScript. If you're actively trying not to do that, then you're striving for bad practice.
@MarnenLaibow-Koser Personally I believe that loading all js on every page is good for the most projects when you combine all js into one file and minimize it. I believe it overall works faster for user. At least its more like conflict one js file vs many(i.e. look at stackoverflow.com/questions/555696/…). Also there is nothing bad in using classes and ids on body if it makes code simpler and works for you. Modernizr(modernizr.com) does this, and some other libs too.
@MarnenLaibow-Koser the rails asset pipeline, to me, seems like a good candidate for comparison with compilation. A programmer writes their javascript in nice decoupled modules, and then it is lumped together, minified, and served. Just as in the case of compiled languages, there will always be programmers who think they are a step ahead of the compiler... but I think this is rarely true.
O
Outside_Box

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:

You can remove require_tree - Rails lets you change the assumptions it makes 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


+1 This is great to know for a newbie like me. I'd give it +2 if I could.
@sujal Exactly. The Rails core team is notorious for abysmal JavaScript management. Feel free to ignore their suggestions and just use the good parts of the asset pipeline. :)
Thanks a lot for this advice. I not have several "top-level" JS files, depending on the module of my app. Works well.
+1 The important point here for me is that you can replace //= require_tree . with //= require_directory . so you can keep all existing files where they are and create new directories for page specific files.
C
Ciro Santilli Путлер Капут 六四事

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.


You've made me crave cupcakes now.. Dangit!
I really like this solution. The only problem I have with it is that those extra manifests are not compressed/uglified. They are properly compiled though. Is there a solution or am I missing something?
does this mean that the browser loads one js file, that is a combination of global + page specific file?
Could you take a look at my question if your available? stackoverflow.com/questions/17055213/…
@clst I believe this is the answer you're looking for: guides.rubyonrails.org/asset_pipeline.html#precompiling-assets
F
Fire Emblem

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.


But you actually want those manual <script> tags. Yes, classes and ids are part of the answer, but it makes no sense for the user to load JavaScript that that particular page does not require.
@MarnenLaibow-Koser the reason for not adding manual script tags to each unique page is that you have to download that script content on every page view. If you are able to package all javascript into application.js using the asset pipeline, then the user downloads those scripts one time only, and pulls application.js from the cache on all subsequent page loads
@jakeonrails "the reason for not adding manual script tags to each unique page is that you have to download that script content on every page view"—quite wrong. The script will be downloaded once, then will be fetched from the browser's cache on further requests. "If you are able to package all javascript into application.js using the asset pipeline, then the user downloads those scripts one time only"—true, but at the cost of lots of unnecessary code. If you can structure your JS into many little files instead of one big one, you get caching benefits without unnecessary code.
@MarnenLaibow-Koser I think it would have been better to say that if you package everything into one script, your user only has to download 1 script for any page of your site. If you have multiple scripts for different parts of your app, then obviously the user must download more than one script. Both methods will be cached, of course, but in most cases (small-medium apps), serving one application.js one time will be more efficient for downloading. Parsing of the JS may be another story, depending on what you serve up.
@Ziggy Also, if the small file is only used on 8 out of 100 pages, why should the code sit in the user's cache all the time? Better to actually drop the stuff that's not needed.
R
Ryan

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:

Iterate over all elements in the DOM marked with data-jstag For each element, split the attribute value on space, creating an array of tag strings. For each tag string, perform a lookup in a Hash for that tag. 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.


One little detail: there's this notion in your answer that once the js is browser cached, it has no impact. This isn't quite true. The browser does indeed avoid the download, if the js file is properly cached, but it still compiles the code on every page render. So, you have to balance tradeoffs. If you have a lot of JS in aggregate, but only some is used per page, you might be able to improve page times by breaking the JS apart.
For more on the practical effects of that compilation step I'm talking about, see 37 Signals' explanation of how pjax impacted Basecamp Next: 37signals.com/svn/posts/…
That's a fair point. After reading the article and looking back on projects where I've used the above solution, I realize I wrote essentially the same "send the changed HTML" solution they mention in the article. The frequent re-compiling of JS hadn't been an issue in my projects because of that. The compilation step is something I'll keep in mind when I'm working on less "desktop application" oriented sites.
Downvoting for "Call me crazy, but I want ALL of my JS compiled and minified into application.js when I deploy." You really don't want this, as it makes the user load JavaScript he doesn't need and it makes your handlers look for attributes that aren't even going to be there. Having everything in app.js is tempting, and Rails certainly makes it easy, but the proper thing to do is to modularizing JavaScript better.
You're entitled to a different opinion... and technically entitled to downvote over a difference of opinion. However, it would be nice to see some justification as to why one large and cached file is inferior to forcing multiple HTTP requests to grab modularized JS. Furthermore, you are mistaken regarding the handler search procedure. The tag values are NOT searched. Only one search is ever performed and it pulls all elements that have a data-jstag attribute. It doesn't search by tag name, it just finds all elements that have tags and then instantiates only the needed objects.
M
Mike A

This has been answered and accepted long ago, but I came up with my own solution based on some of these answers and my experience with Rails 3+.

The asset pipeline is sweet. Use it.

First, in your application.js file, remove //= require_tree.

Then in your application_controller.rb create a helper method:

helper_method :javascript_include_view_js //Or something similar

def javascript_include_view_js
    if FileTest.exists? "app/assets/javascripts/"+params[:controller]+"/"+params[:action]+".js.erb"
        return '<script src="/assets/'+params[:controller]+'/'+params[:action]+'.js.erb" type="text/javascript"></script>'
    end
end

Then in your application.html.erb layout file, add your new helper among the existing javascript includes, prefixed with the raw helper:

<head>
    <title>Your Application</title>
    <%= stylesheet_link_tag "application", :media => "all" %>
    <%= javascript_include_tag "application" %>
    <%= raw javascript_include_view_js %>
</head>

Voila, now you can easily create view-specific javascript using the same file structure you use everywhere else in rails. Simply stick your files in app/assets/:namespace/:controller/action.js.erb!

Hope that helps someone else!


Wont this cause problems after assets are precompiled and at run time the <%= raw ... %> will return a 404 ?
I think the asset pipeline is un-sweet, since it creates a bunch of files that often shouldn't be used. So for me relying on the asset pipeline is creating a dependency on an inefficient system.
@DeborahSpeece When does the asset pipeline create files that shouldn't be used? Are you confusing the asset pipeline (good) with require_tree / (bad)?
m
mcubik

You can add this line in your layout file (e.g. application.html.erb) to automatically load the controller specific javascript file (the one that was created when you generated the controller):

<%= javascript_include_tag params[:controller] %>

You also could add a line to automatically load a script file in a per-action basis.

<%= javascript_include_tag params[:controller] + "/" + params[:action] %>

Just put your page scripts into a subdirectoriy named after the controller name. In these files you could include other scripts using =require. It would be nice to create a helper to include the file only if it exists, to avoid a 404 fail in the browser.


M
Mr Bohr
<%= javascript_include_tag params[:controller] %>

This looks like it might be able to answer the question. Could you please add more to the answer to flesh it out?
p
peresleguine

Maybe you will find pluggable_js gem as suitable solution.


C
Community

The LoadJS gem is another option:

LoadJS provides a way to load page-specific Javascript code in a Rails app without loosing the magic provided by Sprockets. All your Javascript code will continue by minified in one Javascript file but some portions of it will only be executed for certain pages. https://github.com/guidomb/loadjs


R
Rahil Sondhi

Philip's answer is quite good. Here is the code to make it work:

In application.html.erb:

<body class="<%=params[:controller].parameterize%>">

Assuming your controller is called Projects, that will generate:

<body class="projects">

Then in projects.js.coffee:

jQuery ->
  if $('body.projects').length > 0  
     $('h1').click ->
       alert 'you clicked on an h1 in Projects'

Downvoting: any solution that puts a class on the <body> is ipso facto incorrect. See my comments elsewhere on this page.
Don't do this. That problem here is that every time you add one of these, you're adding another piece of js that needs to be executed on page load. Could definitely cause some performance degradation as your project grows.
y
yfeldblum

JavaScripts are only merged when you tell Rails (Sprockets, rather) to merge them.


Of course. I guess I ask because Rails' defaults includes everything in the folder... which means David intends for you to do that. But like I said in the other comment to @rubyprince, I am unsure about execution when it is done this way. I am thinking I have to disable //= require_tree . ?
@FireEmblem Yes. require_tree . is usually a bad idea.
z
zeeraw

This is how i solved the styling issue: (excuse the Haml)

%div{:id => "#{params[:controller].parameterize} #{params[:view]}"}
    = yield

This way i start all the page specific .css.sass files with:

#post
  /* Controller specific code here */
  &#index
    /* View specific code here */
  &#new
  &#edit
  &#show

This way you can easily avoid any clashes. When it comes to .js.coffee files you could just initialize elements like;

$('#post > #edit') ->
  $('form > h1').css('float', 'right')

Hope this helped some.


Read the last bit again please, for javascript you can take advantage of the same structure used for stylesheets for initializing view specific functions.
Philip, $('#post > #edit') -> seems to be invalid. How do you scope jQuery to work within a scope?
Recently I've started loading all controller specific java scripts and style sheets by calling this in the application.html.haml; = javascript_include_tag "application" and = javascript_include_tag params[:controller] this way I can keep javascript code confined without having to specify a scope inside of the file.
C
Community

You can also group the js in folders and continue to use the asset pipeline to load your javascript selectively depending on the page.


A
Adi Inbar

I agree with your answer, to check if that selector is there, use:

if ($(selector).length) {
    // Put the function that does not need to be executed every page
}

(didn't see anyone add the actual solution)


j
juanitogan

I don't see an answer that really puts it all together and lays it out for you. Thus, I'll try to put meleyal, sujal (a la ClosureCowboy), the first part of Ryan's answer, and even Gal's bold statement about Backbone.js... all together in a way that is short and clear. And, who knows, I might even meet Marnen Laibow-Koser's requirements.

Example edits

assets/javascripts/application.js

//= require jquery
//= require jquery_ujs
//= require lodash.underscore.min
...

views/layouts/application.html.erb

  ...
  </footer>

  <!-- Javascripts ================================================== -->
  <!-- Placed at the end of the document so the pages load faster -->
  <%= javascript_include_tag "application" %>
  <%= yield :javascript %>

</body>
</html>

views/foo/index.html.erb

...
<% content_for :javascript do %>
  <%= javascript_include_tag params[:controller] %>
<% end %>

assets/javascripts/foo.js

//= require moment
//= require_tree ./foostuff

assets/javascripts/foostuff/foothis.js.coffee

alert "Hello world!"

Brief description

Remove //= require_tree . from application.js and list only the JS that each page shares.

The two lines shown above in application.html.erb tell the page where to include application.js and your page-specific JS.

The three lines shown above in index.html.erb tells your view to look for some page-specific JS and include it at a named yield region called ":javascript" (or whatever you want to name it). In this example, the controller is "foo" so Rails will attempt to include "foo.js" at the :javascript yield region in the application layout.

List your page-specific JS in foo.js (or whatever the controller is named). List common libraries, a tree, directories, whatever.

Keep your custom page-specific JS someplace where you can easily reference it apart from your other custom JS. In this example, foo.js requires the foostuff tree so put your custom JS there, such as foothis.js.coffee.

There are no hard rules here. Feel free to move things around and perhaps even create multiple yield regions of various names in various layouts if needed. This just shows one possible first step forward. (I don't do it exactly like this given our use of Backbone.js. I might also choose to drop foo.js down into a folder called foo instead of foostuff but haven't decided that yet.)

Notes

You can do similar things with CSS and <%= stylesheet_link_tag params[:controller] %> but this is beyond scope of the question.

If I missed a glaring best practice here, send me a note and I'll conisder adapting. Rails is fairly new to me and, honestly, I'm not terribly impressed so far with the chaos it brings by default to enterprise development and all the traffic the average Rails program generates.


this looks like the way to go, I'm going to see if I can implement it in my own app, thanks for the detailed answer.
P
Peter Abramowitsch

I have another solution, which although primitive works fine for me and doesn't need any fancy selective loading strategies. Put in your nornal document ready function, but then test the current windows location to see if it is the page your javascript is intended for:

$(document).ready(function() {
   if(window.location.pathname.indexOf('/yourpage') != -1) {
          // the javascript you want to execute
   }
}

This still allows all the js to be loaded by rails 3.x in one small package, but does not generate much overhead or any conflicts with pages for which the js isn't intended.


G
Gal

ryguy's answer is a good answer, even though its been downvoted into negative points land.

Especially if you're using something like Backbone JS - each page has its own Backbone view. Then the erb file just has a single line of inline javascript that fires up the right backbone view class. I consider it a single line of 'glue code' and therefore the fact that its inline is OK. The advantage is that you can keep your "require_tree" which lets the browser cache all the javascript.

in show.html.erb, you'll have something like:

<% provide :javascript do %>
  <%= javascript_include_tag do %>
    (new app.views.ProjectsView({el: 'body'})).render();
  <% end %>
<% end do %>

and in your layout file, you'll need:

<%= yield :javascript %>

Downvoting. Inline JavaScript is never a good idea. Even if it's glue code, it should be in an external file.
A
Adi Inbar

Move all your commom JS files to a sub-folder like 'app/assets/javascript/global' then in the application.js, modify the //= require_tree . line to //= require_tree ./global.

Now you are free to put your controller-specific JS on the 'app/assets/javascript/' root and they will not be included in compiled JS, being used just when you call them via = javascript_include_tag on your controller/view.


No way, that's a crapload of JavaScript to load for one page. Doesn't even matter if it's cached.
o
onetwopunch

Though you have several answers here, I think your edit is probably the best bet. A design pattern that we use in our team that we got from Gitlab is the Dispatcher pattern. It does something similar to what you're talking about, however the page name is set in the body tag by rails. For example, in your layout file, just include something like (in HAML):

%body{'data-page' => "#{controller}:#{action}" }

Then only have one closure and a switch statement in your dispatcher.js.coffee file in your javascripts folder like so:

$ ->
  new Dispatcher()

class Dispatcher
  constructor: ->
    page = $('body').attr('data-page')
    switch page
      when 'products:index'
        new Products() 
      when 'users:login'
        new Login()

All you need to do in the individual files (say products.js.coffee or login.js.coffee for example) is enclose them in a class and then globalize that class symbol so you can access it in the dispatcher:

class Products
  constructor: ->
    #do stuff
@Products = Products

Gitlab has several examples of this that you might want to poke around with in case you're curious :)


z
zavg

Paloma project offers interesting approach to manage page specific javascript code.

Usage example from their docs:

var UsersController = Paloma.controller('Users'); // Executes when Rails User#new is executed. UsersController.prototype.new = function(){ alert('Hello Sexy User!' ); };


e
etlds

Step1. remove require_tree . in your application.js and application.css.

Step2. Edit your application.html.erb(by rails default) in layout folder. Add "params[:controller]" in the following tags.

<%= stylesheet_link_tag    'application', params[:controller], media: 'all', 'data-turbolinks-track' => true %>

<%= javascript_include_tag 'application', params[:controller], 'data-turbolinks-track' => true %>

Step3. Add a file in config/initializers/assets.rb

%w( controller_one controller_two controller_three ).each do |controller|
  Rails.application.config.assets.precompile += ["#{controller}.js", "#{controller}.js.coffee", "#{controller}.css", "#{controller}.scss"]
end

references: http://theflyingdeveloper.com/controller-specific-assets-with-rails-4/


Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
B
Bill Eisenhauer

I haven't tried this out, but it looks like the following is true:

if you have a content_for that is javascript (e.g. with real javascript within it), sprockets would not know about it and thus this would work the same way as it does now.

if you want to exclude a file from the big bundle of javascript, you would go into config/sprockets.yml file and modify the source_files accordingly. Then, you would just include any of the files that you excluded where needed.


Is excluding files or using custom javascript on the page itself the "right way" then? Is that how David intended people to use it?
@FireEmblem I don't much care what David intended, because I don't think David understands how to organize JavaScript properly.
E
Eddie Prislac

I did it previously using this method: http://theflyingdeveloper.com/controller-specific-assets-with-rails-4/ . Super-easy, relies on controllers to select the proper js to load.


k
kapellan

I combined some answers into:

Application helper:

module ApplicationHelper
  def js_page_specific_include
    page_specific_js = params[:controller] + '_' + params[:action]
    if Rails.application.assets.find_asset(page_specific_js).nil?
      javascript_include_tag 'application', 'data-turbolinks-track' => true
    else
      javascript_include_tag 'application', page_specific_js, 'data-turbolinks-track' => true
    end
  end
end

layouts/application.html.haml:

 <!DOCTYPE html>
%html{lang: 'uk'}
  %head   
    = stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' => true
   bla-bla-bla
    = js_page_specific_include   
   bla-bla-bla  

N
Nicollas

First: remove \\=require_treefrom application.js Second: all your JS code must be alocated at /app/assets/javascritpt and all your CSS code must be alocated at /app/assets/stylesheets


K
Kruttik

Following the lead from Ryan, here's what I have done-

application.js.coffee

$ ->
    view_method_name = $("body").data("view") + "_onload"
    eval("#{view_method_name}()") if eval("typeof #{view_method_name} == 'function'")
    view_action_method_name = $("body").data("view") + "_"+$("body").data("action")+"_onload"
    eval("#{view_action_method_name}()") if eval("typeof #{view_action_method_name} == 'function'")

users.js.coffee (controller specific coffeescript,e.g controller:users, action:dashboard)

window.users_dashboard_onload = () ->
    alert("controller action called")
window.users_onload = () ->
    alert("controller called")

application.html.haml

%body{:data=>{:view=>controller.controller_name, :action=>controller.action_name}}

Downvoting. This is ridiculously convoluted -- not to mention insecure (due to the eval) if your HTML gets compromised by a cracked server or a malicious userscript.
v
valk

Here's how to do it especially if you don't have to execute tons of libraries for your specific page, but only to run a few hundreds lines of JS more or less.

Since it's perfectly fine to embed Javascript code into HTML, just create under app/views shared.js directory and place there your page/pages specific code inside my_cool_partial.html.erb

<script type="text/javascript"> 
<!--
  var your_code_goes_here = 0;
  function etc() {
     ...
  }
-->
</script>

So now from wherever you want you simply do:

  = render :partial => 'shared.js/my_cool_partial'

And that's it, k?


Downvoting. Inline JavaScript is never advisable. HTML should only contain markup. JS and CSS should be in separate, reusable files.