-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Composable lifecycle hooks #10304
Comments
I'm curious about this statement. What's the baggage? What if, for example, |
I’m not actually sure, but my understanding was that the web platform got a bunch of Observer objects for certain things (MutationObserver, IntersectionObserver, ResizeObserver, etc) because using events for it would have been too slow. If events are acceptable, that is obviously a better solution. Though whatever API is chosen should work with native elements too. Would it be possible to get access to their |
|
EventListener callback itself isn't really any different to other callbacks. The reason for MutationObserver (which is the first *Observer) design is that we wanted to optimize out dispatching tons of events all the time, like what happens with Mutation Events. And since MutationObserver didn't really have any need for being an EventTarget (since it handles only one types of 'events'/'notifications') it was enough to give it a callback. |
This comment was marked as spam.
This comment was marked as spam.
I don't understand what this means. Is this about multiple inheritance? Like class WebComponentA extends HTMLElement {
connectedCallback() {
console.log('A');
}
class WebComponentB extends WebComponentA {
connectedCallback() {
super.connectedCallback();
console.log('B');
} |
@NickGard Multiple inheritance is orthogonal, but would also require this problem to be solved. Here’s an example of using helpers to add element behaviors: ElementClass.js: import { defineProps, makeFormAssociated } from "util.js";
class ElementClass extends HTMLElement {
// stuff, including doing stuff when element is connected
}
defineProps(ElementClass);
makeFormAssociated(ElementClass); util.js: function defineProps (ElementClass) {
// Do stuff when ElementClass instance is connected, among other things
}
function makeFormAssociated (ElementClass) {
// Do stuff when ElementClass instance is connected, among other things
} |
Lit has a reactive controller pattern which I think could work well, if something like class MyElement extends LitElement {
#mouse = new MouseController(this);
}
class MyElement extends HTMLElement {
#internals = this.attachInternals();
#mouse = new MouseController(this.#internals);
} |
Background
Currently web component lifecycle hooks exist as instance functions with special names like
connectedCallback()
,attributeChangedCallback()
,disconnectedCallback()
and so on.This means that composing multiple listeners from different sources has a very poor DX. You basically have to wrap the existing
connectedCallback()
with a new one that calls it. Remember how event handling was beforeaddEventListener()
/attachEvent()
? Yes, that. And good luck undoing this operation.Why would you need to do that?
Proposed solution
You basically need a lightweight pub/sub mechanism that doesn't carry the baggage of events, but allows independently adding and removing callbacks and passing arguments to them (for
attributeChangedCallback()
).As a strawman just to start the conversation, it could look similar to
addEventListener()
(addLifecycleListener
?) withtype
beingconnected
,disconnected
,adopted
,attribute
.This can co-exist with the current lifecycle hooks, as long as the order of execution is well defined (presumably the current lifecycle hooks would be executed first).
The text was updated successfully, but these errors were encountered: