Fix properties classified as nodes

[StarpTech]

In the current state, the input (see below) is interpreted as div with a children because there is an assumption that every node will has a value attribute. This PR will remove this assumption. BTW: The different overloads makes the code very hard to read. I recommend to refactor this in the future.

The change in the script was need to run the format script on windows.

h('div', { type: 'test', value: 'value' })

{ type: 'element', tagName: 'div', properties: {}, children: [ { type: 'test', value: 'value' } ] }

expected

h('div', { type: 'test', value: 'value' })

{ type: 'element', tagName: 'div', properties: { type: 'test', value: 'value' }, children: [] }

[StarpTech]

I just recognized that's harder than expected because the assumption is needed for packages like https://github.com/syntax-tree/unist-builder/blob/master/index.js

[StarpTech]

I suggest introducing a way to differentiate between user nodes.

const u = require('unist-builder')
u instanceof UnistNode

// or
const ss = require('syntaxtree-symbols')
u[ss.unist] === true

//or specific for this case to agree on a flag to force that properties were passed
h('div', {
  type: 'test',
  value: 'value',
  [Symbol.for('hast.isProp')]: true
})

[wooorm]

Yeah, that’s pretty magic behaviour. 🧙🏽‍♀️

The thinking goes that type makes a thing a node, instead of a property, except for some cases (like inputs or buttons, which are even harder, because they also have value).

u doesn’t have this problem because you can’t pass a single node to be used as children. You must always pass an array of children. h does let you pass one node.

Tests don’t break, but it will break other projects, as they do for example h('div', {type: 'text', value: 'foo'}), to add a text node.

From reading the test, but maybe I’m too biased, I’d guess that h('div', {type: 'test', value: 'value'}) (or h('div', u('test', 'value'))) actually adds node to the div, and not that it adds properties.

[wooorm]

Sorry for the wait. The reason for that is that a) I’m uncomfortable favouring non-standard HTML over supporting h('div', u('text', 'alpha')), but also b) recognise that there are cases where you’d want this.

I feel stronger about a), so I’m closing this PR. However, I would accept a PR that does b) by adding a symbol as e.g. h.properties that can be used to signal a child node is instead a properties object.
If using symbols, I’d like to make sure that it would not fail in environments that do not support symbols (such as like this).