2. Key things to keep in mind from
the Throne of JS talk
✤ Clean code does not interleave concepts. Code that is around
maintaining data should not be mixed with code messing with the
DOM.
✤ DOM code should be focused, and not know about about other bits of
DOM code.
✤ The source of truth should be in rich data structures, not embedded in
the DOM.
3. Components of Backbone.js
✤ The Model, an abstraction over a single REST resource
✤ The Collection, an abstraction over a REST collection of resources
✤ The View, a logical UI component
✤ The Router, a way to maintain application state
4. The “real” pattern, MVP
✤ Backbone is MVP, Model View Presenter
✤ What backbone calls the view is actually the presenter, what it calls
the template is actually the view
✤ This is confusing, but unimportant
5. Model / Collection
✤ Where the data goes
✤ Emits events when things change
✤ When in doubt, push it down
6. The View
✤ Operates on a single tree of elements
✤ Should never touch the html outside of its root element
✤ Should either be changing model/collection based on user
interaction, or reacting to data changing
✤ Can be rendered without existing in the DOM
✤ Can be composed of multiple sub views
7.
8. The Router
✤ When you have a “single page” application, you often still want the
back button to work, and users to have the ability to “deep link”
✤ The router accomplishes this via either tricks with hash marks, or
with push state
✤ Least fundamental of all the components
11. Backbone.Marionette
✤ Created by Derick Bailey, to provide structure in building larger
javascript applications
✤ Philosophically very similar to backbone, just goes a few more steps
✤ Eliminates a lot of common boilerplate in backbone code by
providing slightly higher level view abstractions
✤ Provides tools that become extremely useful when writing larger
javascript applications
12. Marionette Views
✤ Provides a additional convenience methods on top of what backbone
gives you (ui hash, triggers hash, model events hash (added by me :)
✤ Provides a model binder, to prevent zombie views
✤ Frameworks away basic rendering code
13. Marionette Views
✤ Item View, binds to a model
✤ Collection View, binds to a collection
✤ CompositeView, binds to a model and to a collection
14. Marionette Tools
✤ Application Modules: Lets you group parts of the application, and
start/stop them independently
✤ Layouts/Regions: Manage the creation/displaying/disposing of
parts of the page which are dynamic
✤ Event Aggregator: Provides a module/application level event bus
✤ AppRouter: Routers that delegate to external objects
16. CommonJS (in the asset pipeline)
✤ Using global scope is explicit
✤ You bring in a module with var Reference = require(“path/to/
module”)
✤ You choose what that Reference is by setting module.exports in the
module
✤ You should never need to introduce a global variable
✤ Much nicer then ruby, but still behind a lot of other implementations
(like python, clojure, scala, etc)
17. Function.apply
✤ Inside a function, what “this” refers to is determined by the
invocation
✤ If invoked off of an object, “this” will refer to that object
✤ If invoked in isolation, “this” will refer to the global scope
✤ If invoked via apply (or call), “this” is specified by the caller
✤ apply also lets you pass an array that will be used as arguments (you
apply arguments to a function)
18. Misc
✤ I have emacs set up to display function() as !(). This is purely
cosmetic (it is still function when it saves) but I find it dramatically
reduces the syntactic noise in the language.
19. What are our requirements?
✤ Have a “new” row. It has a “create” button that when clicked, creates
a resource on the server. When that resource is created, it creates a
new row.
✤ Rows can be edited and deleted.
✤ Errors are shown, and edit boxes are highlighted
✤ There should be a way to override things at any level
✤ There should be a simple api for consumers to invoke
