Rails Without Views

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.

63bfd250f2b518e201825044c820ad68?s=128

Brennan Dunn

March 23, 2012
Tweet

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?

  4. None
  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.”
  22. None
  23. None
  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.

  37. None
  38. “Access control needs to be mirrored on the client and

    server.”
  39. THANKS! @brennandunn projectorpm.com wearetitans.net