bug(md-error/md-hint): It isn't being displayed below tag

[rafaelss95]

Bug, feature request, or proposal:

Bug.

What is the expected behavior?

md-error and md-hint should display below the tag when it's wrapped by another tag.

What is the current behavior?

If you wrap md-error or md-hint with any tag, it doesn't work as expected, it appears inside element itself.

<form [formGroup]="formGroup">
  <md-input-container>
    <input type="text" mdInput formControlName="num2">

    <!--can be any element here-->

    <div *ngIf="formGroup.get('num2').invalid"> // dummy condition to show the issue
      <md-error *ngIf="formGroup.hasError('required', 'num2')">
        Required
      </md-error>
      <md-error *ngIf="formGroup.hasError('pattern', 'num2')">
        Must be a number
      </md-error>
    </div>
  </md-input-container>
</form>

What are the steps to reproduce?

Providing a Plunker (or similar) is the best way to get the team to see your issue.
http://plnkr.co/edit/8QgsyvGx93l9YpucZZ0w?p=info

What is the use-case or motivation for changing an existing behavior?

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular: 4.2.4
Material: Material2#beta.7
OS: Linux
Typescript: 2.3.4
Browser: Only tested in Chrome

Is there anything else we should know?

[willshowell]

See #5263 (comment)

[rafaelss95]

@willshowell For me, it's really strange... even if I use it with ng-container that doesn't render any element (tag) it doesn't render in the right way.

[willshowell]

As you can see here, md-error is selected with <ng-content select="md-error"> to be projected within mat-input-subscript-wrapper.

Unfortunately, ng-content select="" only selects top level components within md-input-container, and doesn't look within ng-container or ng-template...

I don't know the history of that behavior, but maybe worth filing an angular issue for.

[rafaelss95]

@willshowell That's really a bad thing :(

Now I'm wondering if it's an issue or the expected behavior.

My real situation is the following:

I have a lot of inputs inside my components, like this:

<input type="text" mdInput [formControl]="nameCtrl">
<form-validation [control]="nameCtrl"></form-validation>

I have a reusable component named "form-validation" with this template:

<ng-container *ngIf="control.invalid && control.touched && control.errors | keys as errorKeys">
  <ng-container *ngIf="errorKeys[0] as firstError">
    <md-error [translate]="'errors.messages.' + firstError" 
              [translateParams]="control.getError(firstError)">
    </md-error>
  </ng-container>
</ng-container>

Since it doesn't seem possible to do this (to use md-error inside another elements), I'll have to go back to the ugly syntax by doing the same code twice:

<md-error [translate]="'errors.messages.' + control.invalid && control.touched && control.errors | keys | first"
          [translateParams]="control.getError(control.invalid && control.touched && control.errors | keys | first)">
</md-error>

[webUIdevelopment]

The angular material document says that "If an input element can have more than one error state, it is up to the consumer to toggle which messages should be displayed. This can be done with CSS, ngIf or ngSwitch."
If the md-error cannot be wrapped with in another element for eg div, how can I achieve the below structure?

<md-input-container>
<input mdInput required>
<div [ngSwitch]="switchCase">
  <md-error *ngSwitchCase="Case1">Error 1</md-error>
  <md-error *ngSwitchCase="Case2">Error 2</md-error>
  <md-error *ngSwitchCase="Case3">Error 3</md-error>
 </div>
</md-input-container>

[willshowell]

@webUIdevelopment You may have to organize it like this:

<input mdInput required>
<md-error>{{ currentError(switchCase) }}</md-error>

currentError(val) {
  switch (val) {
    // ...
  }
}

...or this

As far as I can understand, support for dynamic content projection will help angular/angular#8563 once it's available

[jelbourn]

See #5263 (comment) as @willshowell said for an explanation

[angular-automatic-lock-bot]

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.}