search

barneycarroll / mithril-machine-tools

Putting the hype back in hyperscript, the OM back in virtual DOM; A bag of tricks for Mithril.
MIT License
30 stars 3 forks source link

(Island) Using `m.render` on intervening DOM nodes is overly complicated and redundant #8

Closed barneycarroll closed 3 years ago

barneycarroll commented 6 years ago

Because of nested fragments, components immediately returning components, etc, etc, Island needs to account for the fact that its nearest DOM-matched ancestor may be several vnodes away. We cater for this by creating a clone of the 'host' vnode entity and creating a hot path down to the recomputed Island view.

But seeing as we have to tunnel through any number of intervening vnodes anyway, would we be better off avoiding the intermediate host entity and simply rendering the patched structure to the original root?

barneycarroll commented 6 years ago

Yes we would. Internal logic would be simplified.

barneycarroll commented 6 years ago

Immediate ancestor components without discrete DOM artefacts bork the current mechanism because the render directive will cause their views to be re-computed, breaking the isolation contract.

barneycarroll commented 6 years ago

☝ fixed in 6f1aeaf6.

The next blocker is a problem whereby Mithril attempts to patch values onto undefined DOM nodes.

Why doesn't Mithril update the instance vtree with DOM references during the localised render? I would expect this to have 'just worked'.

Is it an issue to do with Patchinko overwriting defined values in the target with undefined values in a patch? It shouldn't - we're not patching the instance itself…

barneycarroll commented 3 years ago

This is all obviated by Mobile