ChangeDetectorRef `markForCheck` doesn't behave properly in Angular Elements
See original GitHub issue🐞 bug report
Affected Package
The issue is caused by package @angular/elements
Is this a regression?
No
Description
Invoking changeDetectorRef.markForCheck()
doesn’t work properly inside of an Angular Element in some cases.
This issue surfaced when I tried to use ng-select within a Custom Element and noticed that external binding changes were not being propagated. I was able to the debug the issue and come up with a minimal reproduction.
🔬 Minimal Reproduction
https://stackblitz.com/edit/angular-elements-markforcheck
In this example there is a native Angular and custom element implementation which both use a simple ControlValueAccessor
child component w/ OnPush
change detection. If markForCheck()
is called in the component’s writeValue()
it updates the value in the native component but not the Custom Element.
Interesting to note, either of the following DO work:
this.cd.detectChanges();
this.zone.run(() => this.cd.markForCheck());
🔥 Exception or Error
None, values are just not updated properly.
🌍 Your Environment
Angular Version:
Not from ng version
, but I pasted the dependencies from the StackBlitz:
"dependencies": {
"@angular/animations": "^10.0.1",
"@angular/common": "^10.0.1",
"@angular/compiler": "^10.0.1",
"@angular/core": "^10.0.1",
"@angular/elements": "^10.0.2",
"@angular/forms": "^10.0.1",
"@angular/platform-browser": "^10.0.1",
"@angular/platform-browser-dynamic": "^10.0.1",
"@angular/router": "^10.0.1",
"@webcomponents/custom-elements": "^1.4.1",
"@webcomponents/webcomponentsjs": "^2.4.3",
"rxjs": "^6.5.5",
"tslib": "^2.0.0",
"zone.js": "^0.10.3"
},
"devDependencies": {
"@angular-devkit/build-angular": "~0.10.0",
"@angular/cli": "9.0.0-rc.7",
"@angular/compiler-cli": "9.0.0-rc.7",
"@angular/language-service": "~7.0.0",
"ts-node": "~7.0.0",
"tslint": "~5.11.0",
"typescript": "~3.1.1"
}
Anything else relevant? Also occurs in Angular 9.1.9.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (3 by maintainers)
Top GitHub Comments
Ah, you are correct. Running it locally it does appear that the issue is fixed with #37814. Thanks!
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.