Re: [WICG/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

> Passing it in via constructor does mean users have to assign it to their own (possibly #private) property to use it in other methods.

My concern is about trapping the argument/leaking it, while a read-only property that returns `null` once the behavior is detached looks less error prone.

> or provide a base Behavior class

I think a base class to extend is more elegant and future proof (in case we want to add behavior features, all extenders will benefit).

> That can't happen. If an element is disconnected already, connectedCallback will not be called.

The MO schedules records, so the sequence of events will be guaranteed, but being asynchronous, if you quick append and remove an element before the MO callback triggers, you have a `connectedCallback` event while the element is actually disconnected.

Nothing we can do though, let's not focus much on this, but it'll be a caveat of the polyfill.

> That's also an interesting approach.

Yeah, I've realized I can simulate most of this via `define('[has~="behavior"]', {...})` too in wickedElements.

> I thought about that, but there's no already-existing built-in behaviors, so they aren't really "custom".

Fair enough.

> So even after being disconnected from DOM, this.element could still reference the owner element.

Not in my implementation. `this.target` is null, once the behavior is detached, and the behavior virtually dead.

> Would this be better?

It's veeeeeeery verbose ... let's think about it.

> I haven't relied on it running after a behavior is cleaned up (disconnected), so I don't even know if it does or not currently.

My implementation drops the MO once detached, nothing works anymore, behavior dead.

> It just creates a new one currently.

Cool, I like that.

> But perhaps that should be read-only, and perhaps the only way to add/remove them imperatively would be something like ...

Yeah, I think leaking behaviors around is not great indeed.

> Another idea regarding this.target is ...

My implementation sets it as getter and uses a WeakMap pre-populated per behavior <-> node. It works out of the box in constructor too.

> I think most of the time I would just want to initialize things, it will run for a while, then finally cleanup.

For behaviors: yes, which is why connected/disconnected are not a good place to do so.

> Wondering what are some compelling use cases for it.

DOM diffing. You have a list of things and you filter things as you type, as example, and nodes get off/on all the time, without changing state, except their presence on the document.

Doing listeners dance, or any other, due diffing, looks like extremely undesired overhead.

Behaviors are per element, not per element lifecycle, so coupling these strictly with element lifecycle might easily backfire, imho.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/509#issuecomment-805624075