1

Can someone please explain, what is the life cycle of a View (controller), say, for a Row in a TODO list app?

App.RowView = Backbone.View.extend({
    events:{
        "click #del" : "delRow"
    }
});

Most of the tutorials, the AppView would do this:

    render: function()
    {
        this.collection.each(this.renderRow, this);
        return this;
    },
    renderRow: function(row)
    {
        var rowView = new App.RowView({model:element});
        this.$('#rows').append(rowView.render().el);
    }

Questions:

  1. does that mean rowView is only used once and disposed in renderRow()? Or does it live on?
  2. if true, when to kill the View? is adding listener to model.destroy and invoke remove() at the view good enough?
  3. If I already have the row's markup rendered from the server, would the click #del events still get captured and do something w/o a rowView created?
  4. shouldn't 'click #del' be better located in the parent view, so that jQuery can delegate and attach behavior there?
  5. does that mean I have 1 rowView per row? wouldn't that mean the _.template is being compiled on every row? any alternative?
fguillen
  • 29,929
  • 17
  • 114
  • 172
Henry
  • 31,972
  • 19
  • 112
  • 214

1 Answers1

2
  1. The reference dies, the View can remain if there are other references pointing to it.
  2. You kill the View when is not needed any more, normally when is not visible any more. If your View is binding any event you have to unbinding them before call remove(): Pattern to manage views in backbone
  3. An instance of RowView have to be instantiated for the event to be captured.
  4. This depends on the behavior you are looking for, but in your example I think each View has to capture each own click #del event, if you declare the event in the parent View how do you know wich row to delete?
  5. Normally you declare the template in the View definition and you assign a compiled version of it to this.template like this: template: _.template( "hello: <%= name %>" );.
Community
  • 1
  • 1
fguillen
  • 29,929
  • 17
  • 114
  • 172
  • 2
    Re (1): there will be references to that view instance through the `delegate` call that binds the event handling to the `el`. – mu is too short Jun 04 '12 at 18:39
  • @muistooshort Very interesting point, I was thinking in the explicitly binded events when I say "if there are other references" but I didn't think in the DOM binded events. – fguillen Jun 04 '12 at 18:56
  • 1
    The hidden reference through `delegate` is the one that bites everyone and causes leaks when they don't have a per-view-instance `el`. I know this from experience (of course), you have to clean up that hidden reference through `undelegateEvents` if several views share an `el`. – mu is too short Jun 04 '12 at 19:01
  • @muistooshort does that mean we should call `remove()` AND `undelegateEvents()` to be safe? Even http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/ does not mention `undelegateEvents()` – Henry Jun 04 '12 at 19:08
  • 2
    I think the situation @muistooshort is talking about is when your View is using a shared `el` and then you can't call `View.remove()` but if this is not the case, calling `View.remove()` will remove all the DOM elements binded and with them all the references of them to the View. – fguillen Jun 04 '12 at 19:12
  • Thx, should I also call `model.off()` after `model.destroy()`? – Henry Jun 04 '12 at 19:21