Allow late upgrading of bound elements

[kevinpschaaf]

Currently elements that are bound (i.e. have data pushed to them by their host) must be upgraded prior to data propagation. This is because the act of upgrading installs accessors on the element via its prototype, which may be shadowed by data values propagated to the instance earlier by the host.

This is typically not an issue when an element imports all of its dependencies before registering, which guarantees that when a host stamps its template, the children upgrade prior to the host pushing its data.

However, to support lazy upgrade use cases, elements would need to support reading instance values for properties with accessors, deleting the instance values, and passing them into the initial configuration / setters. This should likely be an option via an attribute (e.g. late-bind) so that all instances aren't taxed with this extra processing.

[ebidel]

+1. In 🎅's lazy loading system, we had to use getAttribute() to poke at values before elements were upgraded and bound.

[samccone]

👍 oh this would be magical ✨

[robdodson]

yeah very much want this!

[tpluscode]

👍

[srikkbhat]

+1.

Couple of observations. Reference plunker: http://plnkr.co/edit/4WEsWabS3nNSacyimwst

1. The boolean property is pushed to lazy element - show-boolean.
2. The value initialization of the property in lazy element is ignored - my-element-two.shared-value. This looks odd.

Update: After spending two more days on this, I found that the properties were updating from parent to lazy loaded element. However the local dom and child elements of the lazy loaded element were not getting the updated properties. I was able to resolve this by adding this.notifyPath to all the values pushed from parent to lazy loaded element in the attached callback of the lazy loaded element.

[TimvdLippe]

When using async HTML imports I encountered this issue too. I have tried to dig into the code to develop a solution, but sadly it is not clear enough where the issue is and how it can be solved.

[kevinpschaaf]

Essentially a dupe of #2348, which has been addressed in #3417.