Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
feat(AbstractControlDirective): implement hasError() and getError() #7255
Due to #7238 I realised, that when building template-driven forms, we don't have APIs such as
E.g. having a tiny form like this:
We always have to walk down the properties of
However, when this same form is built model-driven, all of a sudden we have additional APIs:
What makes the difference, even though we seem to work with the same instance?
Well, when building model-driven forms, the form model is built in the component and then associated to a form in the DOM using
We don't have this with template-driven forms, as we're only using the
I'd expect the same APIs in the template no matter if I'm building template-driven forms or model-driven forms. So I propose extending
Does that make sense?
However, that one doesn't help either, as the control itself is not registered yet at the point we're accessing it from the template:
The control gets only registered the very first time the value of this control changes.
referenced this issue
Feb 26, 2016
Realised I can use the elvis operator to make this work (as this is what we use for expressions that evaluated asynchronously):
However, I still think, that both strategies, template-driven and model-driven, should provide the same API in the template.
Further more, it'd be nice to have an API that tells if there are errors at all, so we can do sth. like:
This could also be done by extending
I'm confused. We have
From the plunker in the Forms chapter
That could have been
I do like the idea of sugaring
I think it's as simple as adding:
That's consistent with its