Bug Tracker

Opened 10 years ago

Closed 9 years ago

#7900 closed enhancement (wontfix)

Create and document interface to jQuery.event.props

Reported by: boaz Owned by: boaz
Priority: low Milestone: 1.6
Component: event Version: 1.4.4
Keywords: Cc:
Blocked by: Blocking:


jQuery.event.props maintains a list of properties to copy to the jQuery event object. This is done for efficiency reasons, so that only the necessary properties for jQuery to perform common tasks.

Sometimes, however, a jQuery developer will want to use jQuery to bind to a native event that has an uncommon property, like the dataTransfer property available in the callback of a drop event.

Currently, developers have to manually push such a property onto jQuery.event.props. This is not ideal, because this makes code rely on internal structures that may change in the future.

Even if the the event copying system does not change over time, it is not good practice for jQuery developers to be accessing internal structures within jQuery.

Therefore, jQuery should create and document a public interface for developers to manipulate this list.

Change History (7)

comment:1 Changed 10 years ago by ajpiano

Component: unfiledevent


Providing documented interfaces to underlying internals that are subject to change is probably a good approach to solving this and other similar problems.

comment:2 Changed 10 years ago by Rick Waldron

Related to #7808

comment:3 Changed 9 years ago by Rick Waldron

Priority: undecidedhigh

comment:4 Changed 9 years ago by snover

Owner: set to boaz
Status: newpending

I’m confused. jQuery.event.props is documented at http://api.jquery.com/category/events/event-object/ as a mechanism for doing this, as is the originalEvent property. Is that an insufficient mechanism?

comment:5 Changed 9 years ago by boaz

Status: pendingnew

I did not see that documentation at the time of posting.

I think that this architecture should be documented in an "internals documentation", and that users should be encouraged to use a setter API for interacting with it in production code.

Accessing an internal property directly is a precarious API. Given the changing landscape of the Document API, a setter interface should be used for adding properties to the jQuery.event.props.

comment:6 Changed 9 years ago by snover

Priority: highlow

Well, I guess my point is that this is no longer an internal data structure since it is documented on the api site, and as such is not subject to change without a long and laborious process of deprecation and so on and so forth. originalEvent is *certainly* not going to change or go away in any case.

I’m also not sure what the benefit of creating an entirely new interface for this would be, since it is pretty edge-casey (not a lot of people are wanting to retrieve arbitrary event object properties like this); I would think it makes more sense to just add any new and useful HTML5 event properties to the default list of props instead.

comment:7 Changed 9 years ago by Rick Waldron

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.