Custom elements should not upgrade elements by setting prototype (bugzilla: 28544)

[hayatoito]

Title: Custom elements should not upgrade elements by setting prototype (bugzilla: 28544)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544#c0
Ryosuke Niwa wrote on 2015-04-22 23:45:08 +0000.

Discussed here:
https://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0158.html
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0083.html

We shouldn't support upgrading of existing elements since it leaves the corresponding DOM objects with a wrong identity.

This is also not a normal programming model. Even with ES6 modules, we don't create a dummy modules while modules are loading and later automatically replace them under the foot.

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544#c1
Domenic Denicola wrote on 2015-04-22 23:52:35 +0000.

Even with ES6 modules, we don't create a dummy modules while modules are loading and later automatically replace them under the foot.

This is exactly what we do with ES6 modules.

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544#c2
Ryosuke Niwa wrote on 2015-04-22 23:57:31 +0000.

(In reply to Domenic Denicola from comment #1)

Even with ES6 modules, we don't create a dummy modules while modules are loading and later automatically replace them under the foot.

This is exactly what we do with ES6 modules.

How? import { myClass } from 'mymodule'; doesn't create a promise or anything. It'll just block until mymodule is loaded.

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544#c3
Domenic Denicola wrote on 2015-04-22 23:58:58 +0000.

Referencing myClass will be a reference error until 'mymodule' is loaded. This normally comes up in the case of circular dependencies.

---

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544#c4
Ryosuke Niwa wrote on 2015-04-23 00:35:18 +0000.

(In reply to Domenic Denicola from comment #3)

Referencing myClass will be a reference error until 'mymodule' is loaded.
This normally comes up in the case of circular dependencies.

I'm not certain what you mean by "until 'mymodule' is loaded' but the 'mymodule' will be synchronously fetched and evaluated before the following statements are executed.

e.g.
import { myClass } from 'mymodule'; // (1)
new myClass; // this line of code is never executed until (1) is done executing.

The fact we can encounter a circular dependency in (1) is an orthogonal issue. The fact of matter is that the declarative syntax for importing an ES6 module DOES synchronously block the script execution.

---

comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544#c5
Domenic Denicola wrote on 2015-04-23 01:23:23 +0000.

It is correct that (2) will not execute until (1) is done executing. But (1) simply creates a dummy myClass binding which will cause ReferenceErrors if executed before myClass's definition is evaluated. myClass's definition may or may not be evaluated by executing (1).

Here is a simple example:

// a.js
import * as bModule from './b.js';
import { b } from './b.js';

// bModule is a dummy module with no properties
// if b is referenced it will cause a ReferenceError
// console.log(b); // fails

export let a = 1;

setTimeout(() => {
// bModule is no longer a dummy module and has a b property
// b can be referenced without errors
console.log(b); // works
}, 100);

////////

// b.js
import * as aModule from './a.js';
import { a } from './a.js';

export let b = 2;

////////

// entry.js
import './b.js';

Execution order is entry.js -> a.js -> b.js. Thus inside a.js we have the dummy module which later gets upgraded. In fact this happens for a.js (and entry.js) as well, but you don't observe that since you can't see them pre-upgrade.

---

comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544#c6
Ryosuke Niwa wrote on 2015-04-23 02:09:24 +0000.

Again, even in this example, files are fetched and evaluated synchronously.

But let us not derail this bug from the main topic, which is about not upgrading custom elements. Even if my statement about class wasn't accurate, the fact that upgrading existing elements is a bad idea wouldn't change.

---

comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544#c7
Domenic Denicola wrote on 2015-04-23 02:11:11 +0000.

I think it's very relevant. In a dynamic system with interdependencies, upgrading of some sort is important. We have it for ES6 modules, and it makes just as much sense for custom elements, for the same reasons.

---

comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544#c8
Ryosuke Niwa wrote on 2015-04-23 02:42:25 +0000.

(In reply to Domenic Denicola from comment #7)

I think it's very relevant. In a dynamic system with interdependencies,
upgrading of some sort is important. We have it for ES6 modules, and it
makes just as much sense for custom elements, for the same reasons.

Why?