In every language I can think of, placing the comment decorator at the start of a line will comment out that line of code (without any exceptions).
In rails, in application.js I see some lines starting with // and others starting with //=. I presume lines starting with // are comments and those lines are not executed.
Question
What's the difference between
lines starting with //
lines starting with //= and
lines starting with neither of those decorators?
From here:
Sprockets is a Ruby library for compiling and serving web assets. Sprockets allows to organize an application’s JavaScript files into smaller more manageable chunks that can be distributed over a number of directories and files.
Also:
When it comes to asset bundling, the "Rails way" is webpack for JavaScript and Sprockets for everything else. The default setup in a fresh Rail 6 install, similar to what Basecamp uses, still compiles CSS, images, and fonts with Sprockets.
So basically
lines starting with //= is a sprocket processor directive (and it will get executed)
lines starting with // are simply comments (they won't get executed), and
lines starting with neither are javascript
Related
I'm just getting started with React in Rails.
When I come across other's Rails apps with React, I find some of them add a leading underscore when naming *.js.* files in /app/assets/javascripts/components/.
e.g. Sample React Rails App
Component files are like:
_comment.js.jsx
While some don't,
e.g. Account React Rails App
Component files are like:
record.js.coffee
So what difference does it make to add the leading underscore?
I know in Rails view, naming a *.html.erb file with leading underscore means it's a partial which you can reuse and we call render method to render it. But here the *.js.* files are require by components.js with //= require_tree ./components. So even you remove the underscore, it makes no difference. And I believe this is the only part which "reuse" the component.
As there's //= require_tree ./components in application.js. I think it really doesn't make any difference to name them with leading underscore.
Then I think there may be something to do with the Rails asset pipeline, because actually the component files are required duplicately in the sample-react-rails-app. The underscores might be for avoid duplication when precomiling.
I've tried remove the leading underscores in those file and run the app locally (also I make asset pipeline precompile in dev env). It turns out that even if you remove the leading underscores, precompilation for those files still doesn't get duplicated and the app works just fine. As a matter of fact, asset pipeline will only include the same file once even if you require the file duplicately.
In conclusion, the leading underscore doesn't make any difference in how your app works. It's probably a naming convention following partial naming like in Rails views or SASS compilation which was also mentioned in Rails Issues #3094. And Generally I think the convention is worth following to tell yourself and your team those files work as incomplete parts.
I had a Rails 4 app that was loading the css.scss files just fine. Then I did something to break it, I don't know what, and reverting to the last git check-in isn't fixing the problem.
My structure is exactly as rails new [project name] left it, and I've never had to look at how the assets get loaded. Reading up on the asset pipeline just left me more confused.
I'm actually putting all of my styling in app\assets\stylesheets\application.css.scss, which begins with
*= require_self
*= require_tree .
as I believe it should, but (judging from the Chrome developer tools view) the application isn't even getting as far as loading that. So where does a Rails 4 application get told to load app\assets\stylesheets\application.css.scss?
(Yes, I see others have problems with loading the stylesheets, but the advice always seems to be to put the stylesheets where I already have them or to include those lines in the application stylesheet that I already have, so it looks as if my problem is something else).
Running Guard with Spin works great to keep my testing fast, except when assets are relevant and need compiling. It seems that the test environments recompiles all assets whenever I change something in them. I've seen examples of deployment scripts that only recompile assets whose source has changed. Can this be done for testing too? Or is there another way to speed up asset compilation for tests?
I'm using a rather specific setup so I'll be happy to supply more information if needed, though I feel the answer from this question might be of use in many more cases than just mine.
You can take a look at this article written two months ago . It seems rather complex task . Nathan has written a gem that precompiles only changes , made to assets . It can be used in development and testing env.
EDIT : Here is another article , related with speeding up our tests . It has a different point of view about js testing .
You can for example avoid adding require_tree in Your application js and css files.
In addition, use proper file extensions - if something is js - then name it like normal js files. Same for css and scss.
You can also precompile assets locally to have it compiled locally on development by command rake assets:precompile - but remember to delete it after tests to see changes in assets next time (it can be generated in vendor folder)
I am sure but you can try:
In application.js file write all js file in tree order like this:
//= require jquery
//= require jquery_ui
//= require jquery.ui.core
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm new to Rails, and having trouble figuring out the best way to organize my assets. The purpose of this question is to collect my thoughts, solicit input, and evolve the document over time - perhaps it can be a Rails Guide someday. (The Rails Wiki appears to be dead.) This will be meant as an aid to conceptualization for novices, not a reference, so it will be limited to the most common scenarios.
Asset Pipeline - Overview
For details on the purpose, benefits, and inner workings of the pipeline, start with this guide: http://guides.rubyonrails.org/asset_pipeline.html I will only summarize the bits relevant to my purposes here.
The reasons the pipeline is necessary are:
Compilation: To compile high-level languages (ERb, Haml, Sass, LESS, CoffeeScript...) into plain CSS/JS.
The additional benefits of the pipeline are:
Concatenation: Combining multiple files into one to improve client performance.
Minification: Removing whitespace and other clever optimizations to reduce file size.
Fingerprinting: Added an MD5 hash of the file contents to the filename to force caches to **fetch the file again when it changes.
Asset Pipeline - Default Filesystem Layout
app|lib|vender/assets/ - Intended for files which will be processed by the pipeline.
app/assets/ - Intended specifically for files you created for your application.
lib/assets/ - Intended specifically for files you created for sharing across multiple applications.
vendor/assets/ - Intended specifically for files created by others, such as jQuery and Twitter Bootstrap (though they are frequently provided by gems instead of being imported directly into /vender).
public/ - Files in here are left as is, and fetchable directly from the root path ('/') of your web app.
Asset Pipeline - Default Files and Behavior
app/assets/javascripts/application.js
//= require jquery
//= require jquery_ujs
//= require_tree .
app/assets/stylesheets/application.css
/*
*= require_self
*= require_tree .
*/
public/404.html
public/robots.txt
...
Gemfile
...
gem 'jquery-rails'
...
Here's what the asset pipeline compiler does using the default setup of a new Rails app:
The compiler, by default, will process application.js, application.css, and all non-JS/CSS files (images, mostly).
The two application files contain sprockets directives (the comment lines that start with =). Sprockets is the library that powers the Rails asset pipeline compilation. These directives are also called manifests, since they list files for inclusion.
application.js contains a manifest that pulls in two jquery files (which exist in the jquery-rails gem, not in your app), then pulls in all files in the app/assets/javascripts/ tree via require_tree .. All files included via this manifest will get compiled into a single file called application-[the MD5 hash].js, and placed in public/assets/.
application.css contains a manifest that pulls in all files in the app/assets/stylesheets/ tree via require_tree .. The required_self directive tells the compiler to include any CSS content in the application.css file itself, and in the order of the directives. So, in this case, the CSS in application.css will appear above the rest. All files included via this manifest will get compiled into a single file called application-[the MD5 hash].css, and placed in public/assets/.
All non-JS/CSS files (images, mostly) in the app/assets tree will also get fingerprinted and placed in public/assets/, with the directory structure intact. For example, app/assets/images/categories/computers.png will end up as public/assets/categories/computers-[the MD5 hash].png.
Conceptualizing Intra-Asset Dependency Scenarios
Images
Images have no dependencies between them, they always stand alone.
Stylesheets
CSS: CSS files can import each other, which will work as long as paths are correct, though it's probably not the best technique.
Sass: Sass files can import each other, as well as share variables and mixins, but only when they are still Sass (not after compiling to CSS), and only via Sass imports. If you have sprockets directives in application.css.scss that requires 'a' and 'b', they will be compiled in separate contexts before merging. To share variables and mixins, you must import 'a' from 'b' or vice versa using Sass import directives. (See Key Concept 1 below.)
LESS: [Don't know enough about this.]
JavaScript
JS: JavaScript components have inter-dependencies (example: Twitter Bootstrap uses jQuery). However, they all get resolves at runtime in the browser, so it doesn't matter how your organize/combine the files in your project, as long as all the contents eventually get loaded by the browser.
CoffeeScript: [Don't know enough about this.]
Helper Behavior - Rails Views
TODO
Helper Behavior - Sass
TODO
Best Practices - Key Concepts
The pipeline is for preparing assets for production. Think of it as part of the deployment system, not the application itself. Establish the logical structure of your app yourself, then configure sprockets to operate correctly on that structure.
Best Practices - The Common Asset Scenarios
TODO
Best Practices - Summary of Generally Useful Defaults
TODO
** Questions **
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.