7 is interesting to me. The lifecycle callbacks are stored at definition time, not accessed dynamically when the lifecycle events occur, despite being implemented on a prototype. In other words, CustomElementRegistry.prototype.define’s constructor argument is doing double-duty: it’s both the element constructor and an (unusually nested) options object.
From my POV, this seems like a ‘dishonest’ API. On the other hand, I think I understand the decision: it permits subclasses of custom elements to delegate to the lifecycle hooks of their super class. I wouldn’t have made the same design choice personally, but it is possible to delete the public-properties-that-are-really-private-config-options immediately after definition — the leak can be entirely closed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
7 is interesting to me. The lifecycle callbacks are stored at definition time, not accessed dynamically when the lifecycle events occur, despite being implemented on a prototype. In other words, CustomElementRegistry.prototype.define’s constructor argument is doing double-duty: it’s both the element constructor and an (unusually nested) options object.
From my POV, this seems like a ‘dishonest’ API. On the other hand, I think I understand the decision: it permits subclasses of custom elements to delegate to the lifecycle hooks of their super class. I wouldn’t have made the same design choice personally, but it is possible to delete the public-properties-that-are-really-private-config-options immediately after definition — the leak can be entirely closed.