Extended custom element creation about incremental-dom HOT 5 OPEN

Incremental DOM's current API does not support is directly, though a new one could be added in the future. While this is standard, I think the API is still a bit contentious, and I would like to see all major browsers adopt this before making an API change to support this functionality first class.

There are currently two options if you need to create such a custom element. Given a custom element definition:

class MyList extends HTMLUListElement {
  constructor() {
    super();
  }
}
customElements.define('my-list', MyList , { extends: "ul" });

1. If you have the element definition, pass the constructor to Incremental DOM:

elementOpen(MyList, key, statics);
...
elementClose(MyList);

2. If you don't have the element definition (e.g. need to asynchronously load the definition):

function MyListConstructor() {
  return document.createElement('ul', { is: 'my-list' });
}

elementOpen(MyListConstructor, key, statics);
...
elementClose(MyListConstructor);

The second is a little inefficient in that it creates an extra object that gets thrown away immediately (when Incremental DOM uses new), but the cost is likely not a big deal compared to the element creation itself.

from incremental-dom.

The second case is actually a blocker, if we persist that extended custom element state. With the next patching the state is lost.

Ah, it doesn't pick it up as a matching node. You can do:

function MyListConstructor() {
  return document.createElement('ul', { is: 'my-list' });
}

MyListConstructor.prototype.toString = function() {
  return 'ul';
};

Unfortunately, there doesn't seem to be a way to distinguish this from a plain <ul> as far as DOM diffing goes. So if you had a <ul> adjacent, they could get reused depending on the control flow. As a result, I would strongly recommend enforcing usage of a key if you are going to use this pattern. Note that keys do not need to be unique anymore, so all your instances of the extended custom element can share the same key.

from incremental-dom.

The second case is actually a blocker, if we persist that extended custom element state. With the next patching the state is lost.

from incremental-dom.

Actually, looking at it again, the toString is only needed if you server-side render the extended element. If you client-side render it, it should reuse the element correctly.

If that is not the case, do you have an example where the element is not being reused?

from incremental-dom.

My bad, I overlooked that I should’ve passed the same function each render call. It works like a charm, thanks for your reply.

from incremental-dom.