Re: [w3c/webcomponents] Custom Element - untrackable upgrade (#671)

*It's kind of too late but this is one of the reasons we were opposed to adding upgrades and only wanted synchronous definitions of custom elements in the first place. This exact conversation came up during the internals discussions we had at Apple, and we came up with many convoluted solutions and we disliked them all.*

> Would it be possible to add something to upgrading like:
>  1. Remove and store all own properties on the element
>  2. Perform existing upgrade
>  3. Re-set the properties from (1)
>
> If that's too drastic, could there be a static property similar to `observedAttributes` that opts into the properties that need to be removed and re-set? CE base-classes/frameworks could implement a getter that returns the properties that it generates accessors for, or use the property to know what accessors to generate.

Alright before deciding whether we like this idea or not, I have a couple of questions to ask.

In step 1, what happens when that property is configurable? Or if `Object.freeze` had been called on the element instance?

In step 3, are we using the abstract operation [OrdinarySet](https://www.ecma-international.org/ecma-262/7.0/#sec-ordinaryset)? That abstraction operation has a bunch of side effect like it can create a new own property, etc... Or are we extracting step 3 of that abstraction where we walk up the prototype chain and call [`Set`](https://www.ecma-international.org/ecma-262/7.0/#sec-ordinary-object-internal-methods-and-internal-slots-set-p-v-receiver)?

Also, what happens if the author defined an own property which has the same name as some setter on `HTMLElement` and its prototype chain hierarchy? Since author could add a new property on any prototype object, these properties may end up walking up prototype chain but since any such a walk can be intercepted by a proxy and overridden, this whole process can get quite complicated.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/671#issuecomment-335360210

Received on Tuesday, 10 October 2017 04:51:36 UTC