Sure thing! Following a lighterhtml integration example, also live in CodePen:

import {render, html, svg} from 'lighterhtml';
const LighterHTML = {
  html() { return render(this.element, html.apply(null, arguments)); },
  svg() { return render(this.element, svg.apply(null, arguments)); }
};

import {define} from 'wicked-elements';
define('.my-component', {
  ...LighterHTML,
  init() { this.render(); },
  render() {
    this.html`<h3>Hello 👋</h3>`;
  }
});

You can either check hookedElements for an out-of-the-box solution, or you could use augmentor, which is just perfect for this use case 😉, which is indeed exactly what hookedElements use (it's just automatically integrated).

Test it live on CodePen.

import {augmentor, useState} from 'augmentor';
import {define} from 'wicked-elements';
define('button.counter', {
  init() {
    // augment once any method, and that's it 🦄
    this.render = augmentor(this.render.bind(this));
    this.render();
  },
  render() {
    const [counter, update] = useState(0);
    const {element} = this;
    element.onclick = () => update(counter + 1);
    element.textContent = `${counter} clicks`;
  }
});

This is a classic one, the WebComponents.dev click counter, also in in CodePen.

Sure. Here any element with a disabled class will effectively become disabled.

wickedElements.define('.disabled', {
  init() {
    const {element} = this;

    // if the element has its native way to be disabled, return
    if ('disabled' in element)
      return;

    // otherwise define the behavior
    Object.defineProperty(element, 'disabled', {
      get: () => element.hasAttribute('disabled'),
      set: value => {
        if (value) {
          element.style.cssText = this.disabled;
          element.setAttribute('disabled', '');
        }
        else {
          element.style.cssText = '';
          element.removeAttribute('disabled');
        }
      }
    });

    // if the element was live, just trigger/ensure its status
    element.disabled = element.disabled;
  },
  // the style to attach to disabled elements
  disabled: `
    pointer-events: none;
    opacity: 0.5;
  `
});

Once a definition is known, even same DOM nodes can be handled by multiple definitions/behaviors.

As example, here we are addressing all elements that will eventually have a [disabled] attribute.

wickedElements.define('[disabled]', {
  onMouseOver() {
    const {element} = this;
    // as elements can be promoted but never come back,
    // which is the same that happens to Custom Elements definitions,
    // we can check these elements are still disabled, per each mouseover event
    if (element.disabled) {
      element.style.visibility = 'hidden';
    }
  },
  onMouseOut() {
    this.element.style.visibility = 'visible';
  }
});

Each definition/behavior will provide a new instance of such definition (definition as prototype), meaning there are no conflicts between definitions, and each wicked instance deals with what its prototype object had at the time of definition.

Same as Custom Elements suffer name-clashing, so that you can have only one custom-element definition per page, wicked definitions also could clash if the name is too generic.

It is a good practice to ensure, somehow, your definitions are namespaced, or unique enough, if you're after portability.

wickedElements.define('[data-wicked="my-proj-name-table"]', {
  // unique(ish) definition what will likely not clash with others
});

Using data-wicked="..." is convenient to also be sure a single element would represent the definition and nothing else, as you cannot have multiple values within an element.dataset.wicked, or better, you can serve these components via Server Side Rendering and reflect their special powers via JS once their definition lands on the client, which can be at any given time.

Using a runtime unique class/attribute name also grants behaviors and definitions won't clash, but portability of each wicked behavior could be compromised.

There are cases where an element might not become wicked, such as when the element class changes at runtime, and after the definition occurs.

wickedElements.define('.is-wicked', {
  init() {
    this.element.classList.remove('not-wicked-yet');
    console.log(this.element, 'is now wicked 🎉');
  }
});

const later = document.querySelector('.not-wicked-yet');
later.classList.add('is-wicked');
// ... nothing happens ...

For obvious performance reasons, the MutationObserver doesn't trigger per each possible class change in the DOM, but fear not, like it is for customElements.upgrade(element), you can always upgrade one or more elements via wickedElements.upgrade(element).

wickedElements.upgrade(later);
// console.log ...
// <div class="is-wicked"></div> is now wicked 🎉

If you'd like to upgrade many elements at once, you can always pass their top-most container, and let the library do the rest.

// upgrade all wicked definitions at once 👍
wickedElements.upgrade(document.documentElement);

Don't worry though, elements that were already wicked won't be affected by an upgrade, so that each init() is still granted to execute only once per fresh new element, and never again.