Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

Remove jqLite#bind & jqLite#unbind #15221

Closed
mgol opened this issue Oct 6, 2016 · 5 comments
Closed

Remove jqLite#bind & jqLite#unbind #15221

mgol opened this issue Oct 6, 2016 · 5 comments

Comments

@mgol
Copy link
Member

mgol commented Oct 6, 2016

Note: for support questions, please use one of these channels: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question. This repository's issues are reserved for feature requests and bug reports.

Do you want to request a feature or report a bug?
A refactor (removing a feature).

What is the current behavior?
jqLite#bind & jqLite#unbind exist and are aliases to jqLite#on & jqLite#off respectively.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).
N/A

What is the expected behavior?
jqLite#bind & jqLite#unbind should be removed.

What is the motivation / use case for changing the behavior?
Those methods will be deprecated in 1.6.0 so we should remove them in 1.7.0.

Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.
N/A

Other information (e.g. stacktraces, related issues, suggestions how to fix)
N/A

@dcherman
Copy link
Contributor

dcherman commented Oct 6, 2016

@mgol Why plan for removal at all? It seems like a potentially big breaking change in order to save 2 lines of code that don't introduce significant complexity, and it doesn't align with jQuery's goals of deprecation without removal for event shorthands/aliases (as you definitely know)

@gkalpak
Copy link
Member

gkalpak commented Oct 6, 2016

We have recently decided that deprecated features should generally stay in the code for one minor release and be removed in the next minor (breaking) release. And that we should create issues with an appropriate milestone as a reminder.

This is not a hard rule; we can discuss it when the time comes for 1.7.0.

Admittedly, bind/unbind are kind of special, since they are just alises. On the other hand, migrating is pretty easy, so I don't see much benefit in allowing people use a method that has been deprecated for a long time. (Just my 2 cents.)

In any case, thx for raising this @dcherman so we can take it into account when the time comes 😃

@mgol
Copy link
Member Author

mgol commented Oct 9, 2016

Thanks @dcherman for the comment.

@gkalpak It's true it's easy to change the code but this applies to your code only. jQuery has a large ecosystem of plugins, not all of which are regularly updated, especially as long as jQuery doesn't remove a particular deprecated API.

Maybe we should treat jqLite-related deprecations differently than for the rest of Angular: wait for removal in jQuery before removing the API in Angular itself?

@gkalpak
Copy link
Member

gkalpak commented Oct 10, 2016

Maybe we should treat jqLite-related deprecations differently than for the rest of Angular: wait for removal in jQuery before removing the API in Angular itself?

Makes sense.

@mgol
Copy link
Member Author

mgol commented Oct 10, 2016

We've decided to follow this strategy:

we should treat jqLite-related deprecations differently than for the rest of Angular: wait for removal in jQuery before removing the API in Angular itself

We'll document it in FAQ.

I'm closing this ticket; thanks, @dcherman!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants