Angular 12 migration leads to huge amounts of Change Detection cycles

[cjohn001]

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

CLI: 8.0.2
"@nativescript/core": "~8.0.0"
"@nativescript/android": "8.0.0",
"@nativescript/ios": "JSC",
"@angular/*": "~12.1.2",
"@nativescript/angular": "~12.0.6"
Describe the bug
After migration to the Angular 12 I am observing huge amounts of Change Detection cycles. About 50 cycles when navigating to an empty page, and about 300 cycles when navigating to a page with content.

Cycles where measured via calls to ngAfterViewChecked().

Note: For everyone observing the same issue. A workaround exists my setting up Angular as follows. I am not sure yet. if this breaks other things:

appModuleBootstrap: (reason: string) =>
platformNativeScript().bootstrapModule(AppModule, { ngZoneEventCoalescing: true })

[edusperoni]

This is an unfortunate result of actually patching all the nativescript apis with Zone (It just means a lot of events are firing and we're correctly running CD when that happens).

We should be releasing a beta shortly with #26 which also adds support for multithreaded js (js is still single threaded, but the js code may be running in a different android thread). This implementation also uses ngZoneEventCoalescing and ngZoneRunCoalescing set to true by default, so please try it out.

It shouldn't break the app like before. Angular's implementation uses requestAnimationFrame, which may delay things for a full frame, and it's probably what broke a few apps.

To use it, just do:

import { NativeScriptNgZone, platformNativeScript, runNativeScriptAngularApp } from '@nativescript/angular';

import { AppModule } from './app/app.module';

runNativeScriptAngularApp({
  appModuleBootstrap: () => platformNativeScript().bootstrapModule(AppModule, {ngZone: new NativeScriptNgZone()}),
});

[cjohn001]

@edusperoni: Thank you very much for the update. I am currently already playing around with ZoneRun- and EventCoalescing options. Unfortunately, it is breaking different things. I have not reported it yet as I have not had the time to write demos. Currently I am using it the following way:

platformNativeScript().bootstrapModule(AppModule, { ngZoneRunCoalescing: false, ngZoneEventCoalescing: false }),

When I set ngZoneRunCoalescing = true , transparencies are not rendered correctly. First image shows how it looks like with ngZoneRunCoalescing = false and second one the broken rendering set to true (in both cases ngZoneEventCoalescing: false)

When setting ngZoneEventCoalescing: true ( ngZoneRunCoalescing: false) I have found a weird bug together with the use of @nativescript-community/ui-material-tabs. I have a child tab in there which registers to navigatedTo events. In case of the flag set to true the event is not firing.

this.page.on('navigatedTo', this.onNavigatedTo.bind(this));

But as I see from your code snipped I seem to have activated it in the wrong way as I have not provided a new ngZone parameter like you mentioned. I will try this and report back to you as soon as possible. I broke another plugin, which I first need to fix before looking at it :)

For NativeScriptNgZone, do I have to install next version of the Angular package? Works together with angular 12.2? Seems @nativescript/angular 12.0.6 is lates package on npm. Does not have it included. Can you provide me the name of the package I need to install?

[edusperoni]

@cjohn001 the beta version is still not up, it seems, @NathanWalker should publish it later.

I saw cases of the app breaking like that, and with this new NgZone it seems that's fixed. About the navigatedTo event and others, please note that ngOnInit may be called AFTER navigatedTo because ngOnInit runs at the first CD cycle. If you need to catch these events, it's better to bind them on constructor, just beware that your callbacks may be called before ngOnInit

[cjohn001]

@cjohn001 the beta version is still not up, it seems, @NathanWalker should publish it later.

I saw cases of the app breaking like that, and with this new NgZone it seems that's fixed. About the navigatedTo event and others, please note that ngOnInit may be called AFTER navigatedTo because ngOnInit runs at the first CD cycle. If you need to catch these events, it's better to bind them on constructor, just beware that your callbacks may be called before ngOnInit

Thanks for the advice. Unfortunately, the registration of the event I am doing already in the constructor. It is also interesting to note, the tab control still receives the navigatedTo event, but not the child view. I hope I can replicate the issue in a demo project. This should make debugging things a lot more easy

[edusperoni]

Btw, I added a helper for these kinds of events (still undocumented and subject to change in the future):

@NativeScriptNgSafeEvent('ngOnInit')
myCallback() {
  console.log('this will never run before ngOnInit')
}

that's useful for nativescript callbacks as they can be called before the components are ready, so you can delay them.

If you're having issues and it's being registered in the constructor, most likely the page is already loaded and your view was created after initial CD (like when it's wrapped in an ngIf). You can use PageService that has a lot of goodies around this, and also keeps track if the page is the current one or not:

constructor(pageService: PageService) {
  this.pageService.inPage$.subscribe((isInPage) => /* isInPage is true when the page is the current one */);
}

you can also use pageEvents$ which will fire all the 4 page navigation events

[cjohn001]

Ok, great, thanks a lot! So you recommend to not stick with navigatedTo event but use one of these mechanisms? Or you consider it as a workaround till we get the navigatedTo stuff right? In that case I would provide a bug report

[edusperoni]

@cjohn001 I consider the best practice to not rely on navigatedTo for components that are not pages themselves (aren't used in the routing module). The reason being that, for example, if you have them in a tabview, listview, or others that are similar, the templates may not be loaded at the start (tabview keeps a few tabs unloaded, so depending on how your view was rendered, you can't guarantee that the component will be shown synchronously, so it'll miss the first navigation event).

I believe current lifecycle is:

navigatingTo
// render the page component here
page.isLoaded = true;
navigatedTo
// CD might have kicked in async and create pending templates here
navigatingFrom
page.isLoaded = false;
navigatedFrom

The most reliable way to check if you're in page is to check if the page is loaded (or use PageService, which will do that for you). This happens a lot with the loaded event, the only reason you don't see issues about it is because we do some special handling (we manually fire a 'loaded' event when you're trying to bind 'loaded' to an already loaded view):

https://github.com/NativeScript/angular/blob/main/packages/angular/src/lib/nativescript-renderer.ts#L261-L269

[edusperoni]

@cjohn001 a new rc was just published, you can try it now.

[cjohn001]

Thank you very much for the info. Then I will go with the PageService in the future. I assume it is part of nativescript/angular as well?
Maybe a last question which is a little of topic, but I have not so often the chance to speak with someone so deep involved :) The only reason I am currently working with page events in Angular is, that I have issues with page transitions (very bad on Android). I typically use a data service to bring the data in to the component. I set the observables of the service usually up in ngOnInit. Unfortunately, I often run into the situation, that they fire during the page. The transition then breaks (no smooth transition) In this situtation I store the data from the dataservice in a temporary variable and then bind them to the component on pageLoaded. I unfortunately have not a found a description yet if for nativescript, ngOnInit is the right way to set up observables. And a second issue of it is, that I always have to show a loading message as the page has to be rendered twice. I have seen that I can preload data with a kind of route guard. Maybe this is the better way to go. Have not tried this yet as I assumed page transitions then feel even slower. What would be your recommendation to bring in the data from the service without interfering the page transitions? I was also thinking about using a second thread for the data processing.

[cjohn001]

@cjohn001 a new rc was just published, you can try it now.

I am on it

[cjohn001]

@edusperoni , @NathanWalker: Very great work gentlemen. My app now for the very first time feels like a real native app. Huge performance gain!! I have one issue with it left now. Nathan knows the issue already. I have a problem with the pro-ui calendar (not an angular thing) which at initial rendering always renders with the default styles rather than the configured styles.
I have access to the plugins-ui repo. After the latest changes in the repo I am unfortunately not able anymore, to build the native calendar demo. A webpack dependency is reported missing which I cannot resolve, I posted an issue in the plugins-ui repo with the error log. If someone of you could look into this, I would invest the rest of the weekend to try to solve the calendar bug thing, see video attached. With the great performance gain the initially loaded calendar view now always appears broken. Before, one could only observe the problem when the app came from background.

Bildschirmaufnahme.2021-08-14.um.00.43.15.mov

[NathanWalker]

Thanks @cjohn001 I’ll take a look at that repo in a bit.

[NathanWalker]

@cjohn001 https://github.com/NativeScript/plugins-ui/issues/6#issuecomment-898772644

[cjohn001]

@edusperoni, @NathanWalker : Hello, I would like to come back on you regarding the new ns zone feature:

ngZone: new NativeScriptNgZone({
enableLongStackTrace: false,
shouldCoalesceEventChangeDetection: true,
shouldCoalesceRunChangeDetection: true
})

On some pages of my app, I am now observing wrongly computed layouts during initial rendering. If I set both coalescing features to false the layouts are working. Attached you see two pictures of a page transition sequence. One can see that the header height looks broken during the transition. Furthermore, it looks like not all elements of the child component (the header fields) are processed when the renderer jumps in.
The header is in a grid layout with row set to auto in the usual case. However, I did extensive testing now. Even if I set the row-height to a fixed height, say row="150" the height is wrong during initial rendering. Would be great if you could have another look into the optimization.
I would also like to note here, that I introduced an angular route resolver in the meantime. Hence, it is guaranteed, that all data relevant for rendering already exist on initial rendering. Photos were made without the resolver. However, the results look exactly the same.

Bildschirmaufnahme.2021-08-15.um.18.17.27.mov

I am not sure if I have enough background knowledge, to start this discussion. However, I would like to mention an observation here. I have spent the last two days now also trying to fix the UI-Pro calendar plugin and I have observed the issue already in the nativescript-ui-charts plugin for which I recently tried to implement angular property bindings.
I always seem to hit the same issue. It seems like when a page is first rendered, i.e. transition to page, it is not guaranteed that all property bindings (value changed events on properties) of the view have been evaluated.
To my understanding after view creation this is the first possibility to apply user configuration. Or is there some other option in the views lifecycle where I can provide user input before the view is rendered? I am not aware of for now.
Might this be a bug in the renderer, that it jumps in too early before layout of all components is finished?
And second observation in this respect. When new data from observables (setup in ngOnInit) start firing during page transitions, they break the page transition. Would it be possible, to lock rendering of new pages during page transitions? I think it should not be the responsibility of a programmer to manually synchronize code execution with page transitions, which also looks rather difficult when doing async stuff. To my opinion, it should be handled by the framework

[edusperoni]

@cjohn001 can you try it with this? https://drive.google.com/file/d/1_akzc_l_Tb5NxcUqF8gGFgr7MOOs4lXz/view?usp=sharing

It's the packed #27. Should trigger CD before the views are attached to the native view tree at all

For you async things, you can do:

combineLatest([this.pageService.inPage$, yourObservable]).pipe(
  filter(([inPage]) => inPage),
  map(([,yourValue]) => yourValue),
  distinctUntilChanged()
)

This will ensure your observable will only dispatch the event after navigation.