angular: Attribute and class bindings throw an error when declared inside ngForm elements in Beta.1

I’ve come across a really weird error right after upgrading to Beta 1: Every time I drop a [class.whatever] or any other attribute binding within a nested DOM element wrapped by a ngForm element I get the infamous No provider for ControlContainer! (NgControlName -> ControlContainer) exception.

I’ve put together a tiny sample component to replicate the error:

import { bootstrap } from 'angular2/platform/browser';
import { Component } from 'angular2/core';
import { FormBuilder, ControlGroup, Control, Validators, FORM_PROVIDERS, FORM_DIRECTIVES } from 'angular2/common';

@Component({
    selector: 'test-form',
    directives: [FORM_DIRECTIVES],
    template: `
        <form [ngFormModel]="testForm">
            <p *ngIf="!testControl.valid">Form is empty and hence not valid</p>

            <!-- This little guy below will make Angular 2 complain -->
            <div [class.error]="!testControl.valid">
                <input type="text" ngControl="testControl">
            </div>

        </form>
    `
})
class TestForm {
    testForm: ControlGroup;
    testControl: Control;

    constructor(private formBuilder: FormBuilder) {
        this.testControl = new Control('', Validators.required);
        this.testForm = this.formBuilder.group({
            testControl: this.testControl
        });
    }
}

bootstrap(TestForm, [FORM_PROVIDERS]);

Apparently this only occurs when attaching class or attribute bindings to nested elements. Whenever I bind class names by means of ngClass instead, the issue simply does not occur.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 1
  • Comments: 51 (3 by maintainers)

Most upvoted comments

To make this work, you can replace ngControl="name"with [ngFormControl]="form.find('name')" . For me it is much more readable workaround.

<form [ngFormModel]="loginForm" (submit)="login()">
     <fieldset class="form-group" [class.has-danger]="!valid">
          <input [ngFormControl]="loginForm.find('name')" id="name" class="form-control form-control-lg" type="text"
                               placeholder="Nutzername" autofocus="autofocus"/>

+1.

In beta 8, using [class.xyz] on a fieldset inside a form triggers this problem:

<form [ngFormModel]="loginForm" (submit)="login()">
      <fieldset class="form-group" [class.has-danger]="!valid">
           <input ngControl="name" id="name" class="form-control form-control-lg" type="text"
                               placeholder="Nutzername" autofocus="autofocus" />

Adding *ngFor=“true” to the fieldset seems to be a workaround - this works:

<form [ngFormModel]="loginForm" (submit)="login()">
     <fieldset class="form-group" *ngIf="true" [class.has-danger]="!valid">
          <input ngControl="name" id="name" class="form-control form-control-lg" type="text"
                               placeholder="Nutzername" autofocus="autofocus"/>

+1 on beta.13

+1 to fix it.

I haven’t this issue anymore. Angular beta.16, rxjs 5.0.0-beta.5, zone.js 0.6.12. Checked in Chrome 50 and FF 45

It works fine use [ngClass]; [class.haserror] is still not good. I am using beta 14 too

In beta 7 i get this error when I use ngControl on input outiside of an html ‘form’ element.

The other temporary fix is to use [ngClass] instead of [class.something]

portah, your temp fix work for me. It will not work only when css class name contains dash. I tried to do it like [ngClass]={ 'state-disabled': !valid }. It works properly.

I am using beta 14 + webpack

I received the No provider for ControlContainer! (NgControlName -> ControlContainer) error for not having the ngControl surrounded by a form tag.

Just for information, I ran into this issue as well after upgrading to beta11. This was caused by having form controls wrapped inside div elements with [hidden] directive set. Replacing [hidden] with *ngIf solved the issue.

@mohamedb @danielcreid that’s the normal behavior. The control must be inside of a form. On the other hand this issue is a bug since it’s completely ignoring that the control is inside a form.