Angular Elements doesn't bind existing property values to component inputs #30848

antch · 2019-06-04T13:42:16Z

🐞 bug report

Affected Package

The issue is caused by package @angular/elements

Is this a regression?

Unsure.

Description

If a DOM element has existing properties prior to being loaded/initialized by Angular Elements, they are not bound to component inputs.

🔬 Minimal Reproduction

https://stackblitz.com/edit/angular-elements-test-existing-bindings

🔥 Exception or Error

No error occurs, properties are not bound.

🌍 Your Environment

Angular Version:


Angular CLI: 7.3.9
Node: 10.14.2
OS: darwin x64
Angular: 7.2.15
... animations, common, compiler, compiler-cli, core, elements
... forms, http, language-service, platform-browser
... platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.13.9
@angular-devkit/build-angular     0.13.9
@angular-devkit/build-optimizer   0.13.9
@angular-devkit/build-webpack     0.13.9
@angular-devkit/core              7.3.9
@angular-devkit/schematics        7.3.9
@angular/cdk                      7.2.2
@angular/cli                      7.3.9
@ngtools/webpack                  7.3.9
@schematics/angular               7.3.9
@schematics/update                0.13.9
rxjs                              6.4.0
typescript                        3.2.4
webpack                           4.29.0

The text was updated successfully, but these errors were encountered:

antch · 2019-06-05T14:43:56Z

Just to add additional context, one of the reasons why this bug is so frustrating is that the only work-around (if you can even call it that) that works with AoT is to iterate through the property names and try to reconcile the values from the injected element. This is obviously not maintainable.

At least if ngOnChanges was called, even if it was late done late, we would be able to work-around the bug in a more generic way.

Following this, once this bug is fixed it should be ensured that ngOnChanges is invoked for these properties with firstChange so that behavior of lifecycle hooks is consistent with a normal Angular component.

CollinGraf314 · 2019-06-13T20:55:15Z

+1
I have come across this issue too.

My use case is that I have an Angular Element nested in a JQuery application and I would like to be able to pass complex data from my JQuery app to my custom element. It seems there are several ways of doing this, but the most appropriate and easiest to implement is to pass the object through a property. Currently the Angular Element code does not acknowledge any changes I make to it's corresponding custom element's property values, so I have to use the much less elegant solution of stringifying my object, passing the stringified data through an attribute, then in the Angular Element parsing the string to rebuild my object.

This leaves messy HTML (if you view it through the developer tools) and adds the unnecessary overhead of having to stringify/parse my data.

antch · 2019-06-13T21:21:10Z

Your issue sounds like maybe a different thing. You really shouldn't have a problem with jQuery, you should be able to set the property with .prop() and it should bind properly. The issue here is when the property is set on the element prior to being added to the DOM.

$(function() {
    $('#myCustomElement').prop('myProp', [ 'some', 'stuff', 'here' ]);
});

I've tried the above and it works.

CollinGraf314 · 2019-06-14T13:41:36Z

Hmmm... I'll look into making a minimum reproduction of my issue. My current implementation is

const customElement = document.createElement('custom-element');
jQuery('#location_to_add').after(customElement);
customElement.propertyToSet = someObject;
// also tried
// jQuery('custom-element').prop('propertyToSet', someObject);

In my Angular Element no change detection fires in either case and 'propertyToSet' never gets set. Though if I run console.dir(customElement); I can see that the property is being set properly from jQuery.

CollinGraf314 · 2019-06-14T15:16:45Z

I made a minimum reproduction here #31055, please check it out if you get the chance.

antch · 2019-06-14T17:46:29Z

FWIW I was able to kind of work around this and #30834 with a custom input decorator and component base class. It's a little verbose but I wasn't able to come up with an easier way (that's AoT compatible):

https://stackblitz.com/edit/angular-elements-test-input-bindings-decorator

This will also fire OnChanges at the proper time for initial bindings.

CollinGraf314 · 2019-06-14T18:05:56Z

wow... I found my bug. I was trying to set the property before Angular finished bootstrapping.

@antch Thank you so much for your help. It was reading your stackblitz code that made me realize my mistake (index.html line 8 to be specific).

robwormald · 2019-07-04T00:09:20Z

@antch thanks for the reproduction and your patience. this should be fixed in #31416

antch · 2019-07-04T00:26:15Z

Thank you very much for the fix @robwormald. Do you know if there's another issue for ngOnChanges not firing prior to ngOnInit?

antch · 2020-03-13T17:59:16Z

@robwormald Sorry to be... persistent... but do you have an update on this? It seemed really close and then no activity for 10 months...

Previously, if an element started out as a regular `HTMLElement` (not a Custom Element) and was later upgraded to a Custom Element, any properties corresponding to component inputs that were set on the element before upgrading it would not be captured correctly and thus not reflected on the instantiated component. This commit fixes it by ensuring that such properties are captured correctly. Fixes angular#30848 Closes angular#31416

Previously, if an element started out as a regular `HTMLElement` (not a Custom Element) and was later upgraded to a Custom Element, any properties corresponding to component inputs that were set on the element before upgrading it would not be captured correctly and thus not reflected on the instantiated component. This commit fixes it by ensuring that such properties are captured correctly. Jira issue: [FW-2006](https://angular-team.atlassian.net/browse/FW-2006) Fixes angular#30848 Closes angular#31416

…ent (#36114) Previously, if an element started out as a regular `HTMLElement` (not a Custom Element) and was later upgraded to a Custom Element, any properties corresponding to component inputs that were set on the element before upgrading it would not be captured correctly and thus not reflected on the instantiated component. This commit fixes it by ensuring that such properties are captured correctly. Jira issue: [FW-2006](https://angular-team.atlassian.net/browse/FW-2006) Fixes #30848 Closes #31416 PR Close #36114

…ent (angular#36114) Previously, if an element started out as a regular `HTMLElement` (not a Custom Element) and was later upgraded to a Custom Element, any properties corresponding to component inputs that were set on the element before upgrading it would not be captured correctly and thus not reflected on the instantiated component. This commit fixes it by ensuring that such properties are captured correctly. Jira issue: [FW-2006](https://angular-team.atlassian.net/browse/FW-2006) Fixes angular#30848 Closes angular#31416 PR Close angular#36114

…ent (#36114) (#37226) Previously, if an element started out as a regular `HTMLElement` (not a Custom Element) and was later upgraded to a Custom Element, any properties corresponding to component inputs that were set on the element before upgrading it would not be captured correctly and thus not reflected on the instantiated component. This commit fixes it by ensuring that such properties are captured correctly. Jira issue: [FW-2006](https://angular-team.atlassian.net/browse/FW-2006) Fixes #30848 Closes #31416 PR Close #36114 PR Close #37226

angular-automatic-lock-bot · 2020-06-20T16:10:21Z

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.}

…ent (angular#36114) Previously, if an element started out as a regular `HTMLElement` (not a Custom Element) and was later upgraded to a Custom Element, any properties corresponding to component inputs that were set on the element before upgrading it would not be captured correctly and thus not reflected on the instantiated component. This commit fixes it by ensuring that such properties are captured correctly. Jira issue: [FW-2006](https://angular-team.atlassian.net/browse/FW-2006) Fixes angular#30848 Closes angular#31416 PR Close angular#36114

mhevery added the area: elements Issues related to Angular Elements label Jun 4, 2019

ngbot bot added this to the needsTriage milestone Jun 4, 2019

robwormald mentioned this issue Jul 4, 2019

fix(elements): handle inputs set before upgrade #31416

Closed

6 tasks

gkalpak mentioned this issue Mar 17, 2020

fix(elements): a couple of small fixes #36114

Closed

antch mentioned this issue Mar 18, 2020

firstChange not set properly in ngOnChanges for pre-bound properties #36130

Closed

kara closed this as completed in 2fc5ae5 May 20, 2020

angular-automatic-lock-bot bot locked and limited conversation to collaborators Jun 20, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Angular Elements doesn't bind existing property values to component inputs #30848

Angular Elements doesn't bind existing property values to component inputs #30848

antch commented Jun 4, 2019

antch commented Jun 5, 2019 •

edited

CollinGraf314 commented Jun 13, 2019

antch commented Jun 13, 2019 •

edited

CollinGraf314 commented Jun 14, 2019

CollinGraf314 commented Jun 14, 2019 •

edited

antch commented Jun 14, 2019 •

edited

CollinGraf314 commented Jun 14, 2019

robwormald commented Jul 4, 2019

antch commented Jul 4, 2019 •

edited

antch commented Mar 13, 2020

angular-automatic-lock-bot bot commented Jun 20, 2020

Angular Elements doesn't bind existing property values to component inputs #30848

Angular Elements doesn't bind existing property values to component inputs #30848

Comments

antch commented Jun 4, 2019

🐞 bug report

Affected Package

Is this a regression?

Description

🔬 Minimal Reproduction

🔥 Exception or Error

🌍 Your Environment

antch commented Jun 5, 2019 • edited

CollinGraf314 commented Jun 13, 2019

antch commented Jun 13, 2019 • edited

CollinGraf314 commented Jun 14, 2019

CollinGraf314 commented Jun 14, 2019 • edited

antch commented Jun 14, 2019 • edited

CollinGraf314 commented Jun 14, 2019

robwormald commented Jul 4, 2019

antch commented Jul 4, 2019 • edited

antch commented Mar 13, 2020

angular-automatic-lock-bot bot commented Jun 20, 2020

antch commented Jun 5, 2019 •

edited

antch commented Jun 13, 2019 •

edited

CollinGraf314 commented Jun 14, 2019 •

edited

antch commented Jun 14, 2019 •

edited

antch commented Jul 4, 2019 •

edited