Right now, we have vdom.element() and vdom.text(). Currently they map directly off to Incremental DOM. However, we could create adaptors that could map to any backend. For example, we could serialise data to JSON that could be consumed by a web worker that returns diff / patch instructions for a different virtual DOM implementation.
In the same way we could keep support for Incremental DOM directly via a separate adaptor. This would allow us to create a server-renderer all without changing anything in our components' render() functions. Consumers could leverage whatever vDOM implementation they want via separate modules that they just plug in to their components, or we could just create base-classes / composable functions they call on their definitions to apply support for whatever the plugin is.
Our functions could also attain the same API as Hyperscript / React so it'd inherently be compatible with current JSX transpilers.
This relates to the discussion in skatejs/skatejs#777. We could make our API follow a single consistent convention, such as returning from render() the value that is produced by vdom.element(). What the renderer does with it is up to what the adaptor behind the element functions produce and what the renderer consumes. This makes writing stuff consistent, but our backends agnostic.
Each adaptor would have a specific interface: one that creates elements / text and one that renders (doesn't have to diff / patch either).
any createElement(name, attributes, children)
void renderTree(any data)We could make this API simpler and normalise the arguments to createElement to always be deterministic so the adaptor doesn't have to do any type checking; we'd do that before it is called.
For renderTree(), we would just pass whatever we get from our render() function into that and it takes it from there.
We should strive to remove the reliance on define() for defining custom elements.
We should move whatever we can into the base Component class if we can. If we can't, maybe it'd be easier to turn it into a function that we can compose behaviour into.
import { component } from 'skatejs';
customElements.define('x-test', component({}));Unique names are generated in define(), but nothing says it has to be done there. We could separate that out so it can be used piecemeal.
import { generate } from 'skatejs';
customElements.define(generate('x-test'), class extends HTMLElement {});Currently we have a problem with v0 custom elements where we can't check to see if a component has already been defined with a given name. This is only available in v1 by using customElements.get('x-test'), which returns the registered constructor. This means that creating a function that will auto-create a name depending on if something is already registered isn't possibly without trying to first register it. This makes it hard to decouple it from define() without only supporting v1.
This doesn't mean we have to remove define as it could just be a formalised way of composing this behaviour and auto-registering; safe defaults.
define('x-test', {
render() {}
});
// could be the same as
customElements.define(generate('x-test'), component({
render() {}
}));