Skip to content
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

Closed
arciisine opened this issue Dec 23, 2016 · 6 comments · Fixed by #2455
Closed

md-input does not honor [value] expressions #2363

arciisine opened this issue Dec 23, 2016 · 6 comments · Fixed by #2455
Assignees

Comments

@arciisine
Copy link

arciisine commented Dec 23, 2016

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 to empty 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?

@arciisine arciisine changed the title md-input empty does not honor [value] md-input does not honor [value] expressions Dec 23, 2016
@arciisine
Copy link
Author

As a follow up, this works properly when using ngModel or formControlName. I actually have a scenario in which I want to show readonly form elements without binding the data to a form. It also does work if using value="name" but not using value="{{name}}"

@bboehm86
Copy link

bboehm86 commented Dec 23, 2016

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)
http://plnkr.co/edit/JkLHwmauIhJGy7dJfQU7?p=preview

Edit: it seems that a handful of things are missing here from the NgControl because the (new) md-input directive seems just to rely on Inputs for things like 'disabled' or 'required' to style the container & label... (updated the plnkr)

@MarcusCalidus
Copy link

MarcusCalidus commented Dec 23, 2016

it also seems not to work when binding via [value]="some.value"
this causes the placeholder to remain where it was

image

@arat3091
Copy link

it also seems not to work when binding via [disabled]="testCondition" or [disabled]= "'true'"

We still can edit the value when testCondition is true.

@devversion devversion self-assigned this Dec 27, 2016
devversion added a commit to devversion/material2 that referenced this issue Dec 29, 2016
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
devversion added a commit to devversion/material2 that referenced this issue Dec 29, 2016
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
@fxck
Copy link
Contributor

fxck commented Jan 2, 2017

It doesn't work even when using formControl or formControlName, specifically when the value is set asynchronously.

devversion added a commit to devversion/material2 that referenced this issue Jan 4, 2017
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
@kara kara closed this as completed in #2455 Jan 4, 2017
kara pushed a commit that referenced this issue Jan 4, 2017
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants