Always delegate in #setElement.

[braddunbar]

Ok, crazy question. Why do we delegate events after calling View#initialize instead of before? The test suite passes either way so I have only conjecture. Here are a couple:

1. Changing el in #initialize - This is probably ill advised but changing this doesn't alter behavior. Events would just be delegated twice.
2. Altering #events in #initialize - I suppose you could, but I would say this is also ill advised. Regardless, you could do it in the constructor if you had to.

Anything I missed? This allows us to do away with the delegate argument to setElement, which is a clear win I think.

[wyuenho]

Another question to ask would be, why would anyone want to not redelegate events when setting a new el?

[akre54]

👍

[jashkenas]

I think because you might want to go and trigger an event during initialize...

But if you think it's clearly better —

[braddunbar]

Hmm...you mean you might want to trigger an event before attaching listeners? I don't quite follow.

[jashkenas]

Sorry — you're right. I was confused.

[jridgewell]

Might be worth reconsidering this one, there are now 6 bug reports (#3166, #3256, #3704, #3620, marionettejs/backbone.marionette#2605, marionettejs/backbone.marionette#2628) that I know of from users about modifying the events hash in #initialize.

[akre54]

This seems like something that you should've been doing in the first place. Not sure why we'd roll it back.

[jridgewell]

Just using libraries I've written on top of Backbone as an example, I always do binding after calling #initialize. In fact, I've recommended it.

Yes, it can be solved by using a function instead, but Backbone's encouraged extend using objects doesn't make it obvious. Modifying in an #initialize is much easier for end devs to grasp.

[akre54]

But why? initialize isn't the right place for this, in my opinion. If your events aren't ready to be bound until after you've rendered, just put a delegate call at the end of your render (or set it up in your child view). Setting up event listeners and child views in initialize is fine, but I wouldn't mess with your el or child views' el there.

[jridgewell]

But why? initialize isn't the right place for this, in my opinion.

I think that's fighting against a common usage. It's not just new devs that are falling into it, I do it as well.

If your events aren't ready to be bound until after you've rendered, just put a delegate call at the end of your render (or set it up in your child view).

But these aren't waiting for a render to bind new events handlers. It's about treating #initialize as a proper constructor:

The thing is initialize exists so we dont have to override the constructor and call super. This same existence can be reconsidered as soon as we have to move things into constructor again, just to make things work. — marionettejs/backbone.marionette#2605 (comment)

We've encouraged this usage pattern by providing an #initialize.

---

As a side note, library authors aren't able to provide this same functionality. You can either bind this like modelEvents before calling Backbone.View.apply(this, arguments) in which case you won't have any of the viewOptions on the instance, or afterwards in which case #initialize has already run.

[kworth]

Doesn't #3802 bring up a new point to this discussion? It appears we've discussed modifying el in initialize and things like that. So I won't beat that horse. But what about the pattern of assigning a model in the initialize, etc. mentioned in #3802?