Re: [w3c/webcomponents] JavaScript bundlers, HMR and customElements.define() (#829)

> If one deletes the callback hooks from the public interface, it can be guaranteed that any invocation of them is legitimate (e.g. connectedCallback is known to only be invoked when the element connects).

I do imagine that with a redefinition feature, the engine could very well drop the references to the old hooks, and store the new ones, thus it can maintain that privacy that you want. (Maybe it'd be better to have some way to expose `#private` fields to the engine?)

> elements generally have expectations about what those elements will be. Currently those can be relied on

That's true. Well obviously programs are going to outright break if people randomly change the types of the elements that are defined. I don't think people will have success doing that anyways. It'll just be something that everyone knows not to do. It'll be like with a type system (f.e. TypeScript): you can swap out an item for another one that can be assigned to the same base type.

> introduced safely if they were opt-in via the second argument.

That's a good idea. In production mode the application could not pass it in, to lock things in place. If someone wants to abuse it, and totally change the types of elements, I think they'll get what's coming to them. It won't be long before they realize they simply shouldn't do that. And having TypeScript in place can trigger type errors once the ambient element type definitions are mapped.

> The concept of downgrading isn’t sound. State exists in association with objects by identity, whether as keys in weak or strong collections, as private fields, as own properties, as internal slots of platform objects, or just as bindings within closures

I'm imagining that it would be fine, because on downgrade the _referenced object (element) remains the same_.

After downgrade, the element will still be the same referenced object in a WeakMap key, the same object at some position in an array, etc. It doesn't matter where the reference is, it'd be the same reference, and all those places would continue to rely on that same reference.

It's similar to currently: we can get references to non-upgraded elements, manipulate them before ever calling `customElements.define`, and in the future we once they are defined we can use the upgraded behavior of the same referenced elements, grab those same elements from any Maps, Arrays, etc. It's the same concept that already exists, just happening more than once.

-- 
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/829#issuecomment-560010744