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

@Leedehai Thank you :) 

>  is better to be addressed by the JS bundlers via polyfills, not by the standards

However, the polyfill is not able to cover all the nifty details. We've managed to solve a lot of issues but there is still one, which we can't address:

If a custom elements class definition is mutated at runtime, the (JS) developer expects the instances to mutate as well, reflecting the change. Just like JS object instances change, when you change its `prototype`. However, when this happens with the polyfill, the developer has to choose from a list of "refresh" strategies atm. One of the major tradeoffs here is, that it is incredibly hard to correctly re-create the state of the component as it was before. 

For example:
- We've detected a re-definition of `FooBar`
- So every <foo-bar> needs to be replaced in DOM
- So we create new instances. There was an attribute on one of them called "w3c" and it was set to "cool". So we call setAttribute("w3c", "cool") and got every possible state loss issue covered. Do we?
- No. Because there is JS state as well. And you can have arbitrary property changes in your custom element class. This means, that the DOM it generates might belong to some class member properties that might be hidden from the outside.
- This is a box of pandora, because we have no easy solution where we could say: This and that property is a "state" that has to be re-created as is.

So, the standard doesn't define this as of now and the effect is, that we can't completely solve the issue with a polyfill. Even if I would loop thru a list of attributes defined by the HTML standard, so I would find custom added properties on instance level before the clone... I could still run into issues here when closure functions are involved. I really cannot solve all cases safely and it has a huge impact on performance as well (all these loops on a per instance level). After all these findings, I went back to a page refresh. And later, I switched my frameworks implementation not to use web components anymore. I use an approach on components now which is much like React in theory, but it's more efficient. For style encapsulation I use CSS modules now and I'm working on a bundler that does does the magic necessary here at compile-time. 

On the other hand, it would be nice if I could have sticked to web components. But there are so many  limitations and I need so many polyfills :/  Well, and the "custom element" / component issue has been solved in user-land already for years. So if we look, for example, in direction of react... there is a defined "state" and because of this they know, in any event of a on class definition mutation, what is a state to clone and to re-apply and what isn't. I do the same in SpringType, but allow class properties to be decorated with `@state` to allow more than one property to be known as a state and get around the deep-tree state mess.



-- 
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-550251976