Here, the presence of an attribute signals behavior. With element-behaviors, has= attribute is used to say what behavior classes to apply. Different paths but doesn't seem super dissimilar end result. I feel like web-directive giving a simple callback leaves a lot to the developer, where-as element-behaviors API surface tries to parallel WebComponents, which is familiar & has lots of nice understandable lifecycle builtin.
This looks kinda neat - I’m not really sure I have a good sense of what I would use this for though.
If I’m working in vanilla js, I don’t really have any issues when using element selectors - deferred or otherwise.
If I’m working in an app framework, then that framework already provides this functionality - for instance Lit lets you bind event listeners to elements as defined in your templates @event-name=${this.onEventName}
I guess - is the aim with this, that it’s useful for if you’re working outside the context of a specific site or project, and aiming to write code for an npm package or similar, where you need something portable and framework-independent? I suppose I could see reaching for it in that case.
Similar but different, I really dig the nice spatial/3d webcomponent https://Lume.io 's ECS / behavior system. Standalone library, works for anything. https://github.com/lume/element-behaviors
Here, the presence of an attribute signals behavior. With element-behaviors, has= attribute is used to say what behavior classes to apply. Different paths but doesn't seem super dissimilar end result. I feel like web-directive giving a simple callback leaves a lot to the developer, where-as element-behaviors API surface tries to parallel WebComponents, which is familiar & has lots of nice understandable lifecycle builtin.
This looks kinda neat - I’m not really sure I have a good sense of what I would use this for though.
If I’m working in vanilla js, I don’t really have any issues when using element selectors - deferred or otherwise.
If I’m working in an app framework, then that framework already provides this functionality - for instance Lit lets you bind event listeners to elements as defined in your templates @event-name=${this.onEventName}
I guess - is the aim with this, that it’s useful for if you’re working outside the context of a specific site or project, and aiming to write code for an npm package or similar, where you need something portable and framework-independent? I suppose I could see reaching for it in that case.