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

refactor(ngOptions): optimize getWatchables array #11050

Closed
sjbarker opened this issue Feb 13, 2015 · 1 comment
Closed

refactor(ngOptions): optimize getWatchables array #11050

sjbarker opened this issue Feb 13, 2015 · 1 comment
Labels
component: forms type: perf type: refactor
Milestone
Backlog - won't fix

Comments

@sjbarker
Copy link
Contributor

We need to prevent storing irrelevant or unnecessary watchers. See discussion in PR #11017:

@petebacondarwin wrote:

I realised that we can actually optimize this by only including things that are being specified. So for instance, if no disable when clause was provided we would not need to watch this expression. The same for the displayFn which computes the label.
sjbarker added a commit to sjbarker/angular.js that referenced this issue Feb 13, 2015
@sjbarker
feat(ngOptions): add support for disabling an option
e0c1ad7 
This patch adds support for disabling options based on model values. The
"disable when" syntax allows for listening to changes on those model values,
in order to dynamically enable and disable the options.

The changes prevent disabled options from being written to the selectCtrl
from the model. If a disabled selection is present on the model, normal
unknown or empty functionality kicks in.

Additionally, instead of adding more unnecessary watchers, if either label
or disableWhen are not matched in the ngOptions expression, they will not be
watched.

closes angular#638
closes angular#11050
@sjbarker sjbarker mentioned this issue Feb 13, 2015
Closed
@Narretz Narretz added this to the Backlog milestone Feb 13, 2015
@petebacondarwin petebacondarwin mentioned this issue Feb 13, 2015
Closed
@sjbarker
Copy link
Contributor Author

closed in 3cea386

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
component: forms type: perf type: refactor
Projects
None yet
Milestone
Backlog - won't fix
Development

No branches or pull requests
2 participants
@Narretz @sjbarker