Double initialization of mounted component

[hankeypancake]

So, I did something stupid and found a very weird edge case. Basically I mounted a component and in a subcomponents oninit function I had a call to m.redraw.

Turns out, if you do some 'heavy' work in your mounted component, and do a m.redraw in a subcomponent to it, mithril will initialize the maincomponent twice (also, it will be very confused about state and stuff)

I cut it down to this fiddle https://jsfiddle.net/v6tx4tLk/13/ so you can have a look.

While you should probably never have a m.redraw in an oninit function (can't think of a valid case for this right now at least), it's definitely something you can do by mistake. And this bug was really hard to track down

[dnErf]

i think m.redraw on init is okay because of xhr request.. unless mithril will have to put restriction on making an xhr request on init..

[hankeypancake]

I think m.redraw's from any callback seems to be fine. doing setTimeout(() => {m.redraw()}, 0) instead doesn't make the main component reinitialize.

I can really not think of any case where you'd want to call m.redraw directly in any oninit function, so this might not be a problem really. The only thing is that if you do it by mistake (like I did) it can take a long time to debug

[hankeypancake]

For me it was very confusing when in the end I brought out the axe and just removed huge parts of the code until I could narrow it down. Since it also depends on the current execution speed each time, it might happen but it might also be completely fine

[pygy]

The problem comes from the fact that m.redraw() triggers a synchronous repaint if more than 16 milliseconds elapsed since the last redraw call. Otherwise, it is scheduled for the next frame.

The "heavy" work causes the init/create phase to last longer than that, and the redraw starts during the previous init phase, wreaking havoc.

#1592 starts to address this, but more work is needed, as discussed there.

[dead-claudia]

To add to @pygy's last point, the current state of the discussion is documented in #1765, with several links to other issues.

[dead-claudia]

I just made a 100% repro for the initial bug:

• v1 (initializes twice): https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAGhAGMB7NYmBvEAXwvW10QICsEqdBk2J4hcYgAIAygFcARgGFaWAA70RkgLyTgAHTR7i9CGgjFEkgBQBKbQD5JWfACcYAExcYA7rYoGjADcIGG9LWwddVgNowzRnLFpZBit3WmpZHAZ8eVp3AE8KXQDjMzMLazstR300SUkjcVpYfChaAHMrAHJTcy6bA3r6wIwXSSZ3bUkAEQxGfDRaXzsAakkARgAGTcGh70JoGGtZ+cXlyQAecbR3O2BY+vZd4NDwqprdozdiWRc6rCsciUKnUaBEAzqklirBslBAcBgsGoxAg9AQPHW60Q6wArGwOCBMDg8PhqHABDR6IxmDw2ABdKhQUwAa3RqEJXDwWHMhBc0Dhv3IPBIxFUcEQAHoJclVMz2qSVBLucRedAAALrfCagBsSp5fKg+H4cOI+VU3Hh1D5qlErDprCAA
• v2 (initializes once): https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAGhAGMB7NYmBvEAXwvW10QICsEqdBk2J4hcYgAIAygFcARgGFaWAA70RkgLyTgAHTR7i9CGgjFEkgBQBKbQD5JWfACcYAExcYA7rYoGjADcIGG9LWwddVgNowzRnLFpZBit3WmpZHAZ8eVp3AE8KXQDjMzMLazstR300SUkjcVpYfChaAHMrAHJTcy6bA3r6wIwXSSZ3bUkAEQxGfDRaXzsAakkARgAGTcGh70JoGGtZ+cXlyQAecbR3O2BY+vZd4NDwqprdozdiWRc6rCsciUKnUaBEAzqklirBslBAcBgsGoxAg9AQPHWACZEJiAKxsDggTA4PD4ahwAQ0eiMZg8NgAXSoUFMAGt0agiVw8FhzIQXNAAAJggAeoiov3IPBIxFUcEQAHp5clVCz2mSVPKecQ+YLMfhNvqALQuaj4daa3n8qD4fhw4j5VTceHUfmqUSsemsIA

This is a race condition here: if I remove the delay, the bug disappears in v1.