Dynamic prop/attr names

[dy]

Not the same as #109.

That would be useful to have insertable attribute names:

html`<a ${foo}=${bar}/>`
// same as
html`<a ...${ {[foo]: bar} }/>`

Practical cases

Optional attributes:

html`<button ${ data.disabled ? 'disabled' : '' }/>`

Private props:

let html = htm.bind(h)

let _data = Symbol('data')
html`<a ${_data}=${data}/>`

function h (tag, props) {
  props[_data]
}

Anonymous props:

html`<a ${draggable}/>`

function draggable(el) {
...
}
draggable[Symbol.toPrimitive] = () => 'data-draggable'

@developit @jviide would you consider that feature?

[dy]

@developit any thoughts? I can devote some time for a PR.

[dy]

@developit @jviide

[developit]

TBH it doesn't seem like these fit with the minimalistic philosophy of htm. They are all relatively easy to accomplish already using objects, and the resulting output (when not over-transpiled) represents a real improvement over what we'd have to do to support the sugared syntax in HTM's parser.

let _data = Symbol('data')
html`<a ...${{ [_data]: data }} />`
// output:
h('a', { [data]: data })

Regarding the last example, this might be interesting to you (demo):

function draggable(el) {}
draggable['data-draggable'] = true;

html`<a ...${draggable}/>`

[dy]

it doesn't seem like these fit with the minimalistic philosophy of htm

#121 suggests distinguishing min / max philosophies, since that's already shipped.

Would it be nice to have htm-max with syntactic sugar/sauce (html-compatible, validation, unclosed tags, dynamic attributes), and keep htm-min JSX-compatible?

[jviide]

I'd like to point out that htm/mini is functionally identical to the regular htm.

[dy]

htm/mini is functionally identical

What is this argued by? What are the pros having it identical? Or, rather, what's the point of htm/max then? A safe-ground implementation? (mb the discussion belongs to #121).

This distinction potential seems to be underdeveloped.

[jviide]

htm and htm/mini implement the same "language" and produce the same output for the same given input.

Their only real difference is that htm/mini doesn't do caching, which allows us save some implementation bytes. The brotli-compressed htm/mini is 170 bytes (~29%) smaller than htm. Whether this size reduction is worth the effort of maintaining two different builds is IMHO a different issue and best left for #121.

Currently the point of htm/mini is to be a drop-in replacement for htm, allowing the library user make a tradeoff between execution speed and code size, depending on their specific situation.