Release 0.4.0

[wavesoft]

This is the preview of the 0.4.0 release

Changelog

• FIXED (Does not handle children that are numbers #31) Now handling children as numbers
• FIXED (JSX support? #51) Adding proper JSX support
• REFACTORED The reconciliation algorithm, in order to use keys
• ADDED The k property that can be used for hinting the reconciliation key
• SWITCHED to brotli instead of gzip to maintain the 512 byte contractual limit

[mindplay-dk]

Regarding this bit...

dot-dom/src/dotdom.js

Lines 235 to 241 in ddd6d50

	? dom.insertBefore( // a. If the node should be re-ordered, place it right after
	_prevnode || // the last known item.
	(_xvnode.$
	? document.createElement(_xvnode.$)
	: document.createTextNode(_xvnode)),
	dom.childNodes[idx]
	)

First of all, if this expression is running, don't we already know that the key didn't match, and thus the DOM node must be new?

Secondly, it looks like _prevnode isn't the "previous node", as I first thought - it looks like this is actually the "previous vnode", so if _prevnode did evaluate as truthy, you would actually end up passing a vnode object, rather than a DOM node, to insertBefore, which wouldn't work.

My suspicioun is that _vnode always evaluates as falsy and the second expression after the || operator always executes - so I think you can actually just delete the _prevnode || part of the expression.

Am I wrong??

[wavesoft]

Not true.

1. _prevnode is the previous DOM element. It will be falsy in any of the following conditions:

   • This is the first time this element appears on this path or
   • The element has changed key (eg. changed it's type)

2. Note that a few properties from the VDom element are copied onto the DOM element in order to save some space by not carrying around the state variables. These are assigned here and defined here. That's why some time it's confusing to find out which is a DOM and which is a VDom element.

3. This particular branch does the following:

   • If this is the first time this VDom element appears:
     • It creates a new DOM Element (or a Text node accordingly)
     • It appends it on the DOM, at the expected order
     • It returns the new element in order for the parent function (updateDom) to reconcile the props
   • If the VDom element has changed type, it's key will be different and therefore a new node will be created. The same things as above will happen, however the replacement will happen in two steps:
     • It will place the new DOM element right before the previous DOM element
     • During the reaping phase the old DOM element will be deleted
   • If the DOM element exists and it's of the same type as the VDom element, the old instance is maintained and it's properties is being reconciled

[mindplay-dk]

Oh man, unpacking this code is really tricky... I wish like hell there was a tool that would automate these spooky compression patterns so no one would need to write code like this. 😐

Anyway, thanks for the explanation. 🙂

[mindplay-dk]

Oh, one thought about keyed updates: I noticed you use the user-supplied key and then fall back to a generated key, e.g.:

key = userKey || " " + elementType + nextIndexFor(elementType)

In my own experiments, the element type is always part of the key - something like:

key = elementType + " " + (userKey || nextIndexFor(elementType))

Otherwise, if we were to diff between, say, <div key="foo"> and <img key="foo">, these would be seen as the same element, wouldn't they?

[mindplay-dk]

Any reason this got stranded here?

I think the only issue was the element-type missing from the key?

Other than that, it looks good to go?