Closed jorgebucaran closed 6 years ago
It would be much nicer if we didn't have to pass a schema so yeh, I would certainly consider it. Another option I thought of is to be able to pass ijk
an h
to try figure out what schema it should output.. something like:
import { app, h } from 'hyperapp'
import { build } from 'ijk'
const View = build(h)(...)
Either that or export different h
for each vdom type:
import { h } from 'ijk/hyperapp'
import { h } from 'ijk/preact'
I am up for exploring all of these options!
I think both options are possible. I've seen the second style used in other projects that support different view frameworks.
Hyperapp's vdom object schema changed. So I am going to do something about this now. I'd like to export just one h
with the schema nodeName, attributes, children
to accommodate at least preact and hyperapp out of the box.
The obvious downside to this is if people want to use this lib with other vdom libraries. In reality I doubt anyone is so perhaps it is better to be opinionated now and change later if required.
Maybe you can still export the original h
from a sub-package or similar?
import { h } from "ijk/factory"
h("name", "props", "children")(...)
Perhaps something as rudimentary as..
export const h = build('nodeName', 'attributes', 'children')
export const factory = build
I can't decide 😅 something else to consider is what @JorgeBucaran said about keys.. and where they live. Which I believe, is no longer in attributes but on the root of the vnode itself. Am I right in thinking this?
Yes, they are now taken from the attributes and placed on the root of the virtual node itself.
@lukejacksonn I think using the framework's exported VDOM builder function is far more robust than my proposal, but if you are willing to take the "risk", returning the raw VNode object would make ijk even more fun to use. Whether you implement this feature or not is up to you. You did a great job here!
@lukejacksonn If https://github.com/hyperapp/hyperapp/issues/578 lands, would you consider changing ijk so it can be used like this:
...without a call to
h('name','props','children')
to create the actualh
function? In other words, have the exportedh
return an opinionated Virtual DOM schema like { nodeName, attributes, children }.