-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
md-input does not honor [value] expressions #2363
Comments
As a follow up, this works properly when using |
same is true when using reactive forms and not setting the values right from the start (eg set them after http call or a timeout) Edit: it seems that a handful of things are missing here from the |
it also seems not to work when binding via [disabled]="testCondition" or [disabled]= "'true'" We still can edit the value when testCondition is true. |
Right now the MdInputDirective tries to cache the `value` of the input. > For this the MdInputDirective needs to listen for NgControl value :changes and for native `(change)` events. This caching will be problematic when a value is set directly to the input element (using `[value]` property binding) because Angular is only able to recognize this change in the first ChangeDetection. > The solution of updating the value in the `ngAfterViewInit` lifecycle hook, will result in a binding change (`[class.md-empty]` in the view) while being in a ChangeDetection, which leads to a ChangeDetection error. Fixes angular#2441. Fixes angular#2363
Right now the `MdInputDirective` tries to cache the `value` of the input. To do this, the `MdInputDirective` needs to listen for `NgControl` value changes and for native `(change)` events. This will be problematic when a value is set directly to the input element (using `[value]` property binding) because Angular is only able to recognize this change in the first ChangeDetection. ```html <md-input-container> <input md-input [value]="myValue" placeholder="Label"> </md-input-container> ``` The approach of updating the value in the `ngAfterViewInit` lifecycle hook, will result in a binding change while being in a ChangeDetection, which leads to a ChangeDetection error. ``` Expression has changed after it was checked. Previous value: 'true'. Current value: 'false'. ``` Fixes angular#2441. Fixes angular#2363
It doesn't work even when using |
Right now the `MdInputDirective` tries to cache the `value` of the input. To do this, the `MdInputDirective` needs to listen for `NgControl` value changes and for native `(change)` events. This will be problematic when a value is set directly to the input element (using `[value]` property binding) because Angular is only able to recognize this change in the first ChangeDetection. ```html <md-input-container> <input md-input [value]="myValue" placeholder="Label"> </md-input-container> ``` The approach of updating the value in the `ngAfterViewInit` lifecycle hook, will result in a binding change while being in a ChangeDetection, which leads to a ChangeDetection error. ``` Expression has changed after it was checked. Previous value: 'true'. Current value: 'false'. ``` Fixes angular#2441. Fixes angular#2363
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Bug, feature request, or proposal:
When using
input[md-input]
and binding a value using[value]="expr"
, the internal value is not updated when[value]
resolves. This in turn propagates toempty
not updating once[value]
resolves.What is the expected behavior?
When setting an input's value with
[value]
, it should be honored. The placeholder should move out of the way when value is set.What is the current behavior?
The input believes it is empty and the placeholder stays in the original spot.
What are the steps to reproduce?
http://plnkr.co/edit/79XlYsdCjUKQvnKQyDRU?p=preview
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, browsers are affected?
Material 2.0.0-beta.0
Is there anything else we should know?
The text was updated successfully, but these errors were encountered: