Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Deprecate jQuery.proxy #2958
Comments
markelog
added this to the 3.1.0 milestone
Feb 29, 2016
markelog
added
the
Core
label
Mar 3, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
r3wt
Apr 18, 2016
It's used extensively to call prototype functions with context for event bindings in many jquery plugins, notably in bootstrap's plugins. I don't think it should be deprecated, though its easy enough to roll your own.
r3wt
commented
Apr 18, 2016
•
|
It's used extensively to call prototype functions with context for event bindings in many jquery plugins, notably in bootstrap's plugins. I don't think it should be deprecated, though its easy enough to roll your own. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
markelog
Apr 18, 2016
Member
Proposal here for deprecation only, not for removal, if it would be removed, it would happen in major version.
As you said you it is easy to supplement, which what jquery-migrate would do anyway
|
Proposal here for deprecation only, not for removal, if it would be removed, it would happen in major version. As you said you it is easy to supplement, which what jquery-migrate would do anyway |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
timmywil
Apr 18, 2016
Member
It's small enough that if it's getting wide usage, I don't see the need for deprecation.
|
It's small enough that if it's getting wide usage, I don't see the need for deprecation. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
mgol
Apr 18, 2016
Member
|
One thing that jQuery.proxy does and Function#bind doesn't is setting guid
on the bound function instances so that proxied event handlers can be
removed without storing the instance of the proxied function.
|
|
@timmywil would you recommend to use |
|
@markelog I still use proxy over bind when I think it's cleaner to pass a function name rather than the function. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
markelog
Apr 18, 2016
Member
If we still recommend to use jQuery#proxy and not es6 version, that then this indeed should be closed.
But i don't think that refusal from deprecation should came from "used a lot" place, if that is the only reason, then we should discourage people from using it, which is what deprecation is, which doesn't mean we would need to remove it at 4.0, it could be the next or next after next.
|
If we still recommend to use But i don't think that refusal from deprecation should came from "used a lot" place, if that is the only reason, then we should discourage people from using it, which is what deprecation is, which doesn't mean we would need to remove it at 4.0, it could be the next or next after next. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
dmethvin
Apr 19, 2016
Member
Carrying over our discussion about breaking things from yesterday's meeting, it seems like there is not a lot of benefit from deprecating this or eventually removing it. It isn't a lot of code inside jQuery and removing it will just make someone rewrite code that works perfectly well today. That's in contrast to something like the Deferred changes which, although potentially more disruptive, are driven by our desire to align with Promise standards.
I started this wiki page that's similar to our Adding page where we can try to outline our practices.
https://github.com/jquery/jquery/wiki/Changing-existing-features
|
Carrying over our discussion about breaking things from yesterday's meeting, it seems like there is not a lot of benefit from deprecating this or eventually removing it. It isn't a lot of code inside jQuery and removing it will just make someone rewrite code that works perfectly well today. That's in contrast to something like the Deferred changes which, although potentially more disruptive, are driven by our desire to align with Promise standards. I started this wiki page that's similar to our Adding page where we can try to outline our practices. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
jzaefferer
Apr 19, 2016
Member
Deprecating in favour Function#bind with no intention to remove seems like a pretty good idea. Pushing users towards standards if worth it.
|
Deprecating in favour |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
Precisely |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
dmethvin
Apr 19, 2016
Member
If we put a deprecation warning in Migrate about it, people will feel compelled to get rid of that warning or complain to us about it. If we have a schedule for removal that makes sense, but if it's eternal deprecation I don't know if it does.
|
If we put a deprecation warning in Migrate about it, people will feel compelled to get rid of that warning or complain to us about it. If we have a schedule for removal that makes sense, but if it's eternal deprecation I don't know if it does. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
markelog
Apr 19, 2016
Member
If we put a deprecation warning in Migrate about it, people will feel compelled to get rid of that warning or complain to us about it
Yeah, that would be consequences of deprecation, also adding note about deprecation to the documentation.
Frankly, i'm not sure why we wouldn't want to promote Function#bind over jQuery#proxy in the same way i don't think we would need to recommend jQuery.now over Date.now.
Yeah, that would be consequences of deprecation, also adding note about deprecation to the documentation. Frankly, i'm not sure why we wouldn't want to promote |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment|
Then don't put a warning in migrate. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
timmywil
Apr 19, 2016
Member
I only want to deprecate things that are slated for eventual removal. I'm fine promoting bind over proxy, but I think we should do it in documentation. Deprecation is not the right tool.
|
I only want to deprecate things that are slated for eventual removal. I'm fine promoting |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
markelog
Apr 19, 2016
Member
If no one would used because we discourage it, it would be logical to eventually remove it, besides definition of deprecation is -
Deprecation is the discouragement of use of some feature, design or practice
What term do you prefer?
|
If no one would used because we discourage it, it would be logical to eventually remove it, besides definition of deprecation is -
What term do you prefer? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
jzaefferer
Apr 20, 2016
Member
I only want to deprecate things that are slated for eventual removal
Why? Also what Oleg said.
Why? Also what Oleg said. |
dmethvin
self-assigned this
Sep 26, 2016
timmywil
modified the milestones:
3.2.0,
3.3.0
Mar 6, 2017
This was referenced Apr 2, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
shanimal
Apr 5, 2017
Im guessing Im not understanding something obvious, and this may be a really dumb question, but Im wondering if native bind can be used to stub $.proxy when it's available.
Calling proxied functions is roughly 80% slower than calling the same function using bind. In Firefox it was 114% slower.
https://jsperf.com/native-bind-vs-proxy
shanimal
commented
Apr 5, 2017
|
Im guessing Im not understanding something obvious, and this may be a really dumb question, but Im wondering if native bind can be used to stub $.proxy when it's available. Calling proxied functions is roughly 80% slower than calling the same function using bind. In Firefox it was 114% slower. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
dmethvin
Apr 6, 2017
Member
We've deprecated this method, so we aren't planning to do any other implementation.
|
We've deprecated this method, so we aren't planning to do any other implementation. |
dmethvin
closed this
Apr 6, 2017
|
@dmethvin Did you close it by accident? We haven't deprecated it yet so I'll reopen... |
markelog commentedFeb 29, 2016
It seems their use is mostly fulfilled with
Function#bindand other signatures has limited use