bean
bean copied to clipboard
fat
Normalize handler signature
To improve jQuery-compatibility and general consistency in the arguments passed to event handlers via different methods, I think that bean.fire() and .trigger() need modification. Consider:
(function ($) {
var $html = $('html');
function handler () {
console.log(arguments);
}
$html.on('click', handler); // `handler` receives (eventData) when <html> is clicked
$html.trigger('click'); // `handler` receives (eventData)
// When triggered with extra params, bean omits the eventData, meaning
// the line below sends just ('extra-0', 'extra-1') to `handler`.
// In jQuery the line below sends (eventData, 'extra-0', 'extra-1')
$html.trigger('click', ['extra-0', 'extra-1']);
}(ender)); // 2012-11-27 ender build jeesh
The arguments passed to handlers should be as normalized as possible between native / custom / triggers etc. The arguments[0] slot should be reserved for an eventData object. In situations without applicable eventData, it could be passed as null or (better) a simple object like:
{
isBean: true,
isTrigger: true // jQuery includes this on triggers
}
@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.
I'm not using trigger args in bean but normalization is a good thing if it can be done without totally screwing people.
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.
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)
