Does Mithril 2.x Reset Component State When Key Changes Across Routes?

Yes, Mithril 2.x resets internal component state when the key changes.

When a component is rendered with a new key, the virtual DOM diffing algorithm treats the resulting node as a completely different entity rather than an update to an existing one. This forces Mithril to detach the old virtual node and mount a fresh instance, effectively wiping any state tied to the previous instance.

The Mechanism of State Reset

The reset occurs during the reconciliation process. When the diffing algorithm identifies a key change at the same position in the DOM tree, it triggers a full lifecycle replacement rather than a patch. The sequence is as follows:

• The existing component instance is destroyed, triggering onDestroy.
• A new component instance is initialized via oninit.
• The new node is mounted to the DOM, triggering oncreate.

Because the previous instance is discarded and eligible for garbage collection, any data stored in the component's closure or instance object is lost. This differs from Mithril 1.x, where components were often reused, potentially leading to state persistence across route transitions.

Practical Verification

To confirm this behavior in a Mithril 2.x environment, implement a component with local state and navigate between routes using different keys:

const Counter = {
  oninit: (vnode) => {
    vnode.state = { count: 0 };
  },
  view: (vnode) => {
    return m("div", [
      m("p", `Count: ${vnode.state.count}`),
      m("button", { onclick: () => vnode.state.count++ }, "Add")
    ]);
  }
};

// Route config
m.route(document.body, "", {
  "/user/1": () => m(Counter, { key: "user-1" }),
  "/user/2": () => m(Counter, { key: "user-2" })
});

If you increment the counter on /user/1 and navigate to /user/2, the count will reset to 0.

Assumptions and Scope

This behavior applies specifically to component-local state. If state is stored in a global object, an external store, or a shared service, it will persist across key changes because those objects exist outside the Mithril component lifecycle. We assume the use of standard Mithril 2.x reconciliation logic.