Although there are many answers already and a link to a very good article on change detection, I wanted to give my two cents here. I think the check is there for a reason so I thought about the architecture of my app and realized that the changes in the view can be dealt with by using BehaviourSubject
and the correct lifecycle hook. So here's what I did for a solution.
So I ended up getting the underlying JavaScript class, and need to initialize my own calendar header for the component. That requires the ViewChild
to be rendered befor my parent is rendered, which is not the way Angular works. This is why I wrapped the value I need for my template in a BehaviourSubject<View>(null)
:
calendarView$ = new BehaviorSubject<View>(null);
Next, when I can be sure the view is checked, I update that subject with the value from the @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);
}
Then, in my template, I just use the async
pipe. No hacking with change detection, no errors, works smoothly.
Please don't hesitate to ask if you need more details.