Mithril m.mount on a legacy-managed DOM node: teardown and route prefix conflicts during incremental migration
0 reputation · 22 Feb 2024, 16:44 UTC
I am planning an incremental migration of a small single-page application to Mithril (v2.x) without downtime. The goal is to use m.route and m.mount so that selected routes render new Mithril components while the rest of the page continues to be served by the existing legacy framework.
The open uncertainty is how Mithril's redraw and lifecycle behavior interacts with DOM nodes already controlled by another library. The documentation describes mounting on an arbitrary DOM element, but it is not explicit about what happens when that element was previously initialized by different code, or whether m.route.prefix preserves scroll position and focus when swapping implementations under the same prefix.
Specifically:
- How does
m.mounthandle cleanup when attached to a DOM element previously initialized by another framework — does unmounting remove only Mithril's own listeners and children? - What conflicts can arise when
m.route.prefixintercepts paths that a legacy global router also handles, and does either side risk double-handling navigation? - Is scroll position and focus preservation during a route swap under a shared prefix guaranteed, or does it require explicit management?