Jak zarządzać wyjątkiem „wyrażenie zmieniło się po sprawdzeniu” w Angular2, gdy właściwość komponentu zależy od bieżącej daty i godziny

Mój komponent ma style zależne od bieżącej daty i godziny. W moim komponencie mam następującą funkcję.

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

lightnessAmpjest obliczany na podstawie bieżącej daty i godziny. Kolor zmienia się, jeśli dtoDatewystąpił w ciągu ostatnich 24 godzin.

Dokładny błąd jest następujący:

Wyrażenie zmieniło się po sprawdzeniu. Poprzednia wartość: „hsl (123, 80%, 49%)”. Aktualna wartość: „hsl (123, 80%, 48%)”

Wiem, że wyjątek pojawia się w trybie programistycznym tylko w momencie sprawdzania wartości. Jeśli zaznaczona wartość różni się od zaktualizowanej wartości, zostanie zgłoszony wyjątek.

Próbowałem więc zaktualizować bieżącą datę i godzinę w każdym cyklu życia w następujący sposób, aby zapobiec wyjątkowi:

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

... ale bez powodzenia.

Uruchom wykrywanie zmian jawnie po zmianie:

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();
    });
}

Chociaż jest to obejście, czasami naprawdę trudno jest rozwiązać ten problem w lepszy sposób, więc nie obwiniaj siebie, jeśli używasz tego podejścia. W porządku.

Przykłady : początkowy problem [ link ], rozwiązany za pomocą setTimeout()[ link ]

Jak ominąć

Ogólnie ten błąd występuje zwykle po dodaniu czegoś (nawet w komponentach nadrzędnych / podrzędnych) ngAfterViewInit. Więc pierwsze pytanie brzmi: czy mogę żyć bez ngAfterViewInit? Być może gdzieś przenosisz kod ( ngAfterViewCheckedmoże to być alternatywa).

Przykład : [ link ]

Również

Również rzeczy asynchroniczne, ngAfterViewInitktóre mają wpływ na DOM, mogą to powodować. Można to również rozwiązać za pomocą setTimeoutlub dodając delay(0)operator w potoku:

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

Przykład : [ link ]

Miłe czytanie

Dobry artykuł o tym, jak to debugować i dlaczego tak się dzieje: link

Jak wspomniał @leocaseiro w sprawie github .

Znalazłem 3 rozwiązania dla tych, którzy szukają łatwych rozwiązań.

1) Przejście z ngAfterViewInitdongAfterContentInit

2) Przejście do ngAfterViewCheckedpołączonych z ChangeDetectorRefzgodnie z sugestią # 14748 (komentarz)

3) Kontynuuj z ngOnInit (), ale wywołaj ChangeDetectorRef.detectChanges()po wprowadzeniu zmian.

Jej masz dwa rozwiązania!

1. Zmodyfikuj ChangeDetectionStrategy na OnPush

W przypadku tego rozwiązania w zasadzie podasz kąt:

Przestań sprawdzać zmiany; zrobię to tylko wtedy, gdy wiem, że jest to konieczne

Szybka naprawa:

Zmodyfikuj swój komponent, aby używał ChangeDetectionStrategy.OnPush

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

Dzięki temu rzeczy już nie działają. To dlatego, że od teraz będziesz musiał detectChanges()ręcznie wywoływać Angular .

this.cdr.detectChanges();

Oto link, który pomógł mi dobrze zrozumieć ChangeDetectionStrategy : https://alligator.io/angular/change-detection-strategy/

2. Zrozumienie ExpressionChangedAfterItHasBeenCheckedError

Oto mały fragment odpowiedzi tomonari_t na temat przyczyn tego błędu, próbowałem zawrzeć tylko te części, które pomogły mi to zrozumieć.

Pełny artykuł zawiera prawdziwe przykłady kodu dotyczące każdego punktu pokazanego tutaj.

Główną przyczyną jest kątowy cykl życia:

Po każdej operacji Angular pamięta, jakich wartości użył do wykonania operacji. Są one przechowywane we właściwości oldValues ​​widoku komponentu.

Po sprawdzeniu wszystkich składników, Angular rozpoczyna następny cykl podsumowania, ale zamiast wykonywać operacje, porównuje bieżące wartości z wartościami, które pamięta z poprzedniego cyklu podsumowania.

Następujące operacje są sprawdzane w cyklu podsumowania:

sprawdź, czy wartości przekazywane do komponentów podrzędnych są takie same, jak wartości, które byłyby teraz używane do aktualizacji właściwości tych komponentów.

sprawdź, czy wartości używane do aktualizacji elementów DOM są takie same, jak wartości, które byłyby używane do aktualizacji tych elementów, teraz działają tak samo.

sprawdza wszystkie komponenty potomne

I tak błąd jest generowany, gdy porównywane wartości są różne. , bloger Max Koretskyi stwierdził:

Winowajcą jest zawsze składnik potomny lub dyrektywa.

I na koniec kilka przykładów z rzeczywistego świata, które zwykle powodują ten błąd:

• Usługi wspólne
• Synchroniczne nadawanie wydarzeń
• Dynamiczne tworzenie instancji komponentów

Każdy przykład można znaleźć tutaj (plunkr), w moim przypadku problemem była dynamiczna instancja komponentu.

Również z własnego doświadczenia zdecydowanie polecam wszystkim unikanie setTimeoutrozwiązania, w moim przypadku spowodowało to "prawie" nieskończoną pętlę (21 wezwań, których nie jestem skłonny pokazać, jak je sprowokować),

Radziłbym zawsze pamiętać o cyklu życia Angulara, abyś mógł wziąć pod uwagę, jak wpłynie to na nie za każdym razem, gdy modyfikujesz wartość innego komponentu. Z tym błędem Angular mówi ci:

Może robisz to w niewłaściwy sposób, czy na pewno masz rację?

Ten sam blog mówi również:

Często rozwiązaniem jest użycie odpowiedniego zaczepu do wykrywania zmian w celu utworzenia komponentu dynamicznego

Krótkim przewodnikiem dla mnie jest rozważenie co najmniej dwóch następujących rzeczy podczas kodowania ( z czasem postaram się to uzupełnić ):

1. Unikaj modyfikowania wartości komponentu nadrzędnego z jego komponentów podrzędnych, zamiast tego: modyfikuj je z jego rodzica.
2. Podczas korzystania z dyrektyw @Inputi @Outputstaraj się unikać wyzwalania zmian w cyklu życia, chyba że składnik zostanie całkowicie zainicjowany.
3. Unikaj niepotrzebnych wywołań, this.cdr.detectChanges();które mogą powodować więcej błędów, szczególnie gdy masz do czynienia z dużą ilością danych dynamicznych
4. Gdy użycie this.cdr.detectChanges();jest obowiązkowe, upewnij się, że używane zmienne ( @Input, @Output, etc) są wypełnione / zainicjowane na prawym haku wykrywania ( OnInit, OnChanges, AfterView, etc)
5. Jeśli to możliwe, raczej usuń niż ukryj , jest to związane z punktem 3 i 4.

Również

Jeśli chcesz w pełni zrozumieć Angular Life Hook, polecam przeczytanie oficjalnej dokumentacji tutaj:

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

W naszym przypadku NAPRAWIONO przez dodanie changeDetection do komponentu i wywołanie funkcji detekcji zmian () w ngAfterContentChecked, kod w następujący sposób

@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();
  }

}

Myślę, że najlepszym i najczystszym rozwiązaniem, jakie możesz sobie wyobrazić, jest:

@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 }
    );
  }
}

Testowane z Angular 5.2.9

Mała praca, z której korzystałem wiele razy

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

Głównie zastępuję "null" jakąś zmienną, której używam w kontrolerze.

Chociaż jest już wiele odpowiedzi i link do bardzo dobrego artykułu o wykrywaniu zmian, chciałem tutaj dać swoje dwa centy. Myślę, że to sprawdzenie ma swój powód, więc pomyślałem o architekturze mojej aplikacji i zdałem sobie sprawę, że zmiany w widoku można rozwiązać, używając BehaviourSubjecti prawidłowego haka cyklu życia. Oto, co zrobiłem dla rozwiązania.

• Używam komponentu innej firmy ( pełny kalendarz) , ale używam również Angular Material , więc chociaż stworzyłem nową wtyczkę do stylizacji, uzyskanie wyglądu i stylu było nieco niezręczne, ponieważ dostosowanie nagłówka kalendarza nie jest możliwe bez rozwidlenia repozytorium i twórz własne.

• Ostatecznie otrzymałem podstawową klasę JavaScript i muszę zainicjować własny nagłówek kalendarza dla komponentu. Wymaga ViewChildto renderowania przed renderowaniem mojego rodzica, co nie jest sposobem, w jaki działa Angular. Dlatego zawarłem wartość, której potrzebuję dla mojego szablonu w BehaviourSubject<View>(null):

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

Następnie, gdy mam pewność, że widok jest zaznaczony, aktualizuję ten temat o wartość z @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);
  }

Następnie w moim szablonie po prostu używam asyncrury. Bez hakowania z wykrywaniem zmian, bez błędów, działa płynnie.

Nie wahaj się zapytać, czy potrzebujesz więcej informacji.

Użyj domyślnej wartości formularza, aby uniknąć błędu.

Zamiast korzystać z akceptowanej odpowiedzi, jaką jest zastosowanie funkcji detekcji zmian () w ngAfterViewInit () (co również rozwiązało błąd w moim przypadku), zdecydowałem się zamiast tego zapisać wartość domyślną dla dynamicznie wymaganego pola formularza, tak aby przy późniejszej aktualizacji formularza, jego ważność nie jest zmieniana, jeśli użytkownik zdecyduje się zmienić opcję w formularzu, która spowoduje uruchomienie nowych wymaganych pól (i wyłączenie przycisku przesyłania).

Pozwoliło to zaoszczędzić trochę kodu w moim komponencie, aw moim przypadku całkowicie uniknięto błędu.

Otrzymałem ten błąd, ponieważ zadeklarowałem zmienną, a później chciałem
zmienić jej wartość za pomocąngAfterViewInit

export class SomeComponent {

    header: string;

}

naprawić to, z czego się zmieniłem

ngAfterViewInit() { 

    // change variable value here...
}

do

ngAfterContentInit() {

    // change variable value here...
}