Very small breaking change to the API to use custom elements, but nevertheless a breaking change. This version fixes custom element glitches such as the ones described in #77. Most of your v0.14 code will work in v0.15, but we advise to use keys on custom elements as much as possible.
BEFORE
h('my-customelem', {foo: 'all your base are belong to us'})AFTER
h('my-customelem', {key: 1, foo: 'all your base are belong to us'})Notice the key for the custom element. This is a virtual-dom key attribute for virtual-dom Widgets.
This breaking change and advice also makes a lot of sense for rendering as a whole, this is not a leak in the abstraction. It is necessary for identifying that the element in question is still the same even though its properties might have changed. Counterexample:
Imagine you have a custom element 'gif-with-filters' which plays an animated gif, but you can specify a color filter such as "black and white" or "sepia". If you don't use a key for this element, when the filter property changes (for instance from BW to sepia), we will have an ambiguous situation. The virtual DOM diff and patch will not know whether you want to (1) replace the current gif-with-filters BW with a new gif-with-filters sepia, hence restarting the gif animation, or (2) keep the same gif-with-filters element but just swap the filter from BW to sepia without restarting the animation. To fix this ambiguity we use keys. If you want (1), then you provide a different key when you change the filter. If you want (2), then you provide the same key but change the filter property. Both cases (1) and (2) should be equally easy to express, and should be a responsibility of the app developer.