Bug Tracker

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#10574 closed bug (invalid)

jQuery.event.trigger throws error if elem[type] is not a function

Reported by: Avorin Owned by: Avorin
Priority: low Milestone: None
Component: event Version: 1.7rc1
Keywords: Cc:
Blocked by: Blocking:


This issue occurs if you use non-DOM elements with events, like this:

$({disabled: true}).trigger("disabled");

and only when the type is a truthy value on the element. since it is checked in Events.js on line 375 with

if (... && elem[ type ] && ...)

the error itself gets thrown on line 386 in the Events.js or 3228 in the jquery.1.7rc1.js:

elem[ type ]();

i made a tiny fiddle that shows the error: http://jsfiddle.net/Avorin/maMxV/show/

(the jQuery version is git though, because jsfiddle does not provide jquery 1.7rc1 yet, but its reproducible on both)

Change History (5)

comment:1 Changed 12 years ago by dmethvin

Owner: set to Avorin
Status: newpending

Can you explain a bit more about why you're doing this? Did you see some documentation indicating it is a valid thing to do? If so can you provide a URL?

comment:2 Changed 12 years ago by Avorin

Status: pendingnew

Well, i don't do this directly, i use the underlying jQuery.event.trigger together with .add and .remove to build a event-system with all the jQuery features, but without the need to create a jQuery object - basically i provide a class that does only wrap those 3 methods and i rewrote jQuery.bind/unbind/trigger for that myself. I dont ask for support of that, don't get me wrong please, but i thought to give jQuery a "plain object" and trigger any kind of event on it was valid:

One of the places where i saw the base of this pattern was here: http://weblog.bocoup.com/publishsubscribe-with-jquery-custom-events

another one comes from there: https://gist.github.com/661855

basically every Observer Pattern implementation with jQuery uses the arbitrary event names/types and since it was ok to wrap a plain object with a jQuery object, i thought they would go along(which was supported by the fact that they did, in 1.5/6)

Version 0, edited 12 years ago by Avorin (next)

comment:3 Changed 12 years ago by Rick Waldron

Component: unfiledevent
Priority: undecidedlow
Resolution: invalid
Status: newclosed

The article you linked to states that using jQuery as an event system gives really poor performance. I can assure you - we (I work at Bocoup) didn't publish that article to encourage using jQuery means to bind and trigger events on plain objects.

Ben's gist is also using a DOM object and was written mostly for academic purpose only.

comment:4 Changed 12 years ago by cowboy

While using an undocumented subsystem as the basis for a custom event system is both interesting and ambitious, it's not really supported.

You might consider using a generic Pub/Sub implementation. It's a pretty lightweight and performant message-passing technique, and shouldn't really require jQuery (mine does, but it was just a proof of concept).

comment:5 Changed 12 years ago by Avorin

Thanks for the advice!

@cowboy i wanted a universal event-system not only pub/sub, i just used the links at an inspiration how that could be done with jQuery. I knew of course that this would not be supported since its a "private" and undocumented subsystem. The framework (for which the event-system is the basis) required jQuery anyway, so that was not a big drawback. I will look into micro-frameworks that provide an jQuery-like Events API to switch it with the Events.js dependency.

Again, thanks for the advice!

Note: See TracTickets for help on using tickets.