Mithril.js: Sharing keyed/unkeyed logic leads to inconsistent behavior

Created on 28 Oct 2017  路  3Comments  路  Source: MithrilJS/mithril.js

This is a core bug in updateNodes

const cmp = {
  view(){},
  oncreate(){console.log('C')},
  onupdate(){console.log('U')},
  onremove(){console.log('R')}
}

console.log('different length')
m.render(document.body, [m(''), null, m(cmp)])
m.render(document.body, [m(''), m(cmp)])
m.render(document.body, [m(''), null, m(cmp)])

console.log('same length')
m.render(document.body, [m(''), m(cmp), null])
m.render(document.body, [m(''), null, m(cmp)])

logs

'different length'
'C'
'U'
'U'
'same length'
'R'
'C'
'R'
'C'

Flems

Replacing nulls with false or '' in the first half also causes onremove/oncreate to fire as I'd expect.

This is due to the fact that keyed/unkeyed diff share the same logic when the old and new lists have different length and keyed diff skips null nodes. There's a special loop for unkeyed diff when both the old and the new list have the same length though, which explains the "same length" behavior (it is only triggered when two nodes at the same index in old and vnode are both non-null and unkeyed, hence the m('') in the example above).

Suggested fix: Move all unkeyed diff to its own loop (PR incoming).

Also, good news, at long last I'm starting to feel at ease in updateNodes() :-)

Bug

Most helpful comment

Another updateNode bug (when mixing the pool with vnodes cached in user land).

I have a POC fix for the various updateNodes bugs that have popped up recently, but there are perf regressions (the unkeyed diff has too many branches and fetches from the pool even for possibly sparse tuples of identical lengths where it doesn't make sense (what is currently handled by the isunkeyed loop)).

I have another solution I want to test. If I get it to work, I'll slice the result into piecemeal tests/fix pairs (one per issue) and submit a PR.

All 3 comments

Another updateNode bug (when mixing the pool with vnodes cached in user land).

I have a POC fix for the various updateNodes bugs that have popped up recently, but there are perf regressions (the unkeyed diff has too many branches and fetches from the pool even for possibly sparse tuples of identical lengths where it doesn't make sense (what is currently handled by the isunkeyed loop)).

I have another solution I want to test. If I get it to work, I'll slice the result into piecemeal tests/fix pairs (one per issue) and submit a PR.

Is this a repro of the same issue or something slightly different?

@orbitbot sorry for the delay, in your example, the lists has mixed keyed and unkeyed children, which is unsupported.

Was this page helpful?
0 / 5 - 0 ratings