Rails Without Views

A presentation I gave at RubyNation 2012. In it, I go over a few best practices for building real-world Backbone.js projects on top of Ruby on Rails.

Transcript

1. Rails Without Views Building real-world Backbone.js applications on top of Rails
2. “When I broke ground on Projector, my first real Backbone app, I went about everything the wrong way.”
3. Backbone.View → ActionController::Base Backbone.MODEL → ACTIVERECORD::BASE Backbone.COLLECTION → ...has_many?
5. “I was naïve. I was thinking too much like a hardened Rails developer.”
6. “I was naïve. I was thinking too much like a hardened Rails developer.” Here’s how you can avoid this quicksand.
7. BACKBONE 101 FOR RAILS DEVELOPERS
8. “Views are sorta like controllers. They wrap themselves around DOM elements.”
9. VIEWS ARE RESPONSIBLE FOR... ★ Rendering, or hijacking, a DOM element and its children ★ Responding to user input within the view’s associated element ★ Registering bindings on collections and model instances that affect the underlying DOM element ★ Templates != Backbone Views
10. “Collections are managed lists of model objects.”
11. COLLECTIONS ARE RESPONSIBLE FOR... ★ Fetching data from somewhere (a REST API, localStorage) ★ Map/Reduce functions to be performed on the collection ★ Emitting events related to items in the collection for listeners ★ Keeping contained items sorted
12. “Models are objects wrapped around JSON.”
13. MODELS ARE RESPONSIBLE FOR... ★ Providing computed properties on top of JSON objects ★ Providing query methods ★ Validating data set on the object ★ Synchronizing itself
14. “The router connects URIs to application state.”
15. THE WAY WE TRADITIONALLY HAVE WRITTEN RAILS APPLICATIONS
16. Responsibilities of the SERVER Responsibilities of the CLIENT ★ Route URI to the appropriate handler ★ Do something with user input (like a form submit) ★ Authenticate sessions ★ Access control ★ Fetch stuff from a database or API ★ Render a template ★ Send back a document to the client (usually HTML) ★ Display received documents ★ Create new requests triggered by user input ★ Basic changes to the DOM
17. THE WAY WE WRITE CLIENT-SIDE HEAVY APPLICATIONS
18. Responsibilities of the SERVER Responsibilities of the CLIENT ★ Route URI to the appropriate handler ★ Do something with user input (like a form submit) ★ Authenticate sessions ★ Access control ★ Fetch stuff from a database or API ★ Render a template ★ Send back a document to the client (JSON) ★ Route URI to the appropriate handler ★ Fetch JSON documents from the server ★ Render templates ★ Modify templates according to user permissions ★ Attach event handlers to the resulting DOM ★ Send JSON to the backend
19. Responsibilities of the CLIENT ★ Route URI to the appropriate handler ★ Fetch JSON documents from the server ★ Render templates ★ Modify templates according to user permissions ★ Attach event handlers to the resulting DOM ★ Send JSON to the backend Responsibilities of the CLIENT ★ Display received documents ★ Create new requests triggered by user input ★ Basic changes to the DOM
20. Responsibilities of the SERVER ★ Route URI to the appropriate handler ★ Do something with user input (like a form submit) ★ Authenticate sessions ★ Access control ★ Fetch stuff from a database or API ★ Render a template ★ Send back a document to the client (JSON) Responsibilities of the SERVER ★ Route URI to the appropriate handler ★ Do something with user input (like a form submit) ★ Authenticate sessions ★ Access control ★ Fetch stuff from a database or API ★ Render a template ★ Send back a document to the client (usually HTML)
21. “Creating a single-page application doesn’t mean less code on the server, more code on the client. Not much changes on the server.”
24. FOUR CORE CONCEPTS TO KEEP YOU OUT OF THE MUD.
25. BACKBONE MODELS DON’T INHERIT FROM ACTIVERECORD.
26. “You can only work with what your backend provides.” “Objects in your collection should be based on what your client needs, not what’s in your database.”
27. “You can only work with what your backend provides.” “Objects in your collection should be based on what your client needs to present, not what’s available.”
28. GET /pROJECTS GET /PROJECTS/ARCHIVED
29. RETHINK THE WAY YOU PRESENT DATA RELATIONSHIPS.
30. “My REST controllers don’t always represent database resources.”
31. AVOID: GET /STORIES GET /STORIES/1/COMMENTS GET /STORIES/1/TIME_LOGS
32. “Eager load to minimize requests.” “Lazy load (make more requests) for detail views.”
33. “Eager load to minimize requests.” “Lazy load (make more requests) for detail views.”
34. EXPOSE THE CURRENT SESSION TO THE CLIENT.
35. “Store your current user in a globally accessible variable .”
36. NEVER TRUST YOUR CLIENT.
38. “Access control needs to be mirrored on the client and server.”
39. THANKS! @brennandunn projectorpm.com wearetitans.net