Standard way to set props, attributes and bind events

[treshugart]

I wanted to see how you feel about trying to standardise a default way to allow a consumer to set properties, attributes and events.

The React community currently have a couple issues open related to this for better DOM integration (though, it says web components, it can be considered just DOM):

• Custom events: https://github.com/facebook/react/issues/7901
• Attributes and properties: https://github.com/facebook/react/issues/7249

I'd very much like to see alignment as much as possible between virtual DOM implementations. Though, Incremental DOM takes a different approach than others (for good reason), I still think there can be some consistency here.

For my proposal, I've created an implementation of what it might look like in Incremental DOM. I realise that this could very easily be a library on top of iDOM, but I feel it would be worth discussing whether or not iDOM could have an opinion here. Most consumers would have to end up doing something around this anyways - especially for custom events - so it might be nice to have a default, opinionated, way of doing so.

The only caveats here, is in this implementation, setting attributes and events require heap allocations for the objects passed in. For example:

attr('attributes', { ... });

A possible way around this might be to accept ...rest arguments:

attr('attributes', 'name1', 'value1', 'name2', 'value2');

Thoughts?

[matthewp]

I think this is a great idea, especial for events. I agree that the rest args is a good way to go, keep it low level.

[treshugart]

We'll be implementing this in SkateJS and be wrapping iDOM to do so, regardless, but it'd be nice to see this handled at the iDOM level.

[sparhami]

The current plan is to have an API for apply attributes and properties (and maybe events too). It will look like:

open('div');
  bufferAttribute('name1', 'value1');
  bufferAttribute('name2', 'value2');
  applyDiffs();
close('div');

After, that, I think a high level API will be added, perhaps something like:

open('div', {
  key: someKey,
  attributes: {
    'name': 'value'
  },
  events: {

  },
  someProp: someValue
});
close('div');

which will simply use the lower level calls. Some time after that, I want to write something that will transform the higher level calls into the lower level calls. This won't be able to handle all cases (e.g. if you pass an object to the function for attributes), but should help most of the time. The remaining cases can be a warning, error or just left alone based on what you want to do.

Haven't quite thought through the higher level API. It could also do something like treat everything named 'on-eventname' as a listener.

[treshugart]

After, that, I think a high level API will be added, perhaps something like:

That would be awesome!

Some time after that, I want to write something that will transform the higher level calls into the lower level calls.

Isn't that exactly what the open('div', {}) API would do? Or something even more high level? Something we've done in Skate is to offer a hyperscript-style API (using h, so it works directly with JSX transforms without using the iDOM specific transform).

For example:

import { h } from 'incremental-dom';

h('div', { prop: true, events: { click } },
  h('span', 'text')
);

This might be something a higher-level API could offer. It requires you create functions for each node, though.

[sparhami]

Isn't that exactly what the open('div', {}) API would do?

It would be a build time transform directly into the lower-level API.

[treshugart]

It would be a build time transform directly into the lower-level API.

Ahh, that makes sense now.

Instead of doing something like:

open('div', {
  key: someKey,
  attributes: {
    'name': 'value'
  },
  events: {

  },
  someProp: someValue
});
close('div');

It'd be interesting to experiment with making something like hyperscript the high-level API. It seems to be the API that most virtual DOM libraries have landed on as the underlying system for constructing a virtual tree. Incremental DOM could benefit from other libraries that transform to hyperscript and then use the iDOM transform to go from that to lower-level calls. It would also aid in migrating from other libraries to Incremental DOM.