angular / angular/components

Strange mat-error & state behaviour on Custom ControlValueAccessor component

Open
#7,920 20 comments 2 reactions 0 assignees View on GitHub
area: material/form-field P3
Dominant language
TypeScript
Stars
25k
Forks
6.8k
Avg merge
1d 8h
Merged PRs (30d)
91

Description

#### Bug
I have this custom input component, using `ControlValueAccessor` and it is perfectly in sync with the controlling formGroup, and gives the `valid`, `invalid`, `touched` and `hasErrors('required')` to the formGroup & internally correctly.

#### What is the current behavior?
Whenever i want to use the `mat-error` component, it will only work as expected when I give the `required` attribute to the `input`. When I leave that out, the `mat-error` will _never_ show, whatever I try. So on blur (`touched=true`) it will not show the `mat-error`. But it _does_ in this simple plunkr: https://plnkr.co/edit/cJFCUITMlcBc78v06937?p=preview

I'm not sure why this is, the only thing I can think of is that I use ` [(ngModel)]="_value"` on the input i.c.w. `NG_VALUE_ACCESSOR`/`ControlValueAccessor`, but I would think that since the formGroup state is correct, and it all works perfectly when having the `required` property on it, this should be irrelevant.

Looking at this @crisbeto's answer: https://github.com/angular/material2/issues/4027 Point 1 seems to be saying a similar thing, that setting `required` on it, it works, and towards the end @willshowell states `Errors are hidden until the input is both invalid and touched` yet they are both invalid and when touched still don't show it.

#### What is the expected behavior?
I would expect the `required` to not be relevant to showing the `mat-error` element. For example, I might want to validate an email with `Validators.email` but have it optional.

#### What are the steps to reproduce?
This plunkr demonstrates it by simply clicking and blurring each input field: https://plnkr.co/edit/4B2OOc5Spv9ewxbeIndZ?p=preview

Although While recreating it in plunkr, I found out some new strange behaviour. The first instance of the component doesn't seem to apply the `placeholder` attribute, and also doesn't change the `touched` state; however this problem has not occurred on my project (yet). See: https://plnkr.co/edit/FODeH4ZhE7IG01dmYCiR?p=preview This does indicate something strange going on, and I cannot figure out what it is.

#### What is the use-case or motivation for changing an existing behavior?
I would expect `required` not to be required for `mat-error` to work.

#### Which versions of Angular, Material, OS, TypeScript, browsers are affected?
- "@angular/material": "2.0.0-beta.11",
- "@angular/common": "^4.3.6",
- "@angular/compiler": "^4.3.6",
- "@angular/compiler-cli": "^4.3.6",
- "@angular/core": "^4.3.6",
- "@angular/forms": "^4.3.6",
- "@angular/http": "^4.3.6",
- "typescript": "^2.4.2",

#### Is there anything else we should know?
- I've spent hours trying to fix this and trying to figure out why this happens. I'm pretty convinced it is a problem with the implementation of `mat-error`.
- I've tried transcluding the `mat-error` like: `{{ getError() }}` and then `` But then it is placed wrongly and will always show the error, probably would not fix this issue either.
- I've tried accessing the state internally on the component, with `Injector` & `NgControl` and subscribing to `statusChanges` and could see the internal status is correct as well.

Contributor guide

Open the contributing guide

Research direction

Start by running the supplied Plunker reproductions and compare the custom ControlValueAccessor component with the simple working example. Trace how mat-error evaluates invalid and touched state when required is absent, then verify optional email validation and first-instance placeholder behavior. Done means the reproduction shows mat-error consistently for invalid, touched controls without requiring required.

Written by the indexing model from the issue text.

Assessment

Tech stack
angular, typescript
Domain
frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
40/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.