cds-core incompatibility with Angular 12?

[hofalk]

Hi,

after upgrading to Angular 12 there were suddenly a few dozen warnings in my console:
"An update was requested (generally because a property was set) after an update completed, causing a new update to be scheduled. This is inefficient and should be avoided unless the next update can only be scheduled as a side effect of the previous update."

At first I thought it was some kind of change-detection issue with my components, but after some digging I found out, that some cds webcomponents seem to trigger the issue.... even without any template variables, just by using them plainly.

I created a stackblitz with the latest cds version (5.4.2) to demonstrate the issue:
https://stackblitz.com/edit/clarity-update-issue?devtoolsheight=33&file=src/app/app.component.html

You can see that three of the four cds-Elements in there trigger this warning (all but cds-input).
There are more, but I wanted to keep the example concise.

I wasn't able to find further information for that warning or a general workaround/fix, so I am unsure if this can be regarded a bug in clarity or maybe just an incompatibility with Angular 12?

[coryrylan]

Thank you for the stackblitz example of the issue. I will be taking a look at this and will post back with any updates.

[coryrylan]

Looking into this is a warning from our internal web component tooling (Lit) about detecting a potential performance issue. This warning only occurs in dev mode. In the stackblitz demo optimization of external dependencies is disabled ("optimization": { "scripts": true }...) which is causing Lit to run in dev mode. In dev mode its detecting Angular setting custom element attr/properties before lit has finished rendering triggering the warning. Here is a fork of the demo with the script optimization turned on and the custom elements running in prod mode.

https://stackblitz.com/edit/clarity-update-issue-tfndv2?devtoolsheight=33&file=angular.json

"development": {
    "buildOptimizer": false,
    "optimization": {
      "scripts": true,
      "styles": {
        "minify": true,
        "inlineCritical": false
      },
      "fonts": true
    },

The performance impact of this should be minimal. When angular and lit are running in prod mode the custom element property setters should be called less frequent. In cases of multiple sets the custom elements are small and fairly inexpensive when re-rendering.

[hofalk]

I see, thanks for taking the time to investigate this. Very good to know this is causing no real issues for production indeed.

For now I resolved to filtering all warnings in console (as I said, there are dozens accumulating over time). But this is also not optimal as it may hide more serious issues.

So if I understand you correctly, changing the optimization settings for development is the way to go (for now) ? Can this lead to other potential side-effects, or "real" issues not being detected?

[coryrylan]

For now with development yes that should be ok. By enabling that setting it also makes the build closer to the production output by using the production versions of dependencies. However, it may be slightly slower in watch mode with those settings. You may be able to try something like this to only optimize the third party scripts/dependencies.

"development": {
    "buildOptimizer": false,
    "optimization": {
      "scripts": true,
      "styles": {
        "minify": false,
        "inlineCritical": false
      },
      "fonts": false
    },

The performance hit for our components getting rendered multiple times is pretty minimal but I am going to still investigate what in particular Angular is doing to trigger the setters to get called multiple times on the custom element.