I have several javascript (coffee script) files in my Rails javascripts directory. The code is logically divided into different files. However, each file starts with $(document).ready -> and some files share common helper functions.
What is the best way to factor out the helper functions? Should I just put them all in some other file that gets included earlier in application.js?
Also, is it normal to have the code divided up the way mine is, where every page does $(document).ready ->? Doesn’t this mean that all of my code is called on every page, regardless of whether or not it is relevant? Are there alternatives to this organization?
I’m not sure if this question is specific to Rails or relevant to javascript and jQuery in general.
I do think this is a Rails question, and a good one.
The normal paradigm in Rails, where “global” stuff goes in
application.*is a little messed up with the asset pipeline, since the application.js really acts as a manifest, rather than a common file. Of course you could add stuff there, or even create anapplication.js.coffeefor your common code. I decided to create a file calledcommon.js.coffee(and in another caseshared.js.coffee), which in my case was automatically handled by therequire_tree .directive.(Update based on comment from @jonathan-tran) In some cases, you may just want methods called on document ready for all pages — for example, I used this to make a datepicker available to any field in any view. If, instead you want methods (actually global functions) available to be callable, you’ll need to export the coffeescript functions to variables, for example by attaching to the
windowobject. You can do both in a shared file.It is true that if you use generators you’ll end up with files for every controller which, if there’s no specialized code result in a series of redundant
$(document).ready ->statements when assets are compiled. So just get rid of the ones you don’t use. But following the pattern of separating functionality specific to a page makes good sense to me and works well — I know where to look to find stuff and that’s worth a lot as a project grows.And another rule I have learned with Rails: go with the flow. If that’s how Rails does it, it’s probably a good way. They do indeed think about these things. Don’t fix what works 🙂