Closed edster23 closed 6 years ago
This also seems to be a problem when you do something like:
<md-input-container>
<my-component></my-component>
</md-input-container>
where my-component template looks like:
<input md-input/>
Although this is a little more understandable - maybe you would want to put the md-input-container into your template to avoid this, but then you loose uniformity in your HTML. But this is again why I was trying to wrap into our own from-group/input-container that would handle the uniformity for you plus hints so your html is not littered with duplicate validation strings and logic.
@edster23 We do plan to allow for more flexibility here. The plan is to create some interface (e.g. MdInputInterface
) and have the MdInputContainer
do all of its communication with the native input via that interface. We would handle providing an implementation of that interface for <input>
elements, but you could also provide your own implementation on a custom component and have it work with the MdInputContainer
. (This all still needs design work and discussion though, so it won't be any time soon).
I'm less sure about the ng-content
example you gave, but I'll look into what it would take to make it work when I'm working on the design.
That's good. I think right now we are planning on making the custom components include the md-input-container in their templates. This would make it more compact wile using, but less material looking when we on board developers.
I also had a similar idea. I wanted to create an InputContainerComponent which developers could use as <app-input-container>
instead of <md-input-container>
to wrap <input mdInput ... />
or <textarea mdInput ...>
The new input container would add md-hint, for validation errors or input hints, set the correct type of the input based on swagger documentation, ... so you'd get the correct input field out of the box without writing anything extra, while having all the freedom of explicitly setting every property of input / textarea.
Right now I've created a structural directive, to be applied on md-hint which needs to be copied into virtually every md-input-container. And this directive takes care of most of it, but it needs additional configurations and is just another piece of code we need to track to be copied properly.
@pgrm Here is what I am using until this is resolved. I have added more of our custom components to this selector and have a bit more code to work between them, but this is the jist of it.
creating a directive on md-input-container
, that's clever I didn't think of that, thx for the hint
We have a different method of extending form field functionality now: https://github.com/angular/material2/blob/master/guides/creating-a-custom-form-field-control.md
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.
Bug, feature request, or proposal:
Bug/Feature
What is the expected behavior?
md-input-container validation should occur after content projection is applied
What is the current behavior?
The resulting content projection provides the md-input/mdInput, but the validation does not take this into account
What are the steps to reproduce?
Create a component similar to: `
` and pass an input to the component. No matter what you pass in, you always get the error
https://plnkr.co/edit/X2cKySR81BG51IbshX4m?p=preview
What is the use-case or motivation for changing an existing behavior?
It makes it particularly hard to extend the functionality of md-input-container with this
Which versions of Angular, Material, OS, browsers are affected?
Angular 4.0.0-beta.6 material 2.0.0-beta.1
Is there anything else we should know?
I was able to solve this with a directive selector ='md-input-container' and insert the desired content (validation messages) at runtime, but this is not nearly as clean and using content projection.