bug: undetected initial prop value on Angular

[mamillastre]

Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already report this problem, without success.

Stencil Version

=4.36.0

Current Behavior

Since Stencil 4.36.0, an initial prop value can be undetected on a dynamically set Angular component.

For example, I use the following code to emulate the dynamic first prop value:

<my-component [first]="'issue'"></my-component>

I have the following logs:

@Prop() first!: string;
@Watch('first')
firstChanged() {
  console.log('CHANGE', this.first);
}

connectedCallback() {
  console.log('connectedCallback', this.first);
}

componentWillLoad() {
  console.log('componentWillLoad', this.first);
}

componentDidLoad() {
  console.log('componentDidLoad', this.first);
}

render() {
  console.log('render', this.first);
  ...
}

In runtime:

The value comes only at the second rendering, the prop has not been initialized before componentWillLoad and the Watch() method has not been called.
The prop update seems to be undetected but fire a rerender.

Note: I reproduced this issue only when the component is on a child routing page and when the app is loaded on this page (See reproduction steps).

Expected Behavior

The prop is available on componentWillLoad OR the Watch() method is called.

System Info

System: node 20.18.3
Platform: darwin (24.6.0)
CPU Model: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 cpus)
Compiler: /stencil-demo/packages/elements/node_modules/@stencil/core/compiler/stencil.js
Build: 1752598220
Stencil: 4.36.0 🎊
TypeScript: 5.5.4
Rollup: 4.34.9
Parse5: 7.2.1
jQuery: 4.0.0-pre
Terser: 5.37.0

Steps to Reproduce

• Clone the angular-issue branch from https://github.com/mamillastre/stencil-demo/tree/angular-issue
• In the root folder
• npm i
• npm run angular
• Open the running Angular app
• Open the dev console to see the logs
• Click on the "TEST" link
• Here the Watch() method is called

• Refresh the page (on the test page)
• The Watch() method is not called

If the stencil component is in the Angular root component (projects/angular-app/src/app/app.component.html), the prop is initialized on componentWillLoad.

Code Reproduction URL

https://github.com/mamillastre/stencil-demo/tree/angular-issue

Additional Information

The issue seems to come from Stencil v3.36.0.
Workaround: stay on the v3.35.3
I didn't try to reproduce on Vue or React.

[johnjenkins]

@danielleroux I'm pretty sure this is due to #6331 < do you have any insights?
(@mamillastre I believe this stems from Stencil components now rendering much faster - perhaps Angular sets properties too slowly)

[danielleroux]

@johnjenkins cannot reproduce the issue on our setup:

@siemens/ix:build: [55:51.9] @stencil/core
@siemens/ix:build: [55:52.0] v4.36.0 🎊

Also tested with v4.36.2 and angular 20

@mamillastre Maybe you can try to reproduce it based on the output-target repo.

[ben-hamida]

We're having a similar issue where in one particular place in our app componentWillLoad is called before the angular input has been set. We have other places with almost identical code using the same stencil component where it doesn't happen.

[mamillastre]

(@mamillastre I believe this stems from Stencil components now rendering much faster - perhaps Angular sets properties too slowly)

It can be the issue. But in this case, the @Watch() method should be called when the Angular value is initialized.

@johnjenkins cannot reproduce the issue on our setup:

@siemens/ix:build: [55:51.9] @stencil/core
@siemens/ix:build: [55:52.0] v4.36.0 🎊

Also tested with v4.36.2 and angular 20

@mamillastre Maybe you can try to reproduce it based on the output-target repo.

Do you reproduce on my repo ? https://github.com/mamillastre/stencil-demo/tree/angular-issue

[danielleroux]

(@mamillastre I believe this stems from Stencil components now rendering much faster - perhaps Angular sets properties too slowly)

It can be the issue. But in this case, the @Watch() method should be called when the Angular value is initialized.

@johnjenkins cannot reproduce the issue on our setup:

@siemens/ix:build: [55:51.9] @stencil/core
@siemens/ix:build: [55:52.0] v4.36.0 🎊

Also tested with v4.36.2 and angular 20 [@mamillastre](https://github.com/mamillastre) Maybe you can try to reproduce it based on the output-target repo.

Do you reproduce on my repo ? https://github.com/mamillastre/stencil-demo/tree/angular-issue

No there is to much stuff in there, I do not install any repo without knowing which dependencies in there. I would suggest use stencil/output-target fork to make a repo to show the issue.

[johnjenkins]

It does seem to be an issue; Ionic users have also reported it: ionic-team/ionic-framework#30613

[mamillastre]

@danielleroux, I forked the output-target repo and reproduced this issue in the issue-angular-prop-init branch: https://github.com/mamillastre/output-targets/tree/issue-angular-prop-init
Here is the commit detail: mamillastre/output-targets@358112c

[danielleroux]

@johnjenkins Do we have any angular dev's here who have some insights into change detection etc? The regular task queue uses requestAnimationFrame which works like desired.

The issue only happens with queueMicrotask. Same as providing taskQueue: 'immediate', inside the stencil.config.ts even without the changes of the queueMicrotask.

//Edit

Maybe a possible fix would be to put the lifecycle calls back into the event loop of the repaint frames.

export const safeCall = (instance: any, method: string, arg?: any, elm?: HTMLElement) => {
  if (instance && instance[method]) {
    try {
      return new Promise<void>((resolve) => {
        plt.raf(() => resolve(instance[method](arg)));
      });
    } catch (e) {
      consoleError(e, elm);
    }
  }
  return undefined;
};

//Edit 2

It looks promising If I put the lifecycle calls back into the repaint loop, but keep the initial rendering inside the microtask-loop.

[johnjenkins]

Do we have any angular dev's here who have some insights into change detection etc? The regular task queue uses requestAnimationFrame which works like desired.

@gratzl-dev maybe?

[danielleroux]

I dont have a solution right now. My current assumption is:

Actual issue:

1. lifecycle calls and initial rendering is called via queueMicrotask (safe time prior to control returning to the browser's event loop.)
2. lifecycle result: valueA = undefined
3. Angular try to perform the angular bindings `[value-a]="'demo'"
   ==> render dependent lifecycle functions will be execute before angular performs the binding

Putting lifecycle calls into requestAnimationFrame will not solve the issue:

1. initial rendering is called still via queueMicrotask
2. Angular try to perform the angular bindings `[value-a]="'demo'"
3. lifecycle calls are executed during requestAnimationFrame loop
4. lifecycle result `valueA = 'demo'

==> Problem componentWillRender and componentWillLoad has the following feature A promise can be returned, that can be used to wait for the upcoming render. This does not work for the initial rendering attempt.

Note: Graphics are super simplified and does not show 100% the execution order or architecture of stencil/angular. Theres are just my assumption of the issue. (Iam still no angular guy to understand every render detail there)

Solutions what I have in mind is, but not sure about:

• Make the queue configuration part of the @Component-decorator or event a runtime flag. Stencil developers can decide If they need the "faster-initial-rendering" or "controlled-rendering" behaviour.

[johnjenkins]

@danielleroux did you try adjusting the taskQueue option before your PR?
It is (or was?) async, perhaps you just wanted immediate and we can revert? idk - haven't looked much into it

[johnjenkins]

@danielleroux / @mamillastre - I've just noticed this hidden in Stencil's docs too ...

/**

• When a component is first attached to the DOM, this setting will wait a single tick before
• rendering. This works around an Angular issue, where Angular attaches the elements before
• settings their initial state, leading to double renders and unnecessary event dispatches.
• Defaults to false.
  */
  initializeNextTick?: boolean;

sounds relevant ... can someone experiment?

[danielleroux]

@danielleroux did you try adjusting the taskQueue option before your PR? It is (or was?) async, perhaps you just wanted immediate and we can revert? idk - haven't looked much into it

I dont think so because applying updates makes totally sense to do that only depending on the refresh rate and the initial render before the browser frame is shown.
If you look at the if-branch of the initializeNextTick there are two closed angular tickets.