Side navigation
#7900 closed enhancement (wontfix)
Opened January 05, 2011 04:05AM UTC
Closed February 09, 2011 06:25PM UTC
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: |
Description
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.
Attachments (0)
Change History (7)
Changed January 05, 2011 04:50AM UTC by comment:1
| component: | unfiled → event |
|---|
Changed January 18, 2011 01:43PM UTC by comment:3
| priority: | undecided → high |
|---|
Changed February 01, 2011 12:24AM UTC by comment:4
| owner: | → boaz |
|---|---|
| status: | new → pending |
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?
Changed February 01, 2011 12:38AM UTC by comment:5
| status: | pending → new |
|---|
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.
Changed February 06, 2011 03:50PM UTC by comment:6
| priority: | high → low |
|---|
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.
Changed February 09, 2011 06:25PM UTC by comment:7
| resolution: | → wontfix |
|---|---|
| status: | new → closed |
+1
Providing documented interfaces to underlying internals that are subject to change is probably a good approach to solving this and other similar problems.