Because it's better in many ways. Faster. And fixes a bug related to delayed onremoves which is quite likely the same bug as observed with @hyperapp/transitions since hyperapp v 1.2.6
Obviously we want the new and improved VDOM in HAV2 as well, but it would be worth much to many, to have in HAV1 also.
There are likely many who, for various reasons, would like to stay on HAV1 for a while yet. For them the better vdom would be a great boon as well. Also, if they use transitions it means they don't have to stop at v1.2.5.
@zaceno The new VDOM includes several breaking changes. What should be the policy to merge it back to 1.x? There can't be two 2.x.
@jorgebucaran Good question. I know it breaks semver, but we've done it before already, so I think we should go with a v 1.3.0 for the breaking changes.
To clarify (from a discussion we had on Slack): the things that will break are:
Lazy components should not go away in V1, but it is easy to add them after applying new diff algorithm.
I should've planned lazy components more carefully. I admit they're after a good cause, but they're not without gotchas. I'd love to remove them, but it's going to be a breaking change.
Considering that this is a "post-mortem" feature request and my focus should be V2 right now, I am willing to publish a 1.3.0 or 1.9.0? if we really want the new VDOM in V1, but I can't allocate much time to it and if the trade-off is too much trouble, then let's better hold on this until after V2 is out or later.
Lazy components have been getting a lot of bad press in various comments on here and in slack recently. I am curious, what are the gotchas and why are they so detrimental?
@lukejacksonn This question deserves a better answer, but for now see https://github.com/hyperapp/router/issues/66.
I guess you mean specifically this https://github.com/hyperapp/router/issues/66#issuecomment-381058516 with in summary, they cause complications and there is not as much need for them now as you only need to worry about passing down state.
@lukejacksonn Yes, and also https://github.com/hyperapp/hyperapp/pull/636.
The problem is that lazy components can return null or undefined and it's difficult to discard those nulls from the old and new vnode trees when patching. We could extract them from the vnode's children array by copying them over to a new array when we switch to a map-based lookup keyed-reconciliation in the diff algo, and then swap the two arrays. This shouldn't be a _significant_ perf hit since we're iterating every child already, but it's extra work. The problem with this AFAICS is it (I think) could interfere with the V2 lazy lists feature.
@jorgebucaran The problem with this AFAICS is it (I think) could interfere with the V2 lazy lists feature.
Good thing that feature was never shipped in HAv1, so no one should miss it. 馃檭
@okwolf Good point. Unfortunately, it should affect any form of memoization as we'd be mutating vnodes. But maybe I'm wrong.
Lazy components are good as far as I am concerned.
From my perspective at least, the new algorithm at the expense of lazy components is pretty problematic. It鈥檒l force anything using lazy components to be rewritten (which isn鈥檛 necessarily easy given the flexibility they impart). Introducing that change would also mean that any more innocuous changes to v1 wouldn鈥檛 be able to be adopted.
Don鈥檛 get me wrong, I鈥檇 love to see the bugs in the v1 VDOM fixed, but doing forcing the removal of lazy components seems rough to me.
@makenosound Even if Hyperapp stops supporting "lazy components" built in, it's quite possible (relatively easy, even) to add them back as a HOA.
Rather than resolving nodes as we do during the patching now, the HOA does a pass over the vdom to resolve nodes before even returning it in the view.
So we can still have both!
Ten months and I still haven't ported the new VDOM to V1. I'd like this too, if only for good time's sake, but as I said before, my focus should be V2. After releasing V2, my focus will likely be V2 still or whatever I'm doing next. I don't think this will be happening any time soon, but maybe someday. 馃憢
Most helpful comment
@makenosound Even if Hyperapp stops supporting "lazy components" built in, it's quite possible (relatively easy, even) to add them back as a HOA.
Rather than resolving nodes as we do during the patching now, the HOA does a pass over the vdom to resolve nodes before even returning it in the view.
So we can still have both!