Mithril.js: Removed nodes stay in the DOM after m.render

Created on 15 Mar 2018 · 5Comments · Source: MithrilJS/mithril.js

Expected Behavior

The following sequence of renders should show only one button

m.render(root, m('a', {}, 'content'));
m.render(root, m('a', {key: 'my-key', oncreate: () => {}}, 'content'));
m.render(root, m('button', {}, 'content'));

Full example

<html>
<head>
  <title>Mithril test</title>
</head>
<body>
<div id="app"></div>
<script src="https://unpkg.com/[email protected]/mithril.js"></script>
<script>
  const root = document.getElementById('app');

  m.render(root, m('a', {}, 'content'));
  m.render(root, m('a', {key: 'my-key', oncreate: () => {}}, 'content'));
  m.render(root, m('button', {}, 'content'));

</script>
</body>
</html>

Current Behavior

Currently the old <a> node stays in the DOM, but it is not expected.

Possible Solution

The node recycling doesn't work well, and doesn't recognize that older <a> node not used anymore.

Context

I have a component, based on Mithril. It re-renders itself based on some properties provided. When it receives certain order of properties, it doesn't remove node, so you see old and new buttons at the same time, which is obviously breaks UI.

For a workaround I currently assigned absolutely unique keys on every render. It seems to work, but kills all benefits of using Virtual DOM and Mithril in particular.

I have also found https://github.com/MithrilJS/mithril.js/issues/2024 that looks anyhow affecting this behavior

Your Environment

Version used: 1.1.6
Browser Name and version: tested at least in latest Chrome and Firefox
Operating System and version (desktop or mobile): destop

Bug

Source

just-boris

Most helpful comment

As is next is v2.0 WIP, but we do backport some patches into v1. I'll have to review if that fix is suitable for a backport.

pygy on 16 Mar 2018

👍3

All 5 comments

If you render without the key it works correctly.

m.render(root, m('a', {}, 'content'));
m.render(root, m('a', {oncreate: () => {}}, 'content'));
m.render(root, m('button', {}, 'content'));

I'm sure it's another weird edge-case around keyed vs unkeyed nodes so #2024 is likely the correct related issue.

tivac on 15 Mar 2018

This is actually fixed in next.

pygy on 16 Mar 2018

Does the next brach contain next major release (2.0) or it will be published as a minor update?

just-boris on 16 Mar 2018

As is next is v2.0 WIP, but we do backport some patches into v1. I'll have to review if that fix is suitable for a backport.

pygy on 16 Mar 2018

👍3

I have a similiar issue which breaks without keys on subsequent renderings. Looks like this is also fixed in next. Please consider trying to backport this fix.