Hi @romansattler, it's a unclear to me why writeValue should be called before ngOnInit. It currently behaves like other inputs would, i.e. that value gets set before ngOnInit: example. It seems like this would be working as intended.

For the NgControl case, this is not behaviorally consistent. If you use NG_VALUE_ACCESSOR for the control value accessor, then ngOnInit is called before writeValue, whereas with the new way that @romansattler pointed out, ngOnInit is called after writeValue. This is likely where he discovered the bug and definitely caused us a lot of headaches as well.

stackblitz

Any update on this? I experience the same issue, the workaround I use is to add setTimeout in writeValue function but it's not ideal

  writeValue(valueToWrite: string) {
    setTimeout(() => {
      if (valueToWrite !== undefined) {
        this.value = valueToWrite;
      }
    });
  }

Currently ran into this issue recently when initialising a form group via FormBuilder which is made up of custom reactive form controls, one using the NgControl constructor injection approach instead of the usual provide NG_VALUE_ACCESSOR approach. In the writeValue function theres some logic to target the ngControl.control which gets executed when we call a setValue() on the control with an initial value we get from an API call which is being ran before the ngControl.control has had time to initialise (the ngControl has been initialised however). A work around I've done is override the original writeValue() and check the ngControl.control is present prior to it being accessed.

I have encountered the same issue when injecting NgControl. In writeValue I don't have my inner form initialized just yet since it needs some info from ngControl.control which I can obtain only in ngOnInit.

I would like to be volunteer for this bug. Please assign this bug to me . grajeshg2000

Thanks @grajeshg2000 - please coordinate with @AndrewKushnir on any fix you would propose.

The bug reproduction code is using angular/forms and angular/material libraries.
I have removed the material related code from reproduction code, Bug is still coming.
So this problem is not because of material library, instead the problem is in angular/form. Now I am debugging angular form to find out the problem.

Hi @grajeshg2000, could you please share a link to a simplified repro (without Material), so we can have a look? Thank you.

code lies in https://stackblitz.com/edit/angular-ivy-2rrugb

@grajeshg2000

I can't see any @angular/material dependencies included.

I have the same issue. Any update?

I have the same issue as well. My component implements ControlValueAccessor, injects ngControl in the constructor, and sets ngControl.valueAccessor = this . I don't specify providers in order to avoid the error for circular references due to having multiple valueAccessors.

When trying to initial variables from ViewChild, I cache a reference for using in the renderer, for example:
@ViewChild('input', { static: true, read: ElementRef }) input: ElementRef;
inputEl : HTMLInputElement;

ngAfterViewInit() {
this.inputEl = this.input.nativeElement;
this.renderer.setAttribute(inputEl, 'id', this.id);
}

If I try to use this.inputEl in the writeValue method, it throws an undefined error for inputEl. As a workaround, I use the following in the writeValue method which is to just use input.nativeElement.

writeValue(value: any): void {
// update input field with value received from outer component
this.renderer.setProperty(this.input.nativeElement, 'value', value);
}

The real problem here is that you can't both provide NG_VALUE_ACCESSOR and inject NgControl, because implementations of NgControl internally inject NG_VALUE_ACCESSOR. That necessitates workarounds like the patching of NgControl.valueAccessor, which cause inconsistent behavior with writeValue.

I am too facing this issue on a custom control. Any current alternatives to the setTimeout() workaround?

I am too facing this issue on a custom control. Any current alternatives to the setTimeout() workaround?

not sure, but how about injecting the Injector itself into the constructor and getting ngControl (FormControl) through it and use providers as usual? It's a dirty fix, but it seems to work.

I am too facing this issue on a custom control. Any current alternatives to the setTimeout() workaround?

not sure, but how about injecting the Injector itself into the constructor and getting ngControl (FormControl) through it and use providers as usual? It's a dirty fix, but it seems to work.

That's the approach I'm following but for some reason writeValue gets called before ngOnInit in that case as opposed to when using NG_VALUE_ACCESSOR

See example app: https://stackblitz.com/edit/angular-ivy-mmcdey?file=src/app/custom-input-ngcontrol/custom-input-ngcontrol.component.html

It should always respect the same order of execution before or after init Lifecycle hooks (ngOnInit, ngAfterViewInit, etc) but always consistent

As a fun bonus of this angular 15 change
https://angular.io/guide/update-to-version-15#setdisabledstate-is-always-called-when-a-controlvalueaccessor-is-attached
setDisabledState joins writeValue in being called before ngOnInit when manually setting the valueAccessor in the constructor.
this.ngControl.valueAccessor = this;