These are chat archives for ractivejs/ractive

22nd
Oct 2018
Chris Reeves
@evs-chris
Oct 22 2018 16:25
I'd say the best way to ship content would be in template form or by attaching a child
I don't see anything wrong with your approach though
Tom Randolph
@rockerest_gitlab
Oct 22 2018 17:14

Hi there!

I've been using native Web Components a lot more, and I've been using events for data "out".

See item 3: https://w3ctag.github.io/webcomponents-design-guidelines/#native-html-elements

This works great, since it uses web-standard events for communication.
However, at the binding point between these components and Ractive, none of the events are catchable.

I'm required to go in and add every possible Web Component event to the Ractive .events global registry.

Is there any way to have Ractive listen for any event coming from a DOM node?
I know that probably has tons of bad edge cases, but are there any ideas around this?

Chris Reeves
@evs-chris
Oct 22 2018 17:19
is there a standard way to detect supported events on a webcomponent?
for instance for a foo event, is there an onfoo property that can be used to attach a listener that would also signal it as a supported event?
Tom Randolph
@rockerest_gitlab
Oct 22 2018 17:47

I don't believe so, but I'm not deeply experienced with this.

The only way I know of is binding via addEventListener( "foo" ...)

I was thinking more like: if Ractive sees on-* and it's not a "standard" event (e.g. onclick) then it assigns the handler via addEventListener( "foo" ...) and handles the detachment when unrendering etc.
Tom Randolph
@rockerest_gitlab
Oct 22 2018 18:08
To be clear, I know nothing about the mechanisms that Ractive currently uses to do this event binding, so if what I'm asking is totally bonkers, I'm happy to hear that.
Chris Reeves
@evs-chris
Oct 22 2018 19:30
do you have control over the custom elements?
I haven't really looked hard at custom elements yet, but it looks like we could check to see if the element is a custom element, and if it is, go ahead and attach an event listener
it doesn't look like there's any standard way to detect what events a custom element will fire
and the onwhatever properties that we use currently are more or less legacy
convenient for knowing what events are supported and for doing one-off things, but not a whole lot else
Tom Randolph
@rockerest_gitlab
Oct 22 2018 19:34
I do personally have control over the custom elements, but of course I'm going to be more bullish on a solution for even projects that don't.
Chris Reeves
@evs-chris
Oct 22 2018 19:34
the quick and dirty immediate solution then, would be to add onwhatever properties to your custom element instances
Tom Randolph
@rockerest_gitlab
Oct 22 2018 19:35
Oh interesting, so Ractive's behavior is basically to convert on-* to a function passed to on*? That's very interesting.
Chris Reeves
@evs-chris
Oct 22 2018 19:36
as long as 'onwhatever' in element returns true, ractive considers it a valid dom event and will attach a listener
Tom Randolph
@rockerest_gitlab
Oct 22 2018 19:36
^ NEAT
Chris Reeves
@evs-chris
Oct 22 2018 19:36
not quite, but yes, on-* get converted into a plain old addEventListener call for dom events
I think the long term solution is probably to detect custom elements and say anything goes for those
Tom Randolph
@rockerest_gitlab
Oct 22 2018 19:40

I had thought detecting CustomElements would be easy, but it's probably more complicated than I thought.

Of course you can get the node name from the node itself, and there's customElements.get() and customElements.whenDefined() but I suspect those would get pretty hairy.

Chris Reeves
@evs-chris
Oct 22 2018 19:45
it looks like we could probably do an internal ponyfill for customElements.get() to check for custom elements
I was hoping something simple like element._shadowRoot would be available as an obvious flag
but doesn't look like it is
hmmm
maybe I was looking at old api and there is element.shadowRoot
Tom Randolph
@rockerest_gitlab
Oct 22 2018 19:54
Might have to be cautious with that since - technically - an element doesn't have to define a shadow root. It's probably beneficial for 99.9% of custom elements, but in theory you could have a my-wrapper element that has no visual representation.
(i.e., no shadowRoot)
Chris Reeves
@evs-chris
Oct 22 2018 19:55
so if you don't call attachShadow, shadowRoot is null?
Tom Randolph
@rockerest_gitlab
Oct 22 2018 19:55
To be honest I don't know what the use-case for an element like that would be, but I'm sure it might exist in the wild
Chris Reeves
@evs-chris
Oct 22 2018 19:56
I was hoping that shadowRoot would simply not be part of the prototype for non-custom elements, but that doesn't appear to be the case
Tom Randolph
@rockerest_gitlab
Oct 22 2018 19:56
Uh, I'm not even aware there's a "standard" shadowRoot property, let me do a little digging
Chris Reeves
@evs-chris
Oct 22 2018 19:56
I do see that closed mode shadow roots are discouraged
I'm going off of a google search for custom elements :smile:
Tom Randolph
@rockerest_gitlab
Oct 22 2018 19:57
Yeah you're right, I wasn't even aware of that as the standard "holding area": https://developer.mozilla.org/en-US/docs/Web/API/Element/shadowRoot
Chris Reeves
@evs-chris
Oct 22 2018 19:57
I've still not looked at them hard because they were moving too fast last time I looked
Tom Randolph
@rockerest_gitlab
Oct 22 2018 19:57
But yes, even elements with a closed-mode shadowRoot would return null there
Chris Reeves
@evs-chris
Oct 22 2018 20:08
looking at it a bit more, there may no longer be any reason to skip adding event listeners even if the events are invalid
we don't warn any more because decorators can now raise events
I think the code may have originally been a legacy ie thing, but since ie 8 is no longer supported, it probably doesn't matter
Tom Randolph
@rockerest_gitlab
Oct 22 2018 20:12
Ah. I'm totally inexperienced with decorators, so I can't speak to it. But it sounds like a good path forward. Especially if it means moving farther from IE8 ;D
Tom Randolph
@rockerest_gitlab
Oct 22 2018 21:21

I don't think this actually changes anything, but may lend some more weight to just removing the "skip adding event listeners" logic...

In the Custom Elements specification, there's a provision for "Customized built-in elements."

That is, you can define custom logic (including events) on built-in elements, like:

<button is="my-custom-button-behavior-component">Magic Button</button>

This would upgrade this standard <button> element with any custom logic, so it then opens up the entire DOM library of standard elements to emitting arbitrary events and exposing arbitrary properties and methods.

https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-customized-builtin-example