skatejs / kickflip

[DEPRECATED] - Functional web components based on the W3C web component specifications.

Skate

Skate is a functional reactive abstraction over the web component standards as a set of packages that enables you to write small, fast and scalable web components using popular view libraries such as React, Preact and LitHTML.

• 🌏 Cross-framework compatible components.
• ⚛️ Render components using your favourite view library, or none at all.
• 👑 Guided conventions for best-practices when reflecting between, and reacting to attributes, properties and events.
• 🌟 Full TypeScript support.
• 📚 Docs https://skatejs.netlify.com.

Getting started

The simplest way to get up and running is to start with a pre-configured element such as @skatejs/element-lit-html.

npm i @skatejs/element-lit-html

Simple example

import Element, { html } from '@skatejs/element-lit-html';

export default class extends Element {
  static get props() {
    return {
      name: String
    };
  }
  render() {
    return html`
      Hello, ${this.name}!
    `;
  }
}

Other examples

1. Todo list

Cli

There's a CLI to get you up and running: https://skatejs.netlify.com/packages/cli.

$ npm i -g @skatejs/cli
$ skatejs

Polyfills

Skate builds upon the Custom Elements and the Shadow DOM standards. It is capable of operating without the Shadow DOM — it just means you don't get any encapsulation of your component's HTML or styles. It also means that it's up to you to provide a way to project content (i.e. <slot>). It's highly recommended you use Shadow DOM whenever possible.

Though most modern browsers support these standards, some still need polyfills to implement missing or inconsistent behaviours for them.

For more information on the polyfills, see the web components polyfill documentation, emphasis on the caveats.

Browser Support

Skate supports all evergreens and IE11, and is subject to the browser support matrix of the polyfills.

Backers

Support us with a monthly donation and help us continue our activities. Become a backer!

Sponsors

Become a sponsor and get your logo on our README on Github with a link to your site. Become a sponsor!

kickflip's Issues

Move special behaviour from VDOM factories into Incremental DOM handlers

We currently check some attributes in the factory functions and apply them in different ways depending on what they are. Instead, we should create Incremental DOM attribute handlers for them and handle them at that level. This would enable JSX -> IDOM compilation to take on the same semantics as our VDOM functions.

Listeners using on* syntax should not trigger for bubbled events.

Spike using Virtual DOM instead of our own implementation.

It'd be nice to not have to maintain our own implementation, so we should spike using Virtual DOM as the defacto diff / patch implementation for this.

However, there are some advantages to our implementation we should consider:

1. It's smaller.
2. It can diff real DOM and virtual DOM interchangeably.
3. On initial investigation it seems smarter about attribute / property setting.
4. Does Virtual DOM bind events?

Number 2 and 4 are a must and we can probably work around number 3. Number 1 isn't very important as it's not that much smaller (30k unmin or so).

The biggest priority is ensuring that we can still do element.appendChild(node) and not lose a reference to node during the rendering process. Maybe due to the nature of the patching process and doing as little transformations as possible, this is not possible. Need to investigate.

The kickflip() custom element name should be optional.

If it is optional, kickflip() should return a function that accepts a name which will return a constructor.

This should still be supported:

const MyElement = kickflip('my-element', {
  render () {}
});

However we should support this:

const defineMyElement = kickflip({
  render () {}
});

const MyElement = defineMyElement('alternate-name');

Export incremental-dom functions from src/vdom

This would allow consumers to use any templating language that compiles down to Incremental DOM while keeping the way we've configured it to run.

This means they can:

import { elementOpen, ... } from 'kickflip/src/vdom';

Spike using Incremental DOM instead of our own implementation.

See #1 and https://github.com/google/incremental-dom.