The sass-rails README says not to use require/ require_tree/require_self in sass/scss files in big, bold letters. Is that warning outdated? If not, what are the potential issues here and why are they recommending that we stay away from the sprockets directives?
It's not quite right. You do lose some of the benefits of sass if you use requires because you can't share sass variables or mixins between files with requires like I talked about in the episode.
The thing they don't talk about is the compile times are incredibly slow when you don't split up your code in requires. When your sass code is modular, you can absolutely split it up and use requires for compile performance in development.
Honestly I've just accepted the fact that Rails Assets Pipeline is uber-slow and started using SCSS @imports as a default a while ago. But this episode was a good reminder that something could be improved. Thank your for the tip.
I was wondering if you plan to make a video about WebPack? I'm still looking for further performance improvement for Rails assets processing. WebPack seem to be a more modern approach. It can compile JS and CSS in background with help of dev server, which may potentially reduce page reload lag in development environment.
It is not that easy to grock the whole thing in the first time though. So it would be really nice to see an episode about Rails+WebPack configuration. And may be another one explaining assets-related specifics for production deployment.
Yeah, I'm gonna talk about Webpack in the future when we get into the frontend framework stuff. It's one of those things that I'm disappointed Rails hasn't improved the asset pipeline enough speed wise, because it doesn't feel like the most useful use of your time to be fiddling with WebPack configurations.
I still very much appreciate the convention over configuration approach Rails takes, just need to get some speed boosts in there and things would be great.
Thanks Chris! I have few related bookmarks, may be you'll find some of these useful:
And there is also rails-webpack gem (https://github.com/mipearso.... It provides WebPack configuration and some related automation out of the box, Rails-style. But I think I'll be using manual approach to set up WebPack, to have more flexibility and understanding what's going on under the hood.
Yeah, thanks! I know that the react_on_rails gem actually uses webpack for compilation but uses the asset pipeline for the embedding into Rails which is nice. I'll have to dive into these articles soon and start planning a webpack episode.
I've a question which I think is related with how to organize the assets files. If we have a rails app that has both a custom frontend and admin/backend layout (so basically we have some controllers inside an admin folder and admin namespace), how can we specifiy in this case that the admin will load only assets required for the backend and not the frontend (and vice versa) ?
You can create separate css files by adding this to your config/application.rb:
config.assets.precompile += ['admin.js', 'admin.css']
And then you can require them in your admin template so those files are compiled separately. It's just like making a second application.css and application.js for your admin area. These won't be compiled into your application.css or application.js by doing so (as long as you don't require them in the file).
So if I understand correct,
2) add in config/application.rb: config.assets.precompile += ['admin.js', 'admin.css'] as you said
3) and then in my admin layout I do: <%= stylesheet_link_tag "admin", media: "all", "data-turbolinks-track" => true %>
correct or did I lose something ? Also same thing applies if I want to do same thing for the frontend too ?
Oh man! Why didn't I think about that? I was suffering with this problem a long time. Every time I need to change a letter in one of the SCSS specific to my app, Sprockets recompiles Foundation and everything. It was getting really slow. This tip is gonna help me a lot! Thanks, Chris!
Join 27,623+ developers who get early access to new screencasts, articles, guides, updates, and more.