BackboneJS与Rails

jieforest

And we modify View to understand presenters by specifying a presenter callback option:

1. 1renderContext: () ->
   
2. 2  if @presenter?
   
3. 3    @presenter.apply @, [@model]
   
4. 4  else if @model?
   
5. 5    @model.toJSON()
   
6. 6  else
   
7. 7    {}
   

复制代码

jieforest

Responding to Events

We want the collection view to show movies as we add them. And we want the collection view to remove movies as we delete them. When we edit a movie's details, we also want to update the list view. Events make this easy.

Note: Events also mean our code is loosely coupled. We recently tried an experiment with a larger, packaged Backbone framework. Since all our code uses standard events, we were able to wire up a completely new collection view implementation by changing one line and our UI (add, delete, edit, and more) just worked.

Adding a new model to a collection fires the add event. When we see the add event, our collection view generates a new child view for the newly added model. Collections will maintain their sort order, so we take advantage of that to render the new child view in the correct place (commit).

jieforest

The event flow goes like this:

1. the collection sends an add event to its listeners
2. the CollectionView adds a new child view for the new model

Removing a model from a collection fires the 'destroy' event. When we see the destroyevent, our collection view removes the child view for the removed model (commit).

The event flow goes like this:

1. the model sends a destroy event to its listeners
2. the collection containing the model passes the event along to its listeners
3. the CollectionView destroys its child view

jieforest

When a view is destroyed, the view should cleanup. Aside from just being good practice, leaving dangling objects around, particularly callbacks, can lead to unexpected and difficult to diagnose behaviors.

Until recently, Backbone had a minimal remove that only removed the DOM element (by now you must be seeing the trend in Backbone.) On August 15th, 2012, dispose was added to Backbone master. The dispose method cleans up all the events registered via Backbone: the events hash and the model and collection bindings. Calling remove will calldispose for you.

Using remove/dispose covers the core Backbone cleanup. There is no hook for non-core Backbone cleanup; for example you might use Backbone.Events to trigger events from a widget, dispose will not know about them.

Instead of calling remove, we are going to use destroy which we implement in our Viewclass:

1. 1destroy: ->
   
2. 2  @hide()
   
3. 3  @unbind()
   
4. 4  @remove()
   
5. 5  @
   

复制代码

jieforest

The view is hidden, we unbind, and then we ask Backbone to cleanup. unbind is the hook to perform our non-core Backbone cleanup. For example, CollectionView could use unbind to destroy all of its children when the parent view is destroyed (and so on if the child views had children).

Wrap up


Recap!
1. render templates; use mustache
2. manage your views in a hierarchy; ideally instantiating only a top level view
3. use presenters
4. leverage events; for example to automatically render and destroy your views
5. cleanup after your views

The next installment will cover routers and controllers and how you should be using them and why Backbone is not MVC, even though it is MVC.

jieforest

TL;DR

Render your views with mustache.

Use presenters instead of using models directly from views.

Use events.

Cleanup when you destroy a view.

Be kind to others; be especially kind to children, the elderly, and animals.

jieforest

over.

gordonwq

jieforest 发表于 2012-9-17 09:15
An example app

The app is incomplete, lacking tests, and written for clarity not conciseness. All ...

where is code