Come gestire l'eccezione "espressione è cambiata dopo che è stata controllata" Angular2 quando una proprietà del componente dipende dal datetime corrente

Il mio componente ha stili che dipendono dal datetime corrente. Nel mio componente ho la seguente funzione.

  private fontColor( dto : Dto ) : string {
    // date d'exécution du dto
    let dtoDate : Date = new Date( dto.LastExecution );

    (...)

    let color =  "hsl( " + hue + ", 80%, " + (maxLigness - lightnessAmp) + "%)";

    return color;
  }

lightnessAmpviene calcolato dal datetime corrente. Il colore cambia se dtoDateè nelle ultime 24 ore.

L'errore esatto è il seguente:

L'espressione è cambiata dopo essere stata controllata. Valore precedente: 'hsl (123, 80%, 49%)'. Valore attuale: 'hsl (123, 80%, 48%)'

So che l'eccezione appare in modalità di sviluppo solo al momento del controllo del valore. Se il valore selezionato è diverso dal valore aggiornato, viene generata l'eccezione.

Quindi ho cercato di aggiornare il datetime corrente ad ogni ciclo di vita nel seguente metodo hook per evitare l'eccezione:

  ngAfterViewChecked()
  {
    console.log( "! changement de la date du composant !" );
    this.dateNow = new Date();
  }

... ma senza successo.

Esegui il rilevamento delle modifiche in modo esplicito dopo la modifica:

import { ChangeDetectorRef } from '@angular/core';

constructor(private cdRef:ChangeDetectorRef) {}

ngAfterViewChecked()
{
  console.log( "! changement de la date du composant !" );
  this.dateNow = new Date();
  this.cdRef.detectChanges();
}

TL; DR

ngAfterViewInit() {
    setTimeout(() => {
        this.dateNow = new Date();
    });
}

Anche se questa è una soluzione alternativa, a volte è davvero difficile risolvere questo problema in modo più piacevole, quindi non incolpare te stesso se stai usando questo approccio. Va bene.

Esempi : il problema iniziale [ link ], risolto con setTimeout()[ link ]

Come evitare

In genere questo errore si verifica in genere dopo l'aggiunta da qualche parte (anche nei componenti padre / figlio) ngAfterViewInit. Quindi la prima domanda è porsi: posso vivere senza ngAfterViewInit? Forse sposti il ​​codice da qualche parte ( ngAfterViewCheckedpotrebbe essere un'alternativa).

Esempio : [ collegamento ]

Anche

Anche cose asincrone ngAfterViewInitche influenzano DOM potrebbero causare questo. Inoltre può essere risolto tramite setTimeouto aggiungendo l' delay(0)operatore nel tubo:

ngAfterViewInit() {
  this.foo$
    .pipe(delay(0)) //"delay" here is an alternative to setTimeout()
    .subscribe();
}

Esempio : [ collegamento ]

Buona lettura

Buon articolo su come eseguire il debug di questo e perché succede: link

Come menzionato da @leocaseiro sulla questione di github .

Ho trovato 3 soluzioni per coloro che sono alla ricerca di soluzioni facili.

1) Passaggio da ngAfterViewInitangAfterContentInit

2) Passaggio a ngAfterViewCheckedcombinato con ChangeDetectorRefcome suggerito su # 14748 (commento)

3) Continua con ngOnInit () ma chiama ChangeDetectorRef.detectChanges()dopo le modifiche.

Lei vai due soluzioni!

1. Modifica ChangeDetectionStrategy su OnPush

Per questa soluzione, in pratica dirai angolare:

Smettere di controllare le modifiche; lo farò solo quando so che è necessario

La soluzione rapida:

Modifica il componente in modo che possa essere utilizzato ChangeDetectionStrategy.OnPush

@Component({
  selector: 'app-child',
  templateUrl: './child.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class ChildComponent implements OnInit {
    // ...
}

Con questo, le cose sembrano non funzionare più. Questo perché d'ora in poi dovrai fare in modo che Angular chiami detectChanges()manualmente.

this.cdr.detectChanges();

Ecco un link che mi ha aiutato a capire bene ChangeDetectionStrategy : https://alligator.io/angular/change-detection-strategy/

2. Comprensione di ExpressionChangedAfterItHasBeenCheckedError

Ecco un piccolo estratto dalla risposta di tomonari_t sulle cause di questo errore, ho provato a includere solo le parti che mi hanno aiutato a capirlo.

L'articolo completo mostra esempi di codice reali su ogni punto mostrato qui.

La causa principale è il ciclo di vita angolare:

Dopo ogni operazione Angolare ricorda quali valori ha usato per eseguire un'operazione. Sono memorizzati nella proprietà oldValues ​​della vista componenti.

Dopo aver eseguito i controlli per tutti i componenti Angolare avvia quindi il successivo ciclo di digest ma invece di eseguire le operazioni confronta i valori correnti con quelli che ricorda del precedente ciclo di digest.

Le seguenti operazioni sono in fase di controllo presso il ciclo digest:

verificare che i valori passati ai componenti figlio siano gli stessi dei valori che ora verrebbero utilizzati per aggiornare le proprietà di questi componenti.

verifica che i valori utilizzati per aggiornare gli elementi DOM siano gli stessi dei valori che verrebbero utilizzati per aggiornare questi elementi ora eseguono lo stesso.

controlla tutti i componenti figlio

Quindi, l'errore viene generato quando i valori confrontati sono diversi. , il blogger Max Koretskyi ha dichiarato:

Il colpevole è sempre il componente figlio o una direttiva.

E finalmente ecco alcuni esempi del mondo reale che di solito causano questo errore:

• Servizi condivisi
• Trasmissione di eventi sincroni
• Istanziazione dinamica dei componenti

Ogni campione può essere trovato qui (plunkr), nel mio caso il problema era un'istanza di componente dinamica.

Inoltre, per mia esperienza, consiglio vivamente a tutti di evitare la setTimeoutsoluzione, nel mio caso ha causato un ciclo "quasi" infinito (21 chiamate che non sono disposto a mostrarti come provocarle),

Consiglio di tenere sempre presente il ciclo di vita angolare in modo da poter tenere conto di come sarebbero interessati ogni volta che si modifica il valore di un altro componente. Con questo errore Angular ti sta dicendo:

Forse lo stai facendo nel modo sbagliato, sei sicuro di avere ragione?

Lo stesso blog dice anche:

Spesso, la soluzione consiste nell'utilizzare il giusto hook di rilevamento delle modifiche per creare un componente dinamico

Una breve guida per me è quella di considerare almeno le seguenti due cose durante la codifica ( cercherò di completarlo nel tempo ):

1. Evita invece di modificare i valori dei componenti principali dai suoi componenti figlio, invece: modificali dai suoi genitori.
2. Quando si utilizzano @Inpute le @Outputdirettive si tenta di evitare di attivare le modifiche del ciclo di vita a meno che il componente non sia completamente inizializzato.
3. Evita chiamate inutili this.cdr.detectChanges();perché possono innescare più errori, specialmente quando hai a che fare con molti dati dinamici
4. Quando l'uso di this.cdr.detectChanges();è obbligatorio, assicurarsi che le variabili ( @Input, @Output, etc) utilizzate siano riempite / inizializzate al gancio di rilevamento destro ( OnInit, OnChanges, AfterView, etc)
5. Se possibile, rimuovere anziché nascondere , ciò è correlato ai punti 3 e 4.

Anche

Se vuoi comprendere appieno Angular Life Hook ti consiglio di leggere la documentazione ufficiale qui:

• https://angular.io/guide/lifecycle-hooks

Nel nostro caso abbiamo FISSO aggiungendo changeDetection nel componente e chiamando detectChanges () in ngAfterContentChecked, codice come segue

@Component({
  selector: 'app-spinner',
  templateUrl: './spinner.component.html',
  styleUrls: ['./spinner.component.scss'],
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class SpinnerComponent implements OnInit, OnDestroy, AfterContentChecked {

  show = false;

  private subscription: Subscription;

  constructor(private spinnerService: SpinnerService, private changeDedectionRef: ChangeDetectorRef) { }

  ngOnInit() {
    this.subscription = this.spinnerService.spinnerState
      .subscribe((state: SpinnerState) => {
        this.show = state.show;
      });
  }

  ngAfterContentChecked(): void {
      this.changeDedectionRef.detectChanges();
  }

  ngOnDestroy() {
    this.subscription.unsubscribe();
  }

}

Penso che la soluzione migliore e più pulita che tu possa immaginare sia questa:

@Component( {
  selector: 'app-my-component',
  template: `<p>{{ myData?.anyfield }}</p>`,
  styles: [ '' ]
} )
export class MyComponent implements OnInit {
  private myData;

  constructor( private myService: MyService ) { }

  ngOnInit( ) {
    /* 
      async .. await 
      clears the ExpressionChangedAfterItHasBeenCheckedError exception.
    */
    this.myService.myObservable.subscribe(
      async (data) => { this.myData = await data }
    );
  }
}

Testato con Angolare 5.2.9

Un piccolo lavoro intorno l'ho usato molte volte

Promise.resolve(null).then(() => {
    console.log( "! changement de la date du composant !" );
    this.dateNow = new Date();
    this.cdRef.detectChanges();
});

Sostituisco principalmente "null" con alcune variabili che uso nel controller.

Sebbene ci siano già molte risposte e un link a un ottimo articolo sul rilevamento delle modifiche, ho voluto dare qui i miei due centesimi. Penso che il controllo sia lì per un motivo, quindi ho pensato all'architettura della mia app e ho capito che le modifiche alla vista possono essere gestite utilizzando BehaviourSubjecte il gancio del ciclo di vita corretto. Quindi, ecco cosa ho fatto per una soluzione.

• Uso un componente di terze parti ( fullcalendar) , ma utilizzo anche materiale angolare , quindi anche se ho creato un nuovo plug-in per lo stile, l'aspetto e l'aspetto sono stati un po 'imbarazzanti perché la personalizzazione dell'intestazione del calendario non è possibile senza il fork del repository e rotolare il tuo.

• Quindi ho finito per ottenere la classe JavaScript sottostante e ho bisogno di inizializzare la mia intestazione del calendario per il componente. Ciò richiede ViewChildche sia reso prima che il mio genitore sia reso, il che non è il modo in cui funziona Angular. Ecco perché ho racchiuso il valore di cui ho bisogno per il mio modello in un BehaviourSubject<View>(null):

  calendarView$ = new BehaviorSubject<View>(null);

Successivamente, quando posso essere sicuro che la vista sia selezionata, aggiorno quell'oggetto con il valore di @ViewChild:

  ngAfterViewInit(): void {
    // ViewChild is available here, so get the JS API
    this.calendarApi = this.calendar.getApi();
  }

  ngAfterViewChecked(): void {
    // The view has been checked and I know that the View object from
    // fullcalendar is available, so emit it.
    this.calendarView$.next(this.calendarApi.view);
  }

Quindi, nel mio modello, utilizzo semplicemente il async pipe. Nessun hacking con rilevamento delle modifiche, nessun errore, funziona senza problemi.

Non esitate a chiedere se avete bisogno di maggiori dettagli.

Utilizzare un valore di modulo predefinito per evitare l'errore.

Invece di utilizzare la risposta accettata di applicare detectChanges () in ngAfterViewInit () (che ha anche risolto l'errore nel mio caso), ho deciso invece di salvare un valore predefinito per un campo modulo richiesto dinamicamente, in modo che quando il modulo viene successivamente aggiornato, la validità non viene modificata se l'utente decide di modificare un'opzione nel modulo che attiverà i nuovi campi obbligatori (e causerebbe la disabilitazione del pulsante di invio).

Ciò ha salvato un po 'di codice nel mio componente e nel mio caso l'errore è stato evitato del tutto.

Ho avuto quell'errore perché ho dichiarato una variabile e in seguito ho voluto
modificarne il valore usandongAfterViewInit

export class SomeComponent {

    header: string;

}

per risolvere il problema da cui sono passato

ngAfterViewInit() { 

    // change variable value here...
}

per

ngAfterContentInit() {

    // change variable value here...
}