CloudEdit: A Backbone.js Tutorial with Rails(jamesyu.org)
jamesyu.org
CloudEdit: A Backbone.js Tutorial with Rails
http://www.jamesyu.org/2011/01/27/cloudedit-a-backbone-js-tutorial-by-example/
6 comments
This is the best walkthrough for learning Backbone.js that’s been posted to Hacker News yet. (In that I actually feel empowered to go use Backbone to create something, now that I’ve read it). Thanks for posting!
Part of what makes Backbone hard to learn from a lot of the tutorials that have been posted is that the authors aren’t experienced at it enough to be opinionated, which makes me feel lost. jamesjyu’s tutorial is opinionated about some matters of taste, which is confidence-inspiring.
Backbone itself isn’t all that opinionated: it just offers a bunch of legos to put together however you wish, feeling free to ignore many of the pieces. So it’s easy to feel adrift trying to learn how to use it confidently.
Backbone itself isn’t all that opinionated: it just offers a bunch of legos to put together however you wish, feeling free to ignore many of the pieces. So it’s easy to feel adrift trying to learn how to use it confidently.
Thanks a lot! I found that there really wasn't any tutorial that went through a working app with a complete server-side backend. So, I wrote one. :)
Great tutorial but when I see this in the conclusion:
Backbone.js really introduces a new kind of data flow for Rails apps. Instead of data flowing like this:
Rails Model => Rails Controller => Rails View
It now flows like this:
Rails Model => Rails Controller => Backbone Model => Backbone Controller => Backbone View
I get confused. 5 components instead of 3—sweet. Why do I want backbone as part of my rails app? Just to ajax-ify everything? Will it reduce the load on my server?
Backbone.js really introduces a new kind of data flow for Rails apps. Instead of data flowing like this:
Rails Model => Rails Controller => Rails View
It now flows like this:
Rails Model => Rails Controller => Backbone Model => Backbone Controller => Backbone View
I get confused. 5 components instead of 3—sweet. Why do I want backbone as part of my rails app? Just to ajax-ify everything? Will it reduce the load on my server?
You want Backbone as part of your Rails app to clean up your Javascript and make it easier to do hard things…it’s meant for apps that let the user do significant client-side state manipulation.
The alternative to “5 components instead of 3” isn’t “just 3”. It’s “3 well-understood components on the server, and a bunch of jQuery/prototype spaghetti on the client that I really wish was better-organized and easier to extend.” If this describes your app, you might do well to look at Backbone.
The alternative to “5 components instead of 3” isn’t “just 3”. It’s “3 well-understood components on the server, and a bunch of jQuery/prototype spaghetti on the client that I really wish was better-organized and easier to extend.” If this describes your app, you might do well to look at Backbone.
In most cases, it will dramatically increase the load on your server, especially if you use a ReST API like the author suggests.
UPDATE: To clarify, in the specific situation the author describes (exactly one model class, no relationships, basically the simplest "schema" one could create), the load will go down slightly. For real, interactive single-page apps (the kind backbone.js is targeting), the load will go up because apps requests data often, way faster than your current app which is limited by page refresh time.
UPDATE: To clarify, in the specific situation the author describes (exactly one model class, no relationships, basically the simplest "schema" one could create), the load will go down slightly. For real, interactive single-page apps (the kind backbone.js is targeting), the load will go up because apps requests data often, way faster than your current app which is limited by page refresh time.
This looks like a great tutorial, but please, for the love of maintainability stop stringing (pun intended) your views together by concatenating a bunch of lines together all over the place.
Underscore.js (which is required (and from the same team) for using Backbone) has a built-in templating with logic feature. In your html make a <script type="text/html"></script> with your template code inside of it, which will be overlooked by the browser during rendering, but you can still select and get the contents of it by slapping on an id. Then it's just a quick call to _.template() with your data object and it renders out beautifully. It feels analogous to your usual MVC structure, and is much easier to debug and update.
Underscore.js (which is required (and from the same team) for using Backbone) has a built-in templating with logic feature. In your html make a <script type="text/html"></script> with your template code inside of it, which will be overlooked by the browser during rendering, but you can still select and get the contents of it by slapping on an id. Then it's just a quick call to _.template() with your data object and it renders out beautifully. It feels analogous to your usual MVC structure, and is much easier to debug and update.
James is also using Jammit here, which has built-in support for JavaScript templates (of any flavor). I agree that it would simplify the tutorial to get all of that string concatenation out of there.
That said, he clearly thinks that leaving templates out of it is the simpler solution: "For the purposes of this tutorial, I'll use simple string concatenation in my views." And from the point of view of someone just getting started, he may very well be right.
That said, he clearly thinks that leaving templates out of it is the simpler solution: "For the purposes of this tutorial, I'll use simple string concatenation in my views." And from the point of view of someone just getting started, he may very well be right.
I'd be willing to do the identical tutorial for SproutCore, if the author will allow his page to be copied and edited.
(I didn't see a license anywhere allowing that.)
(I didn't see a license anywhere allowing that.)
I would like to see that!
Any secret sauce in not worrying about rails 3 forgery protection?
His example app is running Rails 2.3.8, and also includes this little option that's important:
James, I'd consider adding a note about this to your tutorial. Also, the link to your GitHub is a fake one; I managed to guess it properly though. Oh, and all of your commits show you as both the committer and the author, I think your git config is wrong. Make sure git config --global author.email is your github email.
ActiveRecord::Base.include_root_in_json = false
James, I'd consider adding a note about this to your tutorial. Also, the link to your GitHub is a fake one; I managed to guess it properly though. Oh, and all of your commits show you as both the committer and the author, I think your git config is wrong. Make sure git config --global author.email is your github email.
I only ask because cross-site request forgery protection is enabled by default in Rails 3 and require some extra coaxing with its authenticity token. Since this is in Rails 2.3.8 as you've highlighted, it's a moot point.
Oh man, that is embarrassing. Link is fixed now. I'll add a note about the json later.
No worries, it happens to everyone. :D
There's a couple things that might be better handled differently:
* Use a collection to keep track of "Documents". You wouldn't have to implement url() yourself, write the manual getJSON() request, or map the response into Document models.
* As previously mentioned, templates would help avoid a lot of the messy string concatenation here.
* You can use the "change" event to listen to changes on documents, instead of re-rendering the Index every time ... That said, with so many people editing the list of docs simultaneously, it probably makes sense to refresh the Index from scratch.
* You shouldn't have to call "delegateEvents()" again inside of Edit#save, as long as the Edit view's "el" hasn't changed.
Great work -- I really appreciate you taking the time to write such a detailed tutorial.