Custom Events and Elements with Elemental 2

[nikola]

custom events:

 Do we still need EventBus or what was HandlerManager for widgets to fire and create custom events or we should use element's  addEventListener and native custom events?

custom element:

  I'm missing Composite from GWT Widgets and its initWidget() method. Any idea how we could implement the same behavior with elemental? Elemental's Element is not interface but class so we can't delegate inner element or something...

Thanks,

Nikola

[Harald Pehl]

We still use the GWT event bus for custom / application scoped events. To listen to DOM event we use what's provided by Elemental2. 

We use a simple interface [1] which is part or Elemento [2] to create custom elements.

[1] https://github.com/hal/elemento/blob/develop/core/src/main/java/org/jboss/gwt/elemento/core/IsElement.java

[2] https://github.com/hal/elemento/#custom-elements

HTH

Harald

[nikola]

  Users would expect to have events with source from where event was fired. That was source field in GWT events. In your implementation we will need to intercept DOM event and fire new event with source field of custom element. (e.g re-fire through EventHandler). This is kind of double work. 

  Another thing that we need to care about is if add and then remove some custom element from DOM like element.removeChild(customElement.asElement()) we also need to remove reference to custom element to be garbage collected? Since only asElement() is removed from DOM not custom element object itself. If I'm right...

  This is why it would be good if custom element can extends Element and wrap inner element like Widget Composite. 

Btw: Great work there with Elemento especially HTML Templates

[Thomas Broyer]

On Wednesday, October 11, 2017 at 4:12:14 PM UTC+2, nikola wrote:

  Users would expect to have events with source from where event was fired. That was source field in GWT events. In your implementation we will need to intercept DOM event and fire new event with source field of custom element. (e.g re-fire through EventHandler). This is kind of double work. 

  Another thing that we need to care about is if add and then remove some custom element from DOM like element.removeChild(customElement.asElement()) we also need to remove reference to custom element to be garbage collected? Since only asElement() is removed from DOM not custom element object itself. If I'm right...

  This is why it would be good if custom element can extends Element and wrap inner element like Widget Composite.

I'm really not clear about what you want to do, and what you actually mean by "custom element".

Do you mean Web Components? In this case, they'd have to extend HTMLElement and, at least with elemental2-dom 1.0.0-beta-1, set the connectedCallback, attachedCalback, etc. Encapsulation is then provided by the shadow DOM.

Or do you mean "kind of widgets, that just happen to map one-to-one with a DOM element and its subtree"? In this case, you're indeed *wrapping* an element, and that means you're going to have parallel hierarchies or such widgets/components on one hand, and DOM elements on the other hand, and will need to maintain both in sync (this is what GWT Widgets do, and I believe more or less how React works too).

[nikola]

When I say "custom element" I mean:

public class CustomElement implements IsElement {

//    private HandlerManager handlerManager; ?

    List<String> someUserObject; //state object of CustomElement

    HTMLElement root = Js.cast(DomGlobal.document.createElement("div"));

    @Override
    public HTMLElement asElement() {
        return root;
    }

    public static void test() {
        CustomElement customElement = new CustomElement();
        customElement.asElement().addEventListener("click", evt -> {

             //evt.target is not CustomElement so we can't access e.g someUserObject 

           //We can map DOM events to custom events fired through HandlerManager with source field set to CustomElement (double work.. )
        });
    }
    //
}

Also when working with custom elements constructed as above we need some discipline to remove objects both logically and from DOM (as you said we need to keep them in sync).. 

We are coming to something that looks like a Panel

class Panel implements IsElement {

    List<IsElement> componentList;

    HTMLElement root;

    @Override
    public HTMLElement asElement() {
        return root;
    }

    public void add(IsElement component) {
        // add to componentList
        // add to DOM
    }

    public void remove(IsElement component) {
        //remove from componentList
        //remove from DOM
    }
}

So it would be good to have something like this :

public abstract class CustomElementComposite extends HTMLElement implements IsElement {

    List<String> someUserObject;

    protected void initComposite(HTMLElement element) {
        //If we could encapsulate element to become actually CustomElementComposite like Widget Composite
    }

    @Override
    public HTMLElement asElement() {
        return this;
    }

    public static void test() {
        CustomElementComposite element = new CustomElementComposite() {};

        element.addEventListener("click", evt -> {
            // evt.target  is CustomElementComposite
        });

        // we don't need any additional mapping for adding and removing
        HTMLElement parent = Js.cast(DomGlobal.document.createElement("div"));
        parent.appendChild(element);
        parent.removeChild(element);
    }
}

This way we are adding events directly and there is no additional synchronization with DOM when adding and removing components.

I must inspect but I'm not sure if Web Component can solve this (in the way widget's composite did).. I'd rather have web component as a option.

[Thomas Broyer]

This is not how the DOM works I'm afraid. How would your proposed code would translate to JS? (feel free to use ES2015 classes for clarity)

(btw, I really do think Web Components would solve your issues, as I see them)

[nikola]

Ok, Thanks! I'll try with web components. As a java programer I'v been trying to avoid digging too much in javascript but it's inevitable it seems :)

[harshyadav]

You can try the GWT polymer (web components) wrapper:
https://github.com/manolo/gwt-polymer-elements

Wither you can use built-in polymer components; or create your own (just look at the source code)

Also take a look at:

https://github.com/manolo/gwt-api-generator

which auto generates GWT api for polymer elements, so no need to be out of Java world for most cases.

[nikola]

Thanks for the link.. But I can't see what I was looking for.. 

 Can someone please create and register custom web component using only elemental 2. e.g  that says "hello from shadow DOM!".

Cause I'm not able to do it or find working example .. at least without losing whole week on it...
Thanks in advance

[Thomas Broyer]

Web Components require using ES2015 class syntax, so you would need some trickery make them work from GWT (see https://github.com/webcomponents/custom-elements#es5-vs-es2015 or https://github.com/webcomponents/webcomponentsjs#custom-elements-es5-adapterjs)

At least this is the theory…

[James Nelson]

It is possible to create web components with "fake" ES2015 classes built out of raw javascript.

https://github.com/WeTheInternet/xapi/blob/master/gwt/components/src/main/java/xapi/components/impl/WebComponentBuilder.java#L108

Note that the library above depends on a custom fork of Gwt that is not being released until after 2.8.2 goes out, however, the code for assembling custom web components does not actually depend on any of the magic I've added to the Gwt compiler (official release will not be dependent on my fork; I hope to deprecate / upstream everything I've had to do to it over the years). 

I also intend to remove all the ugly jsni to make it compatible with j2cl / gwt3... But, that bit I've linked to is the secret sauce for assembling a correct "extension" of HTMLElement.  In theory, you can define your custom element using a builder that attaches your lifecycle callbacks (created / attached / detached / attributeChanged), plus any extra methods / fields you want, and then the rest of your code can use a @JsType(isNative=true, name="MyCustomElement", namespace = JsPackage.GLOBAL) interface that defines how you want to access the custom element and/or cast directly to an Element.  This work is very imperative and copy-pasta, so I've also created a nice DSL for defining custom elements using... an xml-like, json-like, css-like extension of the java language (totally optional though; you can still use the builder directly).

The end goal (very near to completion) is that you can define your custom component with a bit of xml-like syntax, plugging in java methods wherever you please, and it will generate all the builder-y boilerplate and Element interface for you.  It is likely that I can actually make it extend HTMLElement directly as a class, and just define trampoline methods in the builder to call into the java code, but I have not had time to explore this option yet.

I have not "officially" released this library, but it will be making an official debut soon.  You should be able to use it earlier, if you are interested in some beta testing :-) (message me @ ja...@vertispan.com so I can add you to my beta testers label).

The result is a custom element that has widget-like lifecycle callbacks (we are toying with the idea of actually making widget use something like this under the hood to survive in Gwt 3).  The one big gotcha is how the createdCallback works.  Per the web component spec, you may not write or read any elements attributes or children to a custom element in its constructor.  I have worked up a...  slightly scary "RunSoon" implementation which will ensure that the callback is fired as soon as possible after construction (but this can be hard, since setting innerHTML from plain javascript is an important part of interopability with JS/HTML).  I won't go into many details here, but, in practice, this ugliness can be hidden behind some cleverly generated code (which will lazy-init either at your command, whenever attached, or at the end of the current javascript event loop).

The very first iteration of these custom components actually took a js type interface, directly bound all default methods to the custom element definition (via code generator), and allowed you to use that interface in both java and javascript.  It actually worked quite well, but, unfortunately, that was for V0 of web component spec, and the ES2015 class syntax requirement (and other, imho, design mistakes) made it untenable for V1 (current version of web components).



To use web components with GWT, you do have to install a polyfill (webcomponentjs, with only a couple slight mods I had to make) for older browsers / browsers that do not have web components enabled by default.  The fact GWT runs in an iframe makes instanceof fail spectacularly, so I had to change usage of it to typeofs.

Shameless plug: Myself, Colin Alworth and Justin Hickman have started a company based on selling GWT support contracts called Vertispan.  While I am happy to share open source code and some pointers with you for free at any time, if you are interested in hiring any expertise to help you directly, you should email my aforementioned work account. :-)


Final note: Shadow DOM is completely optional, and you should likely avoid it unless you really need it (for encapsulation and css barriers mostly).  It... gets a bit hinky especially with polyfills and sane event bubbling, so if you are new to web components, only move on to shadow DOM if you've tried something without it, and actually need it (for example, to isolate component internals, or to avoid re-rendering piles of layout logic when all you want is your server to send elements with semantic significance).  

[James Nelson]

Also, feel free to ignore the bit of insanity around virtual shadow roots.  That's just something I built because an older version of webcomponentjs was severely borked, and I needed to...  make my own virtual shadow DOM implementation.  I have allowed it to survive after upstream bug was fixed because I also added V0-like behavior for slotting elements in shadow DOM that was (wrongly, imho) replaced in V1 spec with ugly manual slotting.

To make a long story short, in V0, you can do this (note, #shadow-root is not a real tag name, it's just there to say there is a shadow root with elements in it):

<my-element>
  <#shadow-root>
    <content select="div.cls" />
  </#shadow-root>
  <div class="cls"> I am rendered in shadow root because I match selector</div>
  <div>I am not rendered because I do not match selector</div>
</my-element>

In V1, you have to do this:

<my-element>
  <#shadow-root>
    <slot name="myslot" />
  </#shadow-root>
  <div slot="myslot"> I am rendered in shadow root because my slot attribute matches slot name</div>
  <div slot="notfound">I am not rendered because I do not match slot</div>

  <div>I am also not rendered</div>
</my-element>


In both cases, a content without a select attribute and a slot without a name will render all unslotted elements, but even that gets... hairy with the polyfill, when you are nesting components inside each other.

Anyway, once again: I would strongly recommend avoiding all use of shadow root unless you really enjoy debugging bleeding edge bugs. :D