Persistent Component State Across DOM Reparenting in Mithril.js

glutio — Wed, 24 Sep 2025 07:54:45 +0000

When building complex UIs with dockable panels, modal dialogs, or drag-and-drop interfaces, you often need to move components between different DOM parents. In Mithril.js, this creates a problem: moving a component to a different parent destroys the component instance and loses all local state, even when using the same key.

The Problem

// Before: component in sidebar
m('div.sidebar', [
    m(MyComponent, { key: 'editor-1' })  // Has local state
]);

// After: component moved to floating window
m('div.floating-window', [
    m(MyComponent, { key: 'editor-1' })  // NEW instance, lost state!
]);

Even with identical keys, Mithril treats this as component removal + creation because the parent changed. The key attribute only helps with reordering within the same parent.

The Solution: Reference-Counted State Store

The key insight is that during reparenting, both the old and new component instances with the same key briefly exist simultaneously. We can use this overlap to detect reparenting vs. true removal.

How It Works

During reparenting (same key, different parent):

Old component instance exists → refCount = 1
New component instance created with same key → refCount = 2
Old component instance removed → refCount = 1, state preserved
New component instance continues with restored state

During true removal:

Component instance exists → refCount = 1
Component instance removed, no replacement → refCount = 0, state cleaned up

Example: Persistent Counter

class Counter {
    static stateStore = new Map();

    oninit(vnode) {
        const key = vnode.key;

        // Get or create state entry
        let entry = Counter.stateStore.get(key);
        if (!entry) {
            entry = { 
                refCount: 0, 
                state: { count: 0 }
            };
            Counter.stateStore.set(key, entry);
        }

        entry.refCount++;
        this.persistentState = entry.state;
    }

    onbeforeremove(vnode) {
        const key = vnode.key;
        const entry = Counter.stateStore.get(key);

        if (entry) {
            entry.refCount--;
            if (entry.refCount === 0) {
                Counter.stateStore.delete(key);
            }
        }
    }

    view() {
        return m('div', [
            m('p', `Count: ${this.persistentState.count}`),
            m('button', { 
                onclick: () => this.persistentState.count++ 
            }, 'Increment')
        ]);
    }
}

// Usage - counter value survives reparenting between different containers
m(Counter, { key: 'my-counter' });

Benefits

Automatic: Works with existing key attributes
Memory Safe: Reference counting prevents leaks
Framework Native: Uses only Mithril's lifecycle hooks
Simple: Just add the pattern to any component that needs it

Conclusion

This pattern fills a gap in Mithril's component lifecycle, enabling sophisticated UI behaviors like undockable panels and persistent modal dialogs. The reference counting approach is elegant because it leverages Mithril's own timing - the brief moment when both the old vnode and the new vnode exist during reparenting becomes our signal to preserve state.

IoC Dependency Injection in TypeScript Without Libraries

glutio — Fri, 21 Feb 2025 06:54:00 +0000

Hi All,

I wanted to use the IoC Dependency Injection (DI) pattern on a little project I am working on in TypeScript, and I did not want to use any libraries, just plain TypeScript. I came up with this pattern below, which is not ideal, but gets close to a proper IoC DI paradigm I think.

For the sake of the explanation, let's assume we have two interfaces IFoo and IBar and the corresponding implementations CFoo and CBar. We also have CApp as the main class. Let's assume CApp depends on IFoo and CFoo depends on IBar. We want to recursively instantiate all dependencies starting from the CApp class. Below is what the ideal syntax would look like:

interface IBar {
  bar();
}

interface IFoo {
  foo();
}

class CBar implements IBar {
  bar() {
    console.log("Hello, world");
  }
}

class CFoo implements IFoo {
  bar: IBar;
  constructor(bar: IBar) {
    this.bar = bar;
  }  
  foo() { 
    this.bar.bar();
  }
}

class CApp {
  foo: IFoo;
  constructor(foo: IFoo) {
    this.foo = foo;
  }
}

const app = ioc.resolve(CApp);

Unfortunately, this exact syntax is not possible, because IFoo and IBar types do not exist at runtime. My alternative is to use a kind of type ID with syntactic sugar.

interface IBar {
  bar();
}
const IBar = {} as IBar; // type ID

class CFoo implements IFoo {
  static CFoo = { // static object
    bar: IBar // bar is assigned the value of `const IBar`
  };

  bar: IBar;
  constructor(deps: typeof CFoo.CFoo) {
    this.bar = deps.bar;
  }
}

What we did here is we declared a type ID constant with the same name as the type. The constant is a reference to some unique object cast to the type it represents. In the class where dependencies are to be injected, we declared a static object of the same name as the class, so we can dynamically look it up. The object's declaration colon (:) syntax conveniently makes it look like a type, while in reality, this is an assignment of the type ID value. This static object is essentially a mini reflection metadata without a reflection library. We can use typeof to infer the type of the object that TypeScript will enforce when you call the constructor.

With this setup, the IoC container looks like this:

class IoC {
  di = new Map<object, Function>();    

  constructor() {
    this.di.set(IFoo, () => this.resolve(CFoo));
    this.di.set(IBar, () => this.resolve(CBar));
  }

  resolve<T>(ctor: new (arg?: {}) => T): T {
    const className = ctor.name;
    const deps = (ctor as any)[className];

    if (deps) {
      const resolvedDeps = Object.fromEntries(
        Object.entries(deps).map(
          ([key, typeId]) => [key, this.di.get(typeId as object)()]
        )
      );
      return new ctor(resolvedDeps);
    }        

    return new ctor();
  }
}

const ioc = new IoC();

The dependency resolvers are defined directly in the constructor of the IoC. The resolve<T>() method takes a class as an argument, determines the name of the static property which lists the dependencies, and resolves them by calling the factory function in the resolvers map. The factory function, in turn, recursively resolves its own type, in case it also has dependencies.

With this syntax in place, and the implementation of the IoC container, all you need to do to bootstrap your app is

const app = ioc.resolve(CApp);

Happy coding!

Forem: glutio