Recursive time loop bug

[barneycarroll]

As seen in this fiddle (which goes into a crazy tailspin as soon as any redraw is triggered — which looks like a Mithril key bug), superConfig can end up calling a superConfig. I would have thought this was impossible without processing views multiple times by saving the virtual DOM tree and reprocessing it in a subsequent view.

Things to test:

• [ ] Is one component directly invoking another component as its immediate root? This could lead to duplicate superConfigs but not, one would think, a multiply recursive one this deep…
• [ ] How easy / reliable / efficient could it be to check whether the component root was already registered / its config already bound?

[barneycarroll]

It's pretty grim:

[barneycarroll]

OK, progress: the saved snapshots are not static, meaning that during what should be a reversal to a historical computed view's virtual DOM output snapshot, we are in fact invoking dynamic components.

Need to ensure the view output is totally computed before saving.

[barneycarroll]

Gonna try proxying m.render and split the history logic between that and the root view trap.

I think the only reason trapped views are consuming trapped views is because of re-execution on historical patch, which would explain the infinite recursion on patch when the component is deemed missing again, and another trap consumes the previous recursive trap, ad infinitum.

[barneycarroll]

Better idea: config exposes the computed virtual DOM at render time. Use that — if root superConfig is already an essential hook for binding live DOM then it should also be used to capture snapshots.

[barneycarroll]

Patch works, but Mithril's key implementation still seems screwy.

[barneycarroll]

Fixed in c7c9b94, released in v1.1.2