The Rails guide here says
"Any assets under public will be served as static files by the
application or web server when config.serve_static_files is set to
true. You should use app/assets for files that must undergo some
pre-processing before they are served."
I'm using Rails 4.2.4. There is no public/assets folder. This leaves me wondering a few things:
What is meant by "use app/assets for files that must undergo some pre-processing before they are served?"
What is meant by pre-processing?
How is a static asset different from other assets, and what are the performance benefits of using one pipeline over the other?
Do I even need to worry about this if 4.2.4 has no public/assets folder?
Assets like javascript/css etc. need to be pre-processed - eg. minified, hashed for cache busting, passed through transpilers (like coffeescript) etc. Such assets should be kept in app/assets folder.
I believe 1 already answers that.
Passing each asset through transpilers/minifiers etc. as described in 1 during production will be very expensive and wasteful - because these assets don't change dynamically we can just do them once during pre-compilation and let static file server or cdn handle their delivery.
When you precompile your assets in deployment, the compiled files will be generated into the public/assets folder.
I recommend reading this article, which explains asset pipeline in much detail.
Related
What's considered an "asset" in the Ruby on Rails universe?
Are user generated files, such as images uploaded by the user, considered assets? Where should they be stored in the standard file structure of a Rails project? Should they be kept clear of any asset related directories like:
app/assets
lib/assets
public/assets
Relevant: The Asset Pipeline
Generally asset is anything that browser loads after it gets the HTML page. Meaning javascript, css and any images. But as you pointed out there are two different image types in a rails project.
1) the images related to your css and layout design, those go under the app/assets/images
2) the images that your users upload, those normally go into the public/system or public/uploads folder depending on what you use to receive the uploads
The lib/assets (or sometimes vendor/assets) is where you supposed to place js/css/images related to your front-end design and provided by third party libs. Say if you want to pull in some css or a js framework, that were you should place it.
And finally public/assets is where rails will compile your layout assets from the app/assets and vendor/assets folders when you run rake assets:precompile task for production.
To have it short, your design stuff goes to app/assets, and the user uploads go into public/system
User-uploaded files are not part of assets, and should definitely be kept clear of asset-related folders. You should put them somewhere in your public directory. I put mine in public/uploads, which is a common convention. And then you should ignore those files in git (or whatever VCS you're using).
Assets are basically: javascript, stylesheets, fonts, and images which are part of the site design itself, not part of the user-uploaded content.
I have compiled assets using following command in rails 3.2 for production purpose.
RAILS_ENV=production bundle exec rake assets:precompile
After running above command an assets a folder is created under public. Now I want to removed non-compile assets folder because it is huge. But I have need answers to following questions.
Do I need the assets folder that contains non-compiled assets ?
If yes then what is purpose of having a non-compiled assets folder ?
I will appreciate your help.
Yes, keep them.
The purpose is that when they are taken from assets to public they are usually minified and combined, greatly saving space and helping to reduce download time for end users when using the site. But when you need to make changes, use the originals in assets.
In development mode (local, on your box), the assets version is used and is useful in traces while developing/debugging as they point to the actual source code lines in question and have the original (usually longer and meaningful) variable names.
Most likely you will need to make changes to one of your assets in app/assets in the future.
app/assets has the original source files with original formatting and these are the files you should change.
Theoretically you could delete the source files in app/assets, but then you won't be able to change anything and re-compile with those changes.
It takes an incredibly long time (> 10min) to precompile assets since I have large iconset folders in vendor/images. This makes it really convenient for development since I have all those icons at my disposal but I use a very small number of them. For these small icons I use the asset_data_uri helper throughout my sass files.
Is there a way to have asset pipeline to not compile all of the images, and just the ones I use? Or if it could just not digest compile the images and only make them available for asset_data_uri?
Compiled assets are written to the location specified in
config.assets.prefix. By default, this is the public/assets directory.
You can update config.assets.prefix with your set of locations you want to precompile
http://guides.rubyonrails.org/asset_pipeline.html#precompiling-assets
In the Ruby on Rails guide to the Asset Pipeline, it says
Any assets under public will be served as static files by the
application or web server. You should use app/assets for files that
must undergo some pre-processing before they are served.
http://guides.rubyonrails.org/asset_pipeline.html
To me, this says that images should be kept in the public directory as they can be served statically by my web server and require no pre-processing.
Are there advantages to putting your images in assets/?
Asset precompile appends unique hash value to image filenames, which allows users to get latest version of it despite of cache or expire settings on the server. This is useful when you want to change images in website design.
You don't want to use /assets/images for images what are unlikely to change (like user uploads).
Because it would harm the versatility of the asset pipeline.
With images being served via the asset pipeline, if you change the asset pipeline (for instance, have it upload files to S3) you would have to then sync your images via some other task.
There may be other, deeper reasons, but that is what would give me pause.
EDIT:
Side note: In production thanks to assets:precompile everything from /assets/ will be served from public.
After I deployed my upgraded Rails 2.3.x -> 3.1 (rc4) app to our test environment this afternoon, all of our stylesheets and JavaScript files were returning 404 errors. We had added the rake assets:precompile task to our post-deploy script and it took a while to determine why the assets folder didn't have the pre-compiled files we expected.
In the end, the files weren't being compiled because apparently only application.css and application.js (+ non JS/CSS files) are processed by default.
We needed to change the following configuration value as follows:
config.assets.precompile += %w( *.js *.css )
Question: why isn't this the default?
I would have expected that anything that wasn't necessary to process as a manifest file would just get copied into public/assets. Much of what I've read on the asset pipeline is essentially "stick your assets in app/assets, configure the manifest files, and it should just work". Since the assets:precompile task didn't spit out any information about what it was doing, it took a while to determine that it just wasn't looking at the files we thought it would.
Is there any reason why this would not be a good value for the precompile configuration?
Thanks!
The idea is to have all your JavaScript and CSS always loaded in one shot, rather than loading bits and pieces as you move along. That way you always have the 'world' loaded and ready to work with, rather than having to include a whole bunch of individual files here and there.
It's a bit of a larger 'up front' load, but then the browser should keep loading all the javascript from cache. So the perceived speed of the site should speed up due to having everything cached and ready to go after the first request.
This was a controversial decision to include for Rails, but so is including CoffeeScript by default. Rails has always been an opinionated framework that way.
the new sprockets-based pipeline compiles all the files in /asssets/stylesheets and /assets/javascripts get compiled into application.css and application.js, respectively, by default.
In your views, you only need to link the application files, sprockets handles the rest.
Update:
Well, you don't have to make it all into just one file... You could have an shared.js, secure.js and public.js and have them each include the parts they need...
Think of them not as javascript files, but manifest files that establish groups of javascript files which you can then include as a group with a single javascript_include_tag. While the default is to include everything in the folder into a single file, you can be always pick and choose what to include, and what not.
The 'precompile' task simply runs those manifest files and compiles the multiple files into one, while pre-processing and sass or coffee script it runs across.