What I mean when I ask this is, "Is there a way that an individual view can load w/ specific stylesheets and resources?".
Now, I'm not referring to the classic usages of script and link HTML tags to reference resources, primarily because when Rails loads, it precompiles ALL of the available assets provided.
The main reason I want to do this is because after a while I find that there are so many good web development frameworks out there that it can be very fun to mix and match various ones, and it's really hard to target one framework to use all the time. Also, there can usually be a lot of conflict between various frameworks because of like naming systems (e.g. Bootstrap 2 alongside Bootstrap 3).
If I understand ok, you can do the following:
Application layout:
yield :stylesheets if content_for? :stylesheets
In specific view:
content_for :stylesheet do
= stylesheet_link_tag "specific_style"
Make sure to precompile "specific_style" in application.rb:
config.assets.precompile << ['application.css', 'specific_style.css']
Related
I'm playing with a rails 4.2 application and it seems like it loads all of my stylesheets for each and every page.
Is that true? How is it better than loading for each page only the relevant stylesheets?
On one hand, I know they'll all be minified when going to production, and it will reduce the total size and cache one CSS for the whole website.
On the other hand, page I might have some thin pages that will need no more than a few css lines to be rendered correctly that will get tones of files for no reason. It will also require me to be super strict and safe when choosing class names in order to have no collisions and unwanted overrides.
What about JS assets? It acts the same way?
(I guess the answer for image assets is "hell no!")
Yes, in development you'll see a lot of files (all of them) and in production they will be compiled and minified to a single file.
Once this file has been downloaded by the client it will be cached and wont need to make any further requests to load other stylesheet files on concurrent request (unless caching and turbolinks has been disabled). The downside is that the file size will be larger and make the initial load time slightly longer.
One problem as you point out is scoping. In my experience it's way better to always apply proper scopes when developing. And in rails using sass it's really easy to have nice and tidy css.
The same goes for javascript, but not for images as you pointed out.
That said. There are ways to work around this if desired, but more often than not I've realized that there are more pros than cons with a single file.
Edit:
Oh, and if you're new to rails, beware that turbolinks might cause you some headaches in the beginning messing with page ready in js-files before you get the hang of it. But it's worth it in the end.
The advantage and rationale for this is to reduce the amount of data that is sent to the client after the first page load. The first page load pulls down all the js/css (compiled into single files), but then this can be cached and reduces the amount on each subsequent page load.
The following is purely theoretical, if at all possible, try and work with the defaults of one css/jss file
If you absolutely do want to trim it down, then you can. Your application.css manifest file (or js) probably includes a line such as:
//= require_tree .
which says, require everything in this directory. you could then split this down so application.css only requires everything in the application folder (absolutely need to know):
//=require_tree ./application
Then add additional manifest files, for example for an admin section, so that the admin styles/JS can be loaded only when needed in admin.js
//=require_tree ./admin
Then in your layout file you can do
= stylesheet_link_tag "application", media: "all"
= yield :additional_stylesheets
And where you want those additional styles you can add them.
- content_for :additional_stylesheets do
= stylesheet_link_tag "admin", media: "all"
end
Note: this will cause issues if you're using turbolinks.
Note II: You may need to add these to the precompile list in application.rb:
config.assets.precompile += ['additional_manifests.css']
You could modify this workflow to not include any CSS at all to start with and only load what you need.
Why is it so forbidden to add line like <link href="/assets/stylesheets/bootstrap/bootstrap.css" rel="stylesheet"> in my application.html.erb file. How else do I insert it?
It's not "forbidden" outright - it just skirts a lot of important Rails conventions which will likely create problems & inconsistencies down the line
There are several elements to what you're asking. Here they are:
Layout
Firstly, you need to use the correct helpers in your layout:
#app/views/layout/application.html.erb
<%= stylesheet_link_tag "bootstrap/bootsrap" %>
The reason for this is the same as using helpers in other parts of your Rails application - as paths change between environments & certain "backend" functionalities of the system evolve, you can't rely on using vanilla HTML to call "Rails-centric" methods
A pro tip is that if there is any reference to a path, or an asset, you need to use the helpers which Rails provides
Asset Pipeline
Further to this, you need to appreciate how the "asset pipeline" works.
One of the big benefits of the Rails framework is that it gives you the ability to organize your assets in the most effective way - by keeping them in the /assets folder.
Whilst great for development, your problem will arise when you go into a production environment - Rails prefers to serve static assets in production, which means that the assets will be pre-compiled & access in the public folder:
In the production environment Sprockets uses the fingerprinting scheme
outlined above. By default Rails assumes assets have been precompiled
and will be served as static assets by your web server.
To make sure this works properly, you need to use the path helpers to load the files dynamically; hence allowing Rails to access the files wherever they are on the system
--
Manifest
I would strongly recommend you look into the "manifest" feature of the asset pipeline:
#app/assets/stylesheets/application.css
/*
*= require bootstrap/bootstrap
*/
I'm just learning the new asset pipeline in Rails 3.1. One particular problem I'm having is with the way Sprockets just mashes all the found CSS stylesheets into one massive stylesheet. I understand why this is advantageous over manually merging stylesheets and minifying for production. But I want to be able to selectively cascade stylesheets instead of having all rules all mashed together. For instance, I want:
master.css
to be loaded by all pages in the Rails app, but I want
admin.css only to be loaded by pages/views within the admin section/namespace.
How can I take advantage of the great way that Rails 3.1 combines stylesheets and minifies them for production, but also have the former flexibility of being able to load only certain stylesheet combinations per layout?
Or should this be done by adding a class to body tags in layouts-
body class="admin"
And then target style rules as appropriate. Using SASS scoped selectors this might be a reasonable solution.
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.
Hope this helped some.
I have a post about this on my website:
Leveraging Rails 3.1, SCSS, and the assets pipeline to differentiate your stylesheets
And check out this answer to another question: Using Rails 3.1 assets pipeline to conditionally use certain css
Hope this helps.
Best regards,
Lasse
#nathanvda: sure...
We make use of multiple layout files. So in our app/views/layouts, instead of having just application.html.haml (we use HAML), we actually ignore the application layout and use 3 custom layouts:
admin.html.haml (admin section views only)
registered.html.haml (registered/signed in users views only)
unregistered.html.haml (unregistered/unsigned in users views only)
So at the top of my admin.html.haml file I will have my stylesheet link tags to a separate admin.scss (we use SCSS) manifest. That manifest will load any necessary sub-stylesheets just for the admin section. This allows us to specify rules just for the admin section while also making use of common styles. For instance, we use jquery-ui throughout the site, so the styles associated with jquery-ui sit in their own stylesheet and we include them in the manifests for all 3 css manifest files.
This solution doesn't give you a single CSS file that can be cached, but it ends up giving you 3 CSS files, each of which can be cached. This allows a tradeoff between performance and some flexibility in organizing CSS rules so we don't have to worry about CSS rule collisions.
The way I've been doing it so far is to have two seperate folders a/ and u/ where a/ is for the admin view and u/ is for the user view. Then in the layout I point to the appropriate application.css with assets/u/application.css(js). Bit of a pain having to move the auto generated files each time but a lot less than having to require each file individually in the manifest.
I use something like
application.html.erb
">
show.html.erb
content_for :body_id do
page_specific_body_id
end
I would like to know what are the best ways to organise CSS code in Rails project?
I'm interested in how you do it and why.
If you would like to break up your css into multiple files during development you can add cache => true to stylesheet_link_tag and rails will automatically concatenate them into a single file in production. This also works for javascript_include_tag.
http://guides.rubyonrails.org/layouts_and_rendering.html#linking-to-javascript-files-with-javascript_include_tag
Generally, you should not have the client download a massive amount of CSS snippets, but pack them into a single file on the server to avoid rendering latencies. So you have the tradeoff of having functionality divided up into multiple files put wanting to send only one file to the client.
You could use SASS to have each piece of code inside a single include file and just include all of them together. This gives you the added advantage of mixins (kind of like macros) and variables among other awesome things.
Another possibility would be to use plain CSS and use something like Jammit to pack the stuff up to send to the client.
Regarding actual setups, I tend to have one file resetting the styles to a known default, a file for the basic layout (columns, default spaces, ...), and one file each for each area of concern for your specific design (headers, buttons, ...)
James and Holger's answers are very good.
Besides organizing CSS in my projects, I also had to change colour schemes a couple of times..
Trying to do consistent changes throughout many CSS files can be pretty painful (results may vary).
I ended up extending the Rails start-up procedure a little, to include a custom module "site_settings.rb"
through which I can define variable for colors and other CSS attributes, which I can then use throughout my CSS input files.
Whenever Rails starts up, and one of the input files has changed, it auto-generates the CSS files.
http://unixgods.org/~tilo/Ruby/Using_Variables_in_CSS_Files_with_Ruby_on_Rails.html
Since Rails 3.1 is out and sprockets replaced Jammit, here an excerpt form the Rails guides concerning the asset organization:
Asset Organization
Assets can be placed inside an application in one of three locations: app/assets, lib/assets or vendor/assets.
app/assets is for assets that are owned by the application, such as custom images, JavaScript files or stylesheets.
lib/assets is for your own libraries’ code that doesn’t really fit into the scope of the application or those libraries which are shared across applications.
vendor/assets is for assets that are owned by outside entities, such as code for JavaScript plugins.
I'm using this line:
= javascript_include_tag :all, :recursive => true, :cache => true
in the footer of a Rails app to do the following:
Load all the scripts under public/javascripts recursively
In production, lump them all into one file (the :cache part)
However, I want to load one of these scripts in the head, because some inline JS depends on it.
Is there an option for javascript_include_tag to exclude files that have already been loaded?
I know it doesn't do this by default, because right now I see a script referenced twice in the source HTML.
javascript_include_tag is a simple html helper and doesn't track weather or not something has already been included on the page, so no, there isn't an option, sucks.
In place of this, you can solve your problem in a few ways:
Use something like Jammit, which I use right now and is an absolute joy. It packages all your javascripts up in production into one file, allows you to compress the shit out of them, and does the same for CSS. You configure it using a .yml file in your config directory, making it portable and easy to recursively include scripts from directories while still controlling the order in which they are included on the page or appended to the package. An alternative (less awesome IMHO) to Jammit is Asset Packager.
Use javascript_include_tag in the head. Not really the end of the world. Optimize later.
Not really Rails specific, but use head.js. head.js is pretty new but allows you to load many scripts quickly, in parallel, while preserving the execution order and taking callbacks to fire once your scripts are loaded but before the dom is ready. It includes a bunch of other goodies like HTML5 friendliness in older browsers. This option is interesting because you keep your scripts separate, or at least in different packages for maximum parallel download speed. I'm not sure weather or not downloading one huge compressed package serially in the <head> or even right at the footer, or loading things in parallel using head.js will be faster, but it sure makes managing these things easier.
I've used both head.js and Jammit recently and I must say, for heavy Javascript apps, they make things wonderfully easy.
In config/application.rb you can set the meaning of :defaults in the javascript_include_tag :
# JavaScript files you want as :defaults (application.js is always included).
config.action_view.javascript_expansions[:defaults] = %w(rails, jquery)
You can then use the :defaults parameter to use the tag in application.erb.html, or wherever you like:
<%= javascript_include_tag :defaults %>
Once you've done this at the bottom of your view template, you can of course include single scripts before it.
Now, I realise that you wanted to use the :all parameter, and load recursively, but this solution does give you more control, which I think you are going to need here.