Hyperapp: Rename h to createNode.

[jorgebucaran]

Summary

Like the title says. I considered, createElement too, but as you know, h returns a virtual node, not a DOM element.

ES modules.

import { createNode as h, app } from "hyperapp"

From a CDN.

const { createNode: h, app } = hyperapp

Why?

• Easier to document.
• Self-documenting.
• More aesthetically pleasing.

Plan of action

Export h and createNode in the upcoming 1.2.0 release and remove h from 2.0.0.

[behnammodi]

You can, of course, include both of them in order to avoid a breaking

[jorgebucaran]

Definitely.

[behnammodi]

like this

export var createNode = h;

in src/index.js

[frenzzy]

@uxitten nope, like this:

export function createNode(...) {...}
export var h = createNode

Do you want to create a PR? :)

[behnammodi]

@frenzzy ok

[behnammodi]

created PR

[behnammodi]

need update documention

[frenzzy]

@uxitten yep, creating a PR means you need to update all the places including docs and tests :)

[behnammodi]

done

[okwolf]

Won't this somewhat discourage directly using our built-in hyperscript function? I know it's not quite as bad as React.createElement, but still it is an order of magnitude longer 👎

Would JSX users then switch to using:

import Hyperapp from "hyperapp"

and:

{
  "plugins": [
    ["transform-react-jsx", {
      "pragma": "Hyperapp.createNode"
    }]
  ]
}

?

[jorgebucaran]

@okwolf

import { createNode as h, app } from "hyperapp"

import { createNode as el, app } from "hyperapp"

etc.

Also, createNode is easier to document ha. I feel newcomers, pundits and pedants alike will appreciate createNode more than h which is deliberately unclear. We can do better than that.

[okwolf]

@jorgebucaran but if we are expecting/documenting users to rename our export, why even use a different name?

Would anyone really write:

import { createNode } from "hyperapp"

and use createNode as-is?

[jorgebucaran]

@okwolf createNode is a low-level function and we can't make it more user-friendly without compromising performance since we opted for first-class JSX support. If this was not a concern, then I would still rename it to createNode, but not for the reasons above, but simply because it's more readable and self-documenting. I've struggled a lot documenting h, because it's just weird to someone that has never heard about "hyperscript". And I always try to write documentation that does not rely on user's previous knowledge.

I wouldn't use it as createNode, no. I expect people to alias it to h or whatever they prefer instead, but then that's up to them. I know that most people will prefer to use JSX or @hyperapp/html, so this won't be a problem to them.

[lukejacksonn]

So every file that has import { h } from 'hyperapp' will need to be changed for your app to build after this change is merged? That is almost _every_ view file in every hyperapp project. In vein of making the developer experience better.

Have you considered aliasing h to createNode in the docs instead Something like:

Hyperapp uses a function called h to build virtual DOM trees. In the following examples h is going to be aliased to createNode to aid explanation and comprehension. The h is for hyperscript but is usually shortened to a single character for brevity due to how often the function is used.

Regardless of what you name the h function. Know that it is a function that takes three arguments and returns a virtual DOM node of the form { key, nodeName, attributes, children }.

[SkaterDad]

So every file that has import { h } from 'hyperapp' will need to be changed for your app to build after this change is merged? That is almost every view file in every hyperapp project. In vein of making the developer experience better.

This does sound a little annoying, but shouldn't be too hard to find/replace across a whole project.

h is a pretty standard function name in this space (preact, snabbdom, raw Vue, etc...), so I'm not sure I see much value in replacing it. However, it's @jorgebucaran 's framework and if he prefers the other name, so be it. At least we can alias it!

_Side note:_
I tend to use raw h calls in my code. Lately I've been thinking of switching to JSX though to make the element nesting more visually obvious and let mind-bending when I'm staring at a huge view function 😱 The future possibilities of compiling JSX directly to VNode objects is appealing also.

[rajaraodv]

"h" is pretty standard ever since Preact made it popular. I think we should just keep it "h"

[frenzzy]

If docs will continue use h (import { createNode as h } from "hyperapp"), then this change makes no sense IMO.

[Swizz]

How many of you are using h directly ?
I use jsx or html. And I am looking to use ijk, so this change is not going to affect me, mostly.

[lukejacksonn]

This does sound a little annoying, but shouldn't be too hard to find/replace across a whole project.

Across _every_ hyperapp project, which will all need to then be committed, merged and re-deployed. My point is.. huge breaking change and divergence from a well established standard, for what gain? I believe the pains @jorgebucaran is having describing a function called h can be alleviated within the docs and that issues of this nature should not impose breaking changes to the source.

[jorgebucaran]

I am going to end up renaming Ultradom's createNode back to h if this doesn't go through.

[okwolf]

Since #103 merged should we close this?