Monomorphic signature for `patch`

If and when #242 is merged there will internally be a function toVnode that converts an element and all of it’s children to a VNode. From a more general stance of type-safety, I think it’d be even better to have this function publicly exports and be required for the user to make use of, which in turn will allow patch to have a monomorphic type signature. For example

const element = document.querySelector('#root') as Element

const rootVNode: VNode = toVNode(element)

patch(rootVNode, h('div', {}, [ ... ])

Where patch(oldVNode: VNode, vNode: VNode): VNode is the new type signature of patch.

If anyone agrees with me, this is a breaking change, I think the types can be greatly improved from there as well, but I’ll avoid going into that right now.

[acstll]

I honestly think polymorphism in this case is a feature. But, since snabbdom is low-levelish, the less magic the better, so I like the transparency in this:

patch(emptNodeAt(elm), vnode);
patch(toVNode(elm), vnode);

I would only suggest renaming the “empty” option to toEmptyVNode so you can infer both function to the same (turn an element into a vnode) but with different results:

• toVNode turn DOM element into vnode.
• toEmptyVNode discard children of DOM element and turn into vnode.

[paldepind]

@TylorS Good ideas! Having more precise types for vnodes would be really nice.

But I don’t see why allowing a DOM node as the first element to patch would hinder that? Couldn’t the type be like this?

function patch(oldVnode: ElementVNode | Element, vnode: VNode): ElementVNode

Personally, I would not have a problem with only taking a vnode as the first argument to patch. The simpler type is appealing. On the other hand using a DOM node directly can be convenient.

One benefit I see to only allowing vnodes is that if we keep emptyNodeAt and add toVNode then it will be very transparent to users whether or not Snabbdom attempts to patch into the existing dom.

patch(emptNodeAt(elm), vnode); // Obviously does not respect any existing children in `elm`
patch(toVNode(elm), vnode); // Does base patches on the existing structure

The first of the above lines would behave like patch(elm, vnode) does now. But I like how it is more explicit about what happens.