Bug Tracker

Ticket #10574 (closed bug: invalid)

Opened 3 years ago

Last modified 2 years ago

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:
Blocking: Blocked by:

Description

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

comment:1 Changed 3 years ago by dmethvin

  • Owner set to Avorin
  • Status changed from new to pending

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 3 years ago by Avorin

  • Status changed from pending to new

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)

Edit: The page that says it is allowed to use plain objects with bind:  http://api.jquery.com/jQuery/#working-with-plain-objects

Edit2: i only found this page after you asked, and now that i read it completely, i guess this report is invalid, since the doc says: Should .trigger('eventName') be used, it will search for an 'eventName' property on the object and attempt to execute it after any attached jQuery handlers are executed. It does not check whether the property is a function or not. To avoid this behavior, .triggerHandler('eventName') should be used instead. i guess i should use triggerHandler then...

Version 2, edited 3 years ago by Avorin (previous) (next) (diff)

comment:3 Changed 3 years ago by rwaldron

  • Priority changed from undecided to low
  • Resolution set to invalid
  • Status changed from new to closed
  • Component changed from unfiled to event

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 3 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 3 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.