Repository navigation
Angular 19 - Signal Inputs and Web Components routed vs page load #59757
Description
Which @angular/* package(s) are the source of the bug?
elements
Is this a regression?
Yes
Description
We are experiencing an issue with input signals in a web component. When navigating to a page containing the web component via routing, the input signals are set correctly. However, if the page is reloaded directly (e.g., by refreshing the browser), the input signals are not initialized as expected.
Switching from input() to @input resolves the issue. Below is a reproduction of the problem:
Steps to Reproduce:
Run the app and web component server as outlined in the README.
Navigate to http://localhost:5500/.
Click on "Go to Counter".
Observe that the initial values are correctly set to 5 and 10.
Refresh the browser.
Notice that the initial values revert to 0.
This behavior occurs for various input types, including booleans, objects, and numbers.
Please provide a link to a minimal reproduction of the bug
https://stackblitz.com/~/github.com/vickieallen-certua/angular-input-signals-web-components
Please provide the exception or error you saw
Please provide the environment you discovered this bug in (run ng version)
Angular CLI: 19.1.4
Node: 18.20.3
Package Manager: npm 10.2.3
OS: linux x64
Angular: 19.1.3
... animations, common, compiler, compiler-cli, core, elements
... forms, platform-browser, router
Package Version
---------------------------------------------------------
@angular-devkit/architect 0.1901.4
@angular-devkit/build-angular 19.1.4
@angular-devkit/core 19.1.4
@angular-devkit/schematics 19.1.4
@angular/cli 19.1.4
@schematics/angular 19.1.4
rxjs 7.8.1
typescript 5.5.4
zone.js 0.15.0
Anything else?
No response
Activity
alxhub commentedon Jan 28, 2025
The difference between the two modes of operation is whether the custom element is defined at the time the Angular bindings to it are evaluated. If it's not defined, then the bindings to
[initialValue]and[initialValueNoSignal]are written as plain properties on the un-upgraded element.This evaluation races with the registration of the custom element, which will eventually activate and perform
Object.definePropertyfor each input on the element prototype.Angular has code which runs during the registration and searches for properties on the element itself which represent inputs, preserving their values during this transition.
For some reason, I chose to exclude signal inputs from this logic:
angular/packages/elements/src/create-custom-element.ts
Line 160 in ccebbba
I suspect this is a mistake. If I remember, I misunderstood this section of code as deleting and re-applying the value to the component class, but that's not what it does. It deletes the input value from the element DOM node and saves it for a write to the component class when it's created.
If so, this is a trivial fix, but will need to be TGP'd as the consequences here might be surprising.
fix(elements): not setting initial value on signal-based input
fix(elements): not setting initial value on signal-based input (#59773)
fix(elements): not setting initial value on signal-based input (angul…
fix(elements): not setting initial value on signal-based input (angul…
angular-automatic-lock-bot commentedon Mar 1, 2025
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.