CustomValueAccessor component is not updating mat-form-field with invalid state
See original GitHub issueBug, feature request, or proposal:
Bug? Ease of use?
What is the expected behavior?
I would like to be able to write a simple component that wraps a mat-form-field/mat-input so that it can be reused across many apps within my enterprise. Example is in the Stackblitz below, basically I want a form field that contains a password input with a suffix of an icon where you can toggle between password/text.
I want to use this within a reactive form, and have the validation “just work”.
Ideally, I would not have to implement ControlValueAccessor
on my custom component - it’s not really a custom input, it’s just wrapping one so I can easily reuse it.
What is the current behavior?
There are 2 issues currently. First, I would like to not have to implement ControlValueAccessor. I tried to do this by including formControlName=“password” inside my component’s template (in the real world I’d like to be able to bind to [formControlName]=“someInputField” ), but this yields an error: Error: formControlName must be used with a parent formGroup directive.
This is evident if you edit the app.component.html in the stackblitz and uncomment line 8.
So, I implemented the ControlValueAccessor interface and put the formControlName directive on my component tag. This allows the value stuff to work correctly, but the validation state is not being propagated up to the mat-form-field. This is evident if you compare the UX of the username field to the password one. I’m unsure whether this is a bug in Material, or a bug in my component, or what? Again, I’m just wrapping a material input, so I don’t feel like I should have to write a ton of code to have the validation just work.
What are the steps to reproduce?
StackBlitz: https://stackblitz.com/edit/angular-material-d6myox
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Material beta 12
Is there anything else we should know?
This feels like a common use case for sharing common types of inputs. If this is not the correct way to accomplish this, what is a better strategy?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:6 (1 by maintainers)
Top GitHub Comments
I am going to close this issue as this is actually something that is defined at the Angular platform level rather than Material specific. Unfortunately due to the multi ways that forms can be done, along with form elements not having to appear in forms themselves its not something that really can be set up to be convenienced at a library level.
What you will need to do is pass in the form that your
FormControl
will register into. I forked your stackblitz to a working version hereThe highlights are:
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.