Miss any of our Open RFC calls?Watch the recordings here! »

wicked-elements

2.1.0 • Public • Published

wickedElements 🧙

Social Media Photo by Jonatan Pie on Unsplash

An all inclusive ~1.3K library to handle any element as if it was a Custom Element.

import {define, get, upgrade, whenDefined} from 'wicked-elements';
const {define, get, upgrade, whenDefined} = require('wicked-elements');
<script src="https://unpkg.com/wicked-elements">
  // as global variable
  wickedElements.{define, get, upgrade, whenDefined};
</script> 

V2 Breaking/Changes

There was asymmetry with native Custom Elements attributeChangedCallback(name, oldValue, newValue) which has now been fixed.

Before, attributeChanged(name, newValue, oldValue) was the behavior, in V2 is aligned with native Custom Elements, so it's now attributeChanged(name, oldValue, newValue).

V1 Breaking/Changes

  • half of the size, wickedElements is now less than 1.5K, more like 1.1K in its ES2015 compatible environments version (see new.js file)
  • wickedElements requires zero polyfills whatsoever: everything is provided, and granted to work, out of the box
  • wickedElements has been tested, and works as is in IE11 and in every other Desktop or Mobile browser compatible with WeakMap and MutationObserver.
  • the v0 style feature has been removed, as coupling styles within JS, same way you'd do by including a CSS file, didn't really add much value
  • dropped classes as definition, just pass an object literal
  • this.element automatically provided and already available in the init
  • direct connected, disconnected, and attributeChanged invokes (no more event driven)

API

Exact same customElements API, with the following differences:

  • wickedElements.get(CSS) returns the component definition, which should be an object literal, or a combination of definitions (i.e. Object.assign({}, BaseDefinition, OverwritesDefinition))
  • wickedElements.define(CSS, definition) accepts any CSS selector, where the more specific it is, the better.

The definition is a literal object with optional helpers/utilities described as such:

wickedElements.define(
  // a unique, specific, CSS selector that will become wicked
  '[data-wicked="my-component"]',
  {
    // a one-off, `constructor` like, initialization,
    // the right place to populate node content, add listeners, or setup components
    init() {
      // the element that is related to this wicked instance will be always
      // reachable through `this.element`, even without an `init()` method
      this.element;
      // always points, in every other method, to the DOM element related
      // to this wicked element/component
    },
 
    // Custom Elements like callbacks, without the redundant `Callback` suffix
    connected() {},
    disconnected() {},
    attributeChanged(name, oldValue, newValue) {},
 
    // as optional property used only if `attributeChanged` is defined,
    // it will eventually confine `attributeChanged(...)` calls
    // by monitoring only a well known set of attributes
    observedAttributes: ['data-thing', 'value'],
    // if omitted, or empty array, will notify all attributes changes
 
    // zero, one, or more, listeners, automatically setup per each component
    // the context of each method-listener will be the wicked instance,
    // not the element itself, but you can reach event.currentTarget or this.element
    // at any time within the code
    onClick(event) {},
    onCustomEvent(event) {}
    // if defined camelCase, events will be attached both lowercase
    // and also camelCase, so that element.dispatch(new CustomEvent('customEvent'))
    // or element.dispatch(new CustomEvent('customevent')) will both work.
    // the `event.type` will be the one dispatched, i.e. `click` or `customEvent`
    // or even `customevent`.
 
    // any property with an `Options` suffix, will be used to add the listener,
    // so that special cases like `{once: true}`, `true` to capture, and others,
    // can be easily addressed through the definition. By default, options is `false`.
    onClickOptions: {once: true}
  }
);

F.A.Q.

Can I use 3rd parts libraries to render content?

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>`;
  }
});
Can I haz hooks too?

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`;
  }
});
Any basic example to play with?

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

Any other example?

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.

Any caveat/hint to consider?

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.

My element doesn't become wicked, what should I do?

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.

Install

npm i wicked-elements

DownloadsWeekly Downloads

68

Version

2.1.0

License

ISC

Unpacked Size

42.5 kB

Total Files

13

Last publish

Collaborators

  • avatar