child-array re-use error about dyo

[thysultan]

This probably has nothing to do with race conditions or useCallback and more with holding onto references of the virtual nodes instead of using a declarative approach.

i.e

Ripple = ->
  [$waves, setWaves] = useState []

  ripple = useCallback ->
    $wave =  [Math.random()]
    setWaves $waves.concat $wave
    window.requestAnimationFrame ->
      setWaves _.without $waves, $wave
  , [$waves]

  h 'div',
    className: 'ripple'
    onmousedown: ripple
    $waves.map(v => h('div', {}, v))

[thysultan]

Yes, that was one of the breaking changes from v8 -> v9/dyo-v1, which carried over to dyo. It wasn't worth the complexity to support it since it's not idiomatic to the declarative paradigm.

[thysultan]

Similar reason as to why we append empty in the current instalment https://github.com/dyo/dyo/blob/master/src/Element.js#L137 it acts as an anchor node for the fragment, and arrays act like fragments in order to be afforded a certain level of isolation from siblings, this can avoid key collision under certain conditions i.e in

h(div, {}, [h('h1', {key: 1}, 1)], [h('h1', {key: 1}, 1)])

Both heading are under separate namespaces(arrays) so can reuse the same key, this is more useful when you are using something like

h('div', {}, 
   arr1.map(v => h('h1', {key: v.id}, v.data)),
   arr2.map(v => h('h1', {key: v.id}, v.data))
)

...and not have to worry whether v.id in the two data source will collide.

I put null instead of empty() because they are effectively represent they same type of node vice-versa.

[thysultan]

This is expected.

[Zolmeister]

@thysultan How so? This worked in dio v8

[Zolmeister]

@thysultan can this be detected easily to produce a better error message?
Edit: note that it does not throw in React

[thysultan]

Looking at this closer: the following also resolves this issue:

  h 'div',
    className: 'ripple'
    onmousedown: ripple,
    [...$waves], 'or', ...$waves

[thysultan]

If we change: https://github.com/dyo/dyo/blob/master/src/Element.js#L137 to

return iterable(value.concat(null), hash(index))

It should solve that issue. Current code reuses(direct assignment) the array which avoids creating a new array but concat could be just as fast/negligible.

[Zolmeister]

Great
Also value.concat(null) appends a null (not sure if it matters). Use value.concat() instead.

Edit: value.slice() is fastest (for me) - https://jsperf.com/cloning-arrays/38

[thysultan]

not sure if it matters

The append a null part is deliberate.

[Zolmeister]

Why append null?

[thysultan]

Better comparison of current(push) vs the proposed(concat): https://jsperf.com/concat-vs-inline-push

[Zolmeister]

Perhaps running a more realistic benchmark would help understand the impact.
e.g. https://github.com/krausest/js-framework-benchmark

From a correctness standpoint I think mutation should be avoided.
Could you anchor the fragment by polluting its properties instead?

[thysultan]

Yes, testing the whole h/createElement function variants would be the better comparison.