Provide a way to keep existing markup as is (Custom Elements, Hydration)

[naltatis]

I'm looking for a way to make hyperapp respect existing markup thats inside the app and leave it untouched. My problem is quite similar to the issues @frenzzy and @gyopiazza already have pointed out (#741, #688).

Parts of my application are made up of sub-applications provided through Custom Elements. Due to browser support be can not rely on ShadowDOM, so these Custom Elements use the Light DOM to render their UI. Hyperapp is overwriting their content in every render cycle. I've tried the hydration workaround. But this is not really a solution. You are able to restore the markup, but the innerHTML gets completely rewritten so you loose all events.

I've compiled a little JSBin the shows one concrete scenario I'm having problems with:
https://jsbin.com/dogujuq/4/edit?html,js,output

Using react I was able to make this work using shouldComponentUpdate. But I currently don't see any solution how to make this happen in hyperapp.

[jorgebucaran]

@naltatis What about using Hyperapp to create your custom element instead of setting innerHTML. I did something similar with Superfine the other day when I was toying with custom elements.

[naltatis]

@jorgebucaran We use custom elements as an abstraction between teams, so could be, that a team also uses hyperapp to build their feature, but when composing features through hyperapp I can't make any assumptions about the inner workings of the sub applications.

[frenzzy]

Looks like Hyperapp does not support Custom Elements hydration/recycling.
I think this case is different from innerHTML attribute recycling and probably simpler to implement.

Instead of adding a special shouldComponentUpdate property to VNode, Hyperapp may detect custom element and always do nothing with child nodes in this case.

But I'm not sure is there a way to detect custom elements other than searching for hyphen (-) in the element name. I'm afraid that a simple check if (nodeName.indexOf('-') !== -1) may slowdown rendering.

[zaceno]

@frenzzy I don't think skipping over children of custom elements is the right approach here. You want to be able to compose the with children just like any other html node. (We want to score well on custom elements everywhere eventually)

For example you might want to do:

...
<custom-modal titleBarText="blah">
  <Foo state={state.foo}
  <p>{state.bar}</p>
</custom-modal>

I haven't really dug into the issue yet, but isn't part of the problem here that the OP isn't using Shadow DOM? If they were, I don't think this would be an issue. So maybe this isn't so much a bug as a question of browser support?

[zaceno]

@naltatis I'm not entirely sure why, but I figured out that this works:

  connectedCallback() {
    setTimeout(_ => {
      console.log("example-alert connected - rendering a button");
      this.innerHTML = "<button>alert()</button>";
      this.querySelector("button").addEventListener("click", () => alert("foo"));
    }, 0)
  }

[naltatis]

Yes using nativ ShadowDOM would solve my issue here, but when you have to support more than the latest browsers this is not an option. You have to use the normal DOM in this case.

As @zaceno pointed out correctly, it’s also not right to generally ignore the children of custom elements. Using ShadowDOM and Slots you need this ability to compose things.

I’m thinking of an opt in way to tell Hyperapp to skip/ignore the sub tree of a specific node. Maybe as a result of a lifecycle method.

[naltatis]

@zaceno yes the setTimeout would work, but since I don’t control the code inside the custom element this is not an option. I explicitly chose that order of execution to highlight the issue. See the code comment in the first line ;)

[zaceno]

@naltatis Ah ok.

You can tell hyperapp to skip the subtree of a specific node if you return the exact same instance of the virtual node, as the previous render -- i e if you memoize the h('custom-element') call.

That only works in the case you're patching though -- not the first render, with hydration, which is what your example is about.

[zaceno]

I'm still not exactly sure what's going on. But I verified that this is only a problem when "hydrating" -- ie when the pre-rendered markup already contains the <example-alert> custom element. If the original markup is clean, the custom element works as intended, and keeps working through continued updates/patching (even without memoization)

Not to say that it's not a problem, but just to point out that if there is a fix for this, it's somewhere in hydration.

---

EDIT: It's even more specific than that! It's only a problem if the preexisting markup exactly matches the first render. Any deviation at all (even a whitespace in the markup that wouldn't affect the render) and everything works as expected. I'm still not sure how (where in the code) the button dissapears though.

[zaceno]

Oooh, now I get it.

Before hyperapp does it's first render, the markup is this:

<main>
  <h1>click the button</h1>
  <example-alert>
    <button>
      alert()
    </button>
  </example-alert>
</main>

... because the custom element inserts the button into itself (yuck) when the DOM first mounts. When hyperapp does is about to do the first render, it parses the current DOM -- shown above, including the button -- into a vnode which it compares to the first result of the view function, which is a vnode corresponding to this:

<main>
  <h1>click the button</h1>
  <example-alert></example-alert>
</main>

-- no button!

So during the first render, hyperapp does exactly what it should do and removes the button (because as far as it knows, the button should no longer be rendered)

Now I also understand why shouldComponentUpdate fixes this in React. Our equivalent to shouldComponentUpdate is memoization -- but that doesn't work for hydration (because nothing is in the memo yet)

Sorry, I can't see any elegant, simple fixes for this a t m. I guess for now, if you use custom elements you can only have hydration if you also use shadow dom.

[naltatis]

EDIT: It's even more specific than that! It's only a problem if the preexisting markup exactly matches the first render. Any deviation at all (even a whitespace in the markup that wouldn't affect the render) and everything works as expected.

I think I don't quite get what you are saying.

In my example the server rendered markup in the html document exactly matches the markup hyperapp would produce on first render. But the fact, that the custom element cames in earlier and modifies the DOM leads to the fact, that hyperapp removes the unexpected children of the custom element. The workaround tries to fix that by grapping the CEs innerHTML before render and refills it in later (oncreate), but looes all events while doing this.

[zaceno]

@naltatis yeah, that's expected since you're not moving the actual elements with event listeners, but creating new ones to mimic the previous ones.

[zaceno]

Thinking about it a little more. Maybe @frenzzy had a point about children and custom elements though... We shouldn't avoid them during patch, but perhaps we should ignore children during hydration (in the recycleElement function).

So this:

function recycleElement(element) {
    return {
      nodeName: element.nodeName.toLowerCase(),
      attributes: {},
      children: map.call(element.childNodes, function(element) {
        return element.nodeType === 3 // Node.TEXT_NODE
          ? element.nodeValue
          : recycleElement(element)
      })
    }
  }

into this:

function recycleElement(element) {
    return {
      nodeName: element.nodeName.toLowerCase(),
      attributes: {},
      children: element.tagName.indexOf('-') ? [] : map.call(element.childNodes, function(element) {
        return element.nodeType === 3 // Node.TEXT_NODE
          ? element.nodeValue
          : recycleElement(element)
      })
    }
  }

It still feels a little hacky, but it works (I tried it), and it should prevent custom elements' children (wether static in markup or dynamically generated) from being deleted on first render. On future renders it won't interfere. The only downside here is that we can't have hydration of children of custom elements, even if they were statically declared in the markup.