Ngx-quill: Reactive Forms and OnPush

[mhagnumdw]

Hi!

With ChangeDetectionStrategy.OnPush the FormControl is not updated. Below is the stackblitz with the demo:
https://stackblitz.com/edit/angular-6-ngx-quill-formcontrol-onpush

Already tried with Angular 6, 7 and 8. And several versions of ngx-quill.

Please help me with possible solution.
Tks!

[KillerCodeMonkey]

just trigger change detection like you do it in other components with onPush:

<form [formGroup]="form">

  <quill-editor formControlName="editor" (onEditorChanged)="triggerChangeDetection()">
  </quill-editor>

  <input placeholder="This works" formControlName="test">

</form>

<br/>
Form Value (for debug):
<pre>{{ form.value | json }}</pre>

import { Component, ChangeDetectorRef, OnInit } from '@angular/core';
import { map, tap, shareReplay } from 'rxjs/operators';
import { FormGroup, FormBuilder, FormControl } from '@angular/forms';

@Component({
  selector: 'app-my-editor',
  templateUrl: './my-editor.component.html',
  styleUrls: ['./my-editor.component.css']
})
export class MyEditorComponent {

  form: FormGroup;

  constructor(fb: FormBuilder, private cdr: ChangeDetectorRef) {
    this.form = fb.group({
      editor: [`With ChangeDetectionStrategy.OnPush in AppComponent changes to the formControl of this field are not automatically reflected. Type something here and see that no longer reflects below. If you type something here, then click the input below and then click outside the input, the formControl value is updated.`],
      test: ['This works fine even with onpush'],
    });
  }

  triggerChangeDetection() {
    this.cdr.detectChanges()
  }
}

https://stackblitz.com/edit/angular-6-ngx-quill-formcontrol-onpush-fncsym?file=src%2Fapp%2Fapp.component.ts

And you should consider to enable default strategy per default and use onPush only for components you really want to handle change detection on your own. ;-)

[KillerCodeMonkey]

does it work for you?

[mhagnumdw]

Hi! Sorry for delay! Yes, that worked!

This strategy I had already made. But as the simple Input FormControl worked, I didn't understand why the editor's FormControl didn't work. I thought there was another way around this.

Tks for your prompt, detailed and accurate response!

[KillerCodeMonkey]

thats okay :). Thanks :)

Maybe because the editor is a custom compontent (custom control accessor) and not a default FormControl it behaves like any other own component - you need to say, when the change detection should check for changes.

[gilsdav]

@KillerCodeMonkey This is a workaround, not a bugfix.
This type of management should be done in your library.

[j2L4e]

@KillerCodeMonkey are you open for discussion here?

In my opinion the default behavior should be CD working in all cases including OnPush.
This is easily achieved by calling changeDetectorRef.markForCheck() on relevant changes. Maybe I'm missing something, so what's the reason for not going the "standard" way here?

People rarely need to manually handle CD, but if you wanted to get the current behavior, you'd always be able to call changeDetectorRef.detach().

[KillerCodeMonkey]

sure i am open for discussion or PRs.

in general i am planning to switch to onPush strategy for my components at all, because in general every angular app should use onPush (this should be the real default for angular projects)

[amakhrov]

I believe the core difference between native inputs (or, let's say, MatInputDirective attached to a native input) and Quill is that with native inputs, change event listener to an underlying input is attached using angular mechanism (either in a template, of via @HostBinding() decorator. All events handled this way automatically mark the component dirty. Hence your components don't normally need to deal with change detection when consuming such events.

With Quill, however, you naturally rely on Quill custom callbacks (this.quillEditor.on(...)). Angular doesn't know anything about those, so the component remains unchecked.

A more robust approach is to add .markForCheck in every Quill event handler. This way Quill could really be used as a drop-in replacement to a native input / textarea, with minimal changes at the consuming side.