Support explicit attribute and property bags

[Matthew Gadd]

Currently maquette uses a heuristic (string) on whether to set as an attribute or property on the node. It would be nice in the future if maquette could (optionally?) also take a more structured bag of options as the second parameter to h().

This would allow users to set things specifically as an attribute, as well as having more structure to the options (ie we could also split the events). Strawman example:

h('div', {
  properties: { foo: 'bar' },
  attributes: { bar: '2' },
  on: { 'click': myEventHandler }
})

[Johan Gorter]

Do you maybe have some examples where this would be beneficial? All I am seeing is extra overhead when you just need a simple h('a', {href: '#'}) for example.

[Matthew Gadd]

@johan-gorter yes, custom elements specifically. some custom elements behave differently for properties and attributes, at the moment there is no way to set a property as a string with maquette.

The separate bags also clearly delineate responsibility, ie the event handlers would no longer need a sniff of a function nor an indexof check for on, it also opens up extension possibilities on the options bag itself under additional keys.

[Johan Gorter]

Forcing the VNodeProperties to be split up would be a big change for maquette users. At AFAS, we already have 1200 usages. It would also make the hyperscript much more technical than HTML is. We could add the properties key however to enable string properties.

A custom element with a string property that is not exposed as an attribute is not very useful when using the custom element from HTML by the way.

[Matthew Gadd]

@johan-gorter I did say an optional bag. I'm not sure the argument of more complicated than html is valid, because in just html you can't set properties anyway.

In terms of custom elements, here is the discussion with the google team in this thread: https://twitter.com/justinfagnani/status/901158151415660544. I tend to agree with the takeaway that attributes !== properties and custom elements could implement differing behaviour for an attribute over a property and vice versa (regardless of whether its good form).

[Johan Gorter]

Making it optional sounds doable. I think that the following Typescript signature for the h function would then be best.

h(selector: string, properties: VNodeProperties | PropertiesBag, children: VNodeChild[])

I do want to see if more people want/need this, because there is some overhead involved.