I'v seen some larger emberjs implementations like discourse: https://github.com/discourse/discourse/tree/master/app/assets/javascripts/discourse
Can someone explain to me how this gets integration into rails?
What happens behind the scenes when the asset gets compiled? To the files just get minified and merged or there is more to it?
You need to read about Asset Pipeline.
The directory you linked to above is included by the various require lines in app/assets/javascripts/main_include.js, which is itself included by app/assets/javascripts/application.js.erb.
The gem doing the heavy lifting (the one responsible for interpreting the require lines) is Sprockets.
What happens behind the scenes when the asset gets compiled? To the files just get minified and merged or there is more to it?
Between the asset pipeline docs and sprockets' docs, your very general question should be more than answered. In a nutshell, yes, the files are minified and merged, and yes there is a whole lot more to it.
In addition to reading about the Asset Pipeline and Sprockets (which handle JS minification, etc), also take a look at the ember-rails gem: https://github.com/emberjs/ember-rails
ember-rails allows you to include Ember.JS into your Rails 3.1+ application. The gem will also pre-compile your handlebars templates when building your asset pipeline. It includes development and production copies of Ember.
Related
I'm working on using a Grunt workflow to manage my assets in my Rails app rather than Sprockets.
So far, I have my apps JS and CSS both being concatenated and minified into public/assets/javascripts/application.js and public/assets/stylesheets/application.css respectively.
And also have my Bower components JS and CSS being concatenated and minified into public/assets/javascripts/vendor.js and public/assets/stylesheets/vendor.css respectively.
Fonts and Images from Bower components are then copied into public/assets/(images|fonts).
This is all well and good but now I need the references to fonts/images within those files to be updated to reflect their new location.
I have looked at cssmin and yes it rewrites file references but I cannot get the file path to change depending upon the type of file being referenced.
Any ideas on how I can do this?
Also, I ahve been reading about Grunt plugins which can read your view files and use those to minify and concatenate files and update the and tags in the views for you.
Surely I can't do that in a Rails app? Is there a way I can deal with this in Rails?
This other StackOverflow post may be of help:
Integrate Grunt into Rails asset pipeline
The accepted answer recommends using the Half Pipe gem.
The second answer linked to a blog post about a Do-It Yourself solution: Goodbye, Sprockets! A Grunt-based Rails Asset Pipeline.
I haven't used either solution, but they are worth a try.
I've found several sites online that explain the DIR structure of a Rails app, but I'm still not clear on a few, mainly:
/vendor
/lib
/public
What should go where? I want to know the best practice. For example, I have jQuery plugins, should those be located in /vendor? /public? /lib? I've read all 3 from different sites online.
Thanks
Vendor is third party code / libraries, so, yes, a good place for jQuery plugins.
Public is for static assets, stuff that gets no benefit from being in the asset pipeline.
Lib is generally used to contain your code that is not specific to the app. i.e. stuff you use in multiple apps. There is a trend to put domain logic in lib e.g. domain classes not based on ActiveModel. Gary Bernhardt (https://www.destroyallsoftware.com/) is a proponent of this.
Typically the contents of /public are directly served by the web server (nginx, apache etc.) without intervention from rails, so traditionally all of your static assets (images, stylesheets, javascripts etc.) went in here. You can still put your javascript in there but it's a bit old fashioned.
Rails 3.1 introduced the asset pipeline which changed all of this. Assets in app/assets, lib/assets and vendor/assets all get servers up by the asset pipeline. Normally your application specific assets would go in app/assets and 3rd party libraries (such as a query plugin) would go in vendor/assets. If you were developing your own set of jquery plugins you might put them in lib/assets. Assets will 'work' no matter where you put them though - it's just a question of organisation.
Gems can also have their own asset folders, for example the jquery-rails gem bundles jquery and allows your app to serve up jquery without actually copying it into your app. I find this even neater than putting things in vendor/assets.
I'm serving a semi-static site with rails, just to get used to rails conventions.
Do I really need to use the asset pipeline to serve the .css and .js?
I could always precompile my .scss and coffee-script before their on the server.
and by semi-static, I mean that I may include some gems to do syntax highlighting or some other little tasks.
I guess it would be good practice?
I'm super new to rails and programming in general, by the way.
I just want another opinion.
Thanks, in advance.
You should use the asset pipeline if you are using rails 3.1 or above. It is far faster than the previous serving of assets in rails -- among other things, it munges and minifies the files.
You should always precompile your assets in production, whether or not you are using straight .css or .scss because if you don't precompile your assets, rails will still have to compile them at runtime.
I've used jammit to do my asset packaging so far, but my next application will be in Rails 3.1
Should/Can I still use Jammit? Or should I work with the built-in asset pipeline?
You can still use Jammit, but the built in asset pipeline is The Rails Way™.
I'd recommend you try out the asset pipeline/Sprockets - if you don't like it, it's as simple as moving the javascript and css files back to the public directory and setting up Jammit the old way.
I found that setting up the asset pipeline the first time around for browser specific css was a little non-intuitive, but, that was just me being unfamiliar with the whole process. Sprockets works well and allows you to use ERB/HAML with your coffee script or sass (if you want.)
Because a jQuery plugin I use in my application has direct references to images, I'm trying to turn off asset fingerprinting.
So I set config.assets.digest = false in my production.rb, but now none of my image references work at all. /assets/foo.png just returns a blank response.
I really don't want to alter the jQuery plugin's code and add erb image helpers, but I'm not sure what else to do. And frankly, the asset fingerprinting for images seems to be much more trouble than it's worth.
Does anybody have any insight?
Thanks!
Someone made a gem for this purpose:
https://github.com/spohlenz/digestion
The asset pipeline is a great new component of Rails 3.1. However it
has a feature known as fingerprinting that makes it impossible to
properly incorporate many popular JavaScript libraries (including
TinyMCE, CKEditor and FancyZoom to name just a few) into the asset
pipeline.
This gem patches the asset pipeline to allow these libraries to be
used, by disabling the fingerprinting functionality for specific files
or paths.
If you are using a large plugin, like ckeditor, then your only real option is to move that plugin into the public directory.
For smaller plugins you can move their images into the correct asset path. For example if your plugin references images/icon.jpg under the plugin folder this would need to be moved to something like app/assets/images/plugin_name/icon.png and then referenced in the plugin with <%= asset_tag('plugin_name/icon.png') %>.
The pipeline IS worth it. Not using digests in production pretty much negates the point of using it at all, which is to set far-future headers so that the asset gets cached somewhere.
If you are set on removing digests then you must precompile the assets (so that Sprockets does not serve them with far-future headers), and make sure no headers are set on the server.