@jdfreder Corrected as per your comment.

@SylvainCorlay why trigger the "destroy" event ourselves instead of calling this.destroy() and let Backbone trigger the destroy event itself?

Ahh I think I see why, is it because the destroy method attempts to delete the model on the back-end?

Because this.destroy() also sends message to the server.

Do you think it would also make sense to call this.stopListening() since backbone does that in its clean-up code inside destroy()? That method doesn't seem to call back to the back-end.

In any case we need an event, which we use that event in Javascript Link widget PR and the PR on hiding the widget area. Backbone propagates it to the children models and all, which can be useful in the future.
I can look at the stropListening tonight.

I agree, I'll merge this after you take a quick look at stopListening() and tell me if you agree that it makes sense to call it here. I'm just trying to make sure the model is in the same state as it would be if if backbone itself triggered the destroy event. From it's docstring, stopListening() just removes all of the event listeners to/from the current model which seems like it would be important in reducing ref count... It may be a bug that we aren't calling it already.

Quiclky checking into backbone, I see the stopListening in remove, but not in destroy.

Isn't this it: https://github.com/jashkenas/backbone/blob/master/backbone.js#L527 ? Lines 526, 527, and 544. Maybe you were looking in another destroy?

Indeed. you are right. I added the line to stop listening.

Awesome thanks @SylvainCorlay !