Normalize handler signature about bean HOT 5 OPEN

@ryanve I completely agree with you here, and not just for jQuery compatibility, the trigger arg stuff is a bit of a mess. Also, given the fact that we do a lot of manual handler triggering now we can do some Event object emulation stuff, like jQuery does.

Consider this jQuery, a pattern used a bit in Bootstrap:

var e = $.Event('show')
el.trigger(e)
if (!e.isDefaultPrevented()) {
  // do something
}

Being able to create and retain the event object has a heap of benefits.

Unfortunately the horse has bolted on that and it's a bit difficult to change the API. Perhaps we'll try and solicit some feedback on this to see if anyone is actually using the trigger arguments in Bean.

from bean.

@ded @connor @st-luke @iamdustan (or anyone else?) got an opinion on this?

from bean.

I'm not using trigger args in bean but normalization is a good thing if it can be done without totally screwing people.

from bean.

I'm also not using trigger arguments in any projects using Bean (although may discover some during the conversion, Rod, like we talked about over email). I'm for the first element in the array being reserved for an eventData object.

from bean.

I agree with the argument presented here that the first argument should be reserved for the eventData object and the second being optional arguments. It’s clean and provides an expected and consistent way to determine how the event was triggered and how to access your custom arguments.

I haven’t used the trigger arguments because of how it’s applied currently (I tried. I may still have used it, but it definitely caused some confusion at the time)

from bean.