Just wondering what would happen if we change the VNode type from:
const vnode = {
type: "h1",
props: { class: "heading" },
children: "Hello"
}
to this:
const vnode = ["h1", { class: "heading" }, "Hello"]
To generate the vnode you call h("h1", { class: "heading" }, "Hello") as usual.
This is a private API, so it would not be a breaking change unless you were creating vnodes directly without h().
This reminds me of some performance advice from Elm:
Prefer arrays over dictionary objects. Crawling an array is much faster than crawling an object. for (var key in object) is just never going to be as fast as for (var i = 0; i < len; i++). Whenever there is a dynamic number of things, find a way to allocate them one-by-one at the end of an array.
you should bench this. javascript JITs will recognize the object by its consistent shape and optimize it via a hidden class. arrays are only faster for iteration. i dont think you intend to iterate vnode properties so it's likely a net perf regression.
I experimented with this and found it yielded less code, because it removes h(), but then we need to make up for h param normalization with more checks which are only likely to slow us down.
馃様
@Swizz We could still have a function that turns a VNode into a cool array VNode though.
Most helpful comment
you should bench this. javascript JITs will recognize the object by its consistent shape and optimize it via a hidden class. arrays are only faster for iteration. i dont think you intend to iterate vnode properties so it's likely a net perf regression.