Elm’s vdom diffing considers a node created via lazy different than a node created without lazy, even if the results are equivalent. In compiled Elm output, in the vdom diffing code, are the comments:
// Bail if you run into different types of nodes. Implies that the
// structure has changed significantly and it's not worth a diff.
“not worth a diff” means nodes will be deleted and recreated (even if they would be equivalent). This can cause surprising performance and UX problems if one uses lazy conditionally.
Here’s an example of an input that loses focus when it switches between lazy/non-lazy rendering.
Html.Lazy.lazy and Html.map create virtual DOM nodes (yes, they do create nodes, not just modify existing ones!), and the vdom library diffs trees of virtual DOM nodes. But as a user of the package, I tend to think about the real DOM tree: I think there’s a 1:1 mapping between virtual DOM nodes and real DOM nodes, but as you’ve discovered the virtual DOM tree can contain more nodes, which is surprising.
Glad to hear you managed to figure it out. It certainly is surprising that lazy would cause nodes to be recreated in a situation where not using lazy would not!
For your particular application, can you just leave the lazy out? Or move down into to other parts of the view code where it will not upset your inputs?
Btw, the generalization of this is: Elm’s vdom diffing considers a nodes of different types not to be equal, without doing any extra smart things to see if the results would be equivalent.
The vdom compares the parent nodes and sees that NODE !== THUNK and bails. I don’t think that’s a bug – it sounds like maybe you are requesting smarter diffing.
Have you done anything with this in elm-safe-virtual-dom? It strikes me that there are definitely some improvements could be made for both lazy and keyed.
lazy is documented as an optimization. It is implied that we’ll always get the same result, but perhaps faster. Yet, here is a case where using lazy breaks the end user’s experience.
If this was clearly documented, we could call it a caveat. In this case, I’d say bug, insofar as it is unexpected and breaks things for the end user. It took me a few days to track down this undesired behaviour and I had to post-process my compiled elm to log diffing/patching to figure out what was happening. Whether or not to document this, “fix” it, or sweep it under the rug is another issue (not mine). Or perhaps the compiler could warn if an expression returns lazy and non-lazy nodes?
If you have the time, please create a GitHub Issue on the elm/virtual-dom package, with your code from the Ellie. I know it seems kind of pointless but a future me that finds time to continue with elm-janitor would definitely find it helpful to have this documented there.