Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The event argument is not passed for listners attached to a JS object #102

Open
bartsidee opened this issue Jan 28, 2014 · 7 comments
Open

Comments

@bartsidee
Copy link
Contributor

events attached to DOM object pass back an event argument

bean.on(element, 'click', function (e) {
   console.log(e);
});

but events attached to a JS objects do not receive the event argument

var eventbus = {};
bean.on(eventbus, 'customevent', function (e) {
   console.log(e);
});
bean.trigger(eventbus, 'customevent');

the above outputs undefined.

The implication is that:

  • the .on syntax is not following a standard pattern
  • it is impossible to determine the event type afterwards, e.g. when attaching multiple custom events at the same time this could be useful

.

var eventbus = {};
bean.on(eventbus, 'customevent1 customevent2 customevent3 customevent4', function (e) {
    console.log(e.type);
});
bean.trigger(eventbus, 'customevent1');
@bartsidee
Copy link
Contributor Author

A quick solution I just found was to pass the handler as event argument to the event

From https://github.com/fat/bean/blob/master/src/bean.js#L667:

        // non-native event, either because of a namespace, arguments or a non DOM element
        // iterate over all listeners and manually 'fire'
        handlers = registry.get(element, type, null, false)
        args = [false].concat(args)
        for (j = 0, l = handlers.length; j < l; j++) {
          if (handlers[j].inNamespaces(names)) {
            handlers[j].handler.apply(element, args)
          }
        }

To:

        // non-native event, either because of a namespace, arguments or a non DOM element
        // iterate over all listeners and manually 'fire'
        handlers = registry.get(element, type, null, false)
        for (j = 0, l = handlers.length; j < l; j++) {
          if (handlers[j].inNamespaces(names)) {
            handlers[j].handler.apply(element, [false, handlers[j]].concat(args))
          }
        }

@ryanve
Copy link

ryanve commented Jan 28, 2014

Duplicate of #80 Yes we should fix this.

@rvagg
Copy link
Collaborator

rvagg commented Jan 28, 2014

@ryanve let's just get this done, want to do up a PR to make the needed changes?

@ded
Copy link
Collaborator

ded commented Jan 28, 2014

interesting that this only comes up now. what would one do with an event object from a custom event?

@ryanve
Copy link

ryanve commented Jan 28, 2014

@rvagg I can tackle this within the next week or so.

@ded Not lots but including it would help normalize the handler signature between all events: native, custom, triggers.

For custom events, supporting .type could suffice.

@ded
Copy link
Collaborator

ded commented Jan 28, 2014

For custom events, supporting `.type` could suffice.

that's actually a great idea and would work for a first pass. we should probably bump up a minor version after this is implemented

@ryanve
Copy link

ryanve commented Jan 28, 2014

Sounds like a plan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants