Maybe I’m weird (actually, there’s no maybe about it) but when I first heard about Rails 3.1 getting CoffeeScript and Sass out of the box, I wanted to see how it worked and how smooth the process would be. So like quite a few people on IRC I’ve seen, I installed edge Rails (currently 3.1.0-beta) and got playing. (Yes, it’s PRE-RELEASE. Expect mischief!)
I hit a couple of stumbling blocks on my way so I thought I’d explain what I found to be the smoothest way through to getting to play with the new Rails 3.1 goodies. I’ll only take you as far as making some changes and seeing the results, though – you’re on your own from there!
Note: This post was written in April 2011. If you are reading much later on, much of this post may no longer be relevant and you should refer to guides about installing the eventual full release of Rails 3.1 instead. If I remember, I’ll update this to reflect that 
Installing Edge Rails (Rails 3.1 Beta)
Being a conservative kinda dude with the versions of things I run, I hadn’t run the edge Rails gauntlet for some time. I naively tried rails new myapp --edge and while it appeared to work and installed edge Rails, there be dragons (that even rake rails:update couldn’t slay). So do it this way instead:
- Head to whatever directory you use as the base for all of your git cloning. I’ll assume
~/codefrom here on out. - Clone the Rails repository from GitHub with:
git clone git://github.com/rails/rails.git
Creating a Bare Rails 3.1 App
Cloning edge Rails was the easy bit. Now let’s create an app with the bad boy:
- Head to whatever directory you want to use as the base for your Rails projects. I’ll assume you remain in
~/code. - Create a new Rails app with:
~/code/rails/bin/rails new yourapp --edge
It’s important to note that we’re explicitly calling the
railsscript that’s in the edge Rails git repository we just cloned. And, of course, you can call the app whatever you like but I findyourappto be both unique and catchy. - Enjoy watching your Rails app being created and waiting for Bundler to finish its work grabbing edge versions of all sorts of things.
- Dive into your app’s folder:
cd yourapp
- Check everything went OK so far by running:
rails server
- Browse to
http://localhost:3000/(or whatever is relevant in your case) and ensuring you get the usual Rails welcome page. - CTRL+C your way out of
rails serverand get back to the prompt.
We have a working but dead boring Rails 3.1 app on our hands. Let’s get something happening and see what Rails 3.1 is rocking in the CoffeeScript and Sass departments.
In the interests of having something running as soon as possible, we’ll lean on the scaffold generator to get some default, core team approved model, controller, and view code up and running. Simply:
rails generate scaffold Link title:string url:string slug:string visits:integer
Yes, it’s an example model for a URL shortener (the new “hello world” or “blog in 15 minutes” project)! That doesn’t matter though – you can do whatever you like.
Sprockets – Asset Packaging Shenanigans!
Run rails server again now and browse to http://localhost:3000/links/ – pretty typical scaffolding fare, right?
View the source though and check out the <head> section:
If you dig into application.js and application.css (as they’re being served up by the server), you’ll notice that they’re a bit different to the same files in older Rails apps. They contain JavaScript code and CSS code respectively but if you look through the /public folder in your app, those files are nowhere to be found. Shenanigans!
Or not. Sprockets is merely at play, melting and merging down multiple CSS and JavaScript files into a single gooey lump to send to your Web browser.
Playing “Hunt The JavaScript and CSS”
We’re getting CSS and JavaScript being served up through application.css and application.js just fine then, but where are they coming from? Here’s a clue!
Oh yes, there’s a app/assets folder and its beautiful children javascripts and stylesheets. It seems these two fine specimens will become our friends when we make the transition to Rails 3.1.
You may notice that my file tree doesn’t look quite the same as yours. That’s because I’ve already started playing with CoffeeScript and Sass by creating an app/assets/javascripts/awesome.js.coffee file and a app/assets/stylesheets/scaffold.css.scss file (the latter just being a rename of the scaffold.css file you already have).
If you take a sneaky peek into application.css you’ll notice there’s not really any CSS in there. Merely a comment with a directive like so:
/* * FIXME: Introduce SCSS & Sprockets *= require_tree . */
require_tree is just telling the system to bundle together everything from the stylesheets folder into a single file. Awesome – thanks Sprockets!
Playing with Sass
To have a play with Sass first, rename scaffold.css to scaffold.css.scss. If you then reload the /links page in your Web browser you’ll notice little difference. Why? Because Sass (or, more specifically, SCSS) is merely a superset of CSS and any existing CSS will work with it!
Open up scaffold.css.scss and you’ll see it’s pretty boring. It’s just the standard stuff that comes with Rails after all. The first section looks something like this:
body { background-color: #fff; color: #333; }
Let’s say we want to keep our background and text colors in variables so we can use them throughout our CSS later (meaning we only have to change a couple of variables instead of hundreds of references if we want to retheme our app). Rewrite the previous section to:
$background_color: #fee;
$text_color: #000;
body { background-color: $background_color; color: $text_color; }
Here I’ve assigned the colors to variables and then use the variables in the CSS. I’ve made some minor changes to the colors too so that I can definitely see a difference when I reload the page in my browser.
And, well, that’s it. That’s the absolute bare basics of using SCSS in Rails 3.1. Dead simple. Stick .scss on the end of a filename to trigger the SCSS/SASS parser and you’re cooking with gas.
Playing with CoffeeScript
At the time of writing, the application.js file is a wee bit broken as it has a comment that’s not being parsed out. Since this stuff was only added on the very day I wrote this post, I’ll let them off. But in case it’s broken for you still, get application.js looking like this:
#= require jquery #= require jquery_ujs #= require_tree .
These directives should remind you of the equivalent in application.css. As with there, they include other JavaScript files into application.js when it’s served up. You get jQuery, the “unobstrusive” jQuery helpers for Rails, and any other files in the javascripts folder (currently none).
To give CoffeeScript a try, create a file called awesome.js.coffee in the app/assets/javascripts folder and populate it thus:
square = (x) -> x * x alert square(10)
If you refresh the http://localhost:3000/links/ page again now, you’ll have an annoying JavaScript alert window popping up with “100″ in it (the result of square(10)).
This isn’t the time or place to dig into what CoffeeScript does or how it works but.. you’ve just played with it nonetheless If you want to learn more about it, its official homepage is packed with useful stuff.
Like the street walker I picked up solely to use the car pool lane, I’m going to dump you off at the curb here in the middle of conversation. It’s been fun. Good luck and have fun breaking Rails 3.1. If you find any really nasty bugs, be sure to either raise a ticket so the lovely Rails developers can make Rails 3.1 even better or, y’know, submit a patch yourself.
Want to show some appreciation after this lovely blog post? Check out the Ruby Weekly and JavaScript Weekly e-mail newsletters or pass them on to your buddies or co-workers. People are loving them and they’re doing great but the more the merrier!
Похожие записи
Нет комментариев
Оставить комментарий или два