Nuclear Powered Marshmallows
    TypeScript icon, indicating that this package has built-in type declarations

    5.1.8 • Public • Published


    npm version npm downloads Twitter Follow

    This project is part of the monorepo.


    Mutable wrappers for nested immutable values with optional undo/redo history and transaction support.

    Additional support for:

    • type checked value access for up to 8 levels of nesting (deeper values default to any)
    • watches (listeners)
    • derived, eager/lazy view subscriptions (w/ optional transformation)
    • cursors (direct R/W access to nested values)
    • transacted updates (incl. nested transactions)
    • undo/redo history

    Together, these types act as building blocks for various application state handling patterns, specifically aimed (though not exclusively) at the concept of using a centralized atom around a nested, immutable object as single source of truth within an application and driving reactive updates from performed state changes.


    STABLE - used in production

    Search or submit any issues for this package

    Temporary restrictions

    Due to a change of inferencing rules in TypeScript 4.3 with regards to tuples, the IReset and ISwap interface definitions in this package had to be updated and removed support for lookup path lengths > 6. This change is expected to be temporary only and is tracked by #303.

    Breaking changes


    Type checked accessors

    The resetIn() and swapIn() methods are fully type checked (up to 8 levels deep), with the given value paths (and the new state value) being validated against the structure of the containers's main value type. Since that kind of type checking can only be done via tuples, string paths are NOT supported anymore and instead require using the resetInUnsafe() and swapInUnsafe() methods, which now provide the legacy, unchecked update functionality. More details below.

    The use of the Unsafe suffix is inspired by Rust and, for consistency, now used across other umbrella packages providing both checked and unchecked variations.

    Factory functions

    Users are encouraged to use the new set of (type checked) factory functions in lieu of direct constructor invocations. These functions are now considered the defacto way to create new instances are generally starting to be provided more consistently across the umbrella ecosystem. All of them use the def prefix, e.g. defAtom(), defCursor() etc. Unsafe versions exist for some types too. More info


    Derived views can now only be created via defView(), defViewUnsafe() (or new View()). The IViewable interface and .addView() methods have been removed.

    Related packages

    • - Interceptor based event bus, side effect & immutable state handling
    • - Immutable, optimized and optionally typed path-based object property / array accessors with structural sharing
    • - Reactive streams & subscription primitives for constructing dataflow graphs / pipelines


    yarn add

    ES module import:

    <script type="module" src=""></script>

    Skypack documentation

    For Node.js REPL:

    # with flag only for < v16
    node --experimental-repl-await
    > const atom = await import("");

    Package sizes (gzipped, pre-treeshake): ESM: 1.91 KB


    Usage examples

    Several demos in this repo's /examples directory are using this package.

    A selection:

    Screenshot Description Live demo Source
    BMI calculator in a devcards format Demo Source
    Interactive inverse FFT toy synth Demo Source
    Custom dropdown UI component for hdom Demo Source
    Custom dropdown UI component w/ fuzzy search Demo Source
    Using custom hdom context for dynamic UI theming Demo Source
    Hiccup / hdom DOM hydration example Demo Source
    Canvas based Immediate Mode GUI components Demo Source
    Basic SPA example with atom-based UI router Demo Source
    rdom powered SVG graph with draggable nodes Demo Source
    Animated Voronoi diagram, cubic splines & SVG download Demo Source
    Complete mini SPA app w/ router & async content loading Demo Source
    Minimal rstream dataflow graph Demo Source
    Interactive grid generator, SVG generation & export, undo/redo support Demo Source
    rstream based spreadsheet w/ S-expression formula DSL Demo Source
    Additive waveform synthesis & SVG visualization with undo/redo Demo Source
    Obligatory to-do list example with undo/redo Demo Source
    Triple store query results & sortable table Demo Source


    Generated API docs


    An Atom is a mutable (typed) wrapper for supposedly immutable values. The wrapped value can be obtained via deref(), replaced via reset() and updated using swap(). An atom too supports the concept of watches, essentially onchange event handlers which are called from reset / swap and receive both the old and new atom values.

    Note: The IDeref interface is widely supported across many packages and implemented by most value wrapper types.

    import { defAtom } from "";
    const a = defAtom(23);
    // obtain value via deref()
    // 23
    // add watch to observe value changes
    a.addWatch("foo", (id, prev, curr) => console.log(`${id}: ${prev} -> ${curr}`));
    // true
    // example update function
    const add = (x, y) => x + y;
    // apply given function to current value
    // (incl. any additional arguments passed to swap)
    // this is the same as:
    // a.reset(adder(a.deref(), 1))
    a.swap(add, 1);
    // foo: 23 -> 24
    // reset atom's value
    // foo: 24 -> 42

    When Atom-like containers are used to wrap nested object values, the resetIn() / swapIn() methods can be used to directly update nested values. These updates are handled via immutable setters provided by

    const db = defAtom({ a: { b: 1, c: 2 } });
    // type checked access
    db.resetIn(["a", "b"], 100);
    // { a: { b: 100, c: 2 } }
    // unchecked access
    db.resetInUnsafe("a.b", 100);
    // { a: { b: 100, c: 2 } }
    // type checked access
    // type of `x` in update function is automatically inferred too
    db.swapIn(["a", "c"], (x) => x + 1);
    // { a: { b: 100, c: 3 } }
    // unchecked access
    db.swapInUnsafe("a.c", (x) => x + 1);
    // { a: { b: 100, c: 4 } }

    If the update path is created dynamically, you will have to use one of these approaches:

    interface Item {
        name: string;
    const db = defAtom<Item[]>([{ name: "" }, { name: "atom" }]);
    const id = 1;
    // using <const> expr
    db.resetIn(<const>[id, "name"], "umbrella");
    // unchecked
    db.resetInUnsafe([id, "name"], "umbrella");
    // unchecked (string path)
    db.resetInUnsafe(`${id}.name`, "umbrella");

    Transacted updates

    Since v3.1.0, multiple sequential state updates can be grouped in transactions and then applied in one go (or canceled altogether). This can be useful to produce a clean(er) sequence of undo snapshots (see further below) and avoids multiple / obsolete invocations of watches caused by each interim state update. Using a transaction, the parent state is only updated once and watches too are only notified once after each commit.

    Transactions can also be canceled, thus not impacting the parent state at all.

    Transacted can wrap any existing IAtom implementation, e.g. Atom, Cursor or History instances. Transacted also implements IAtom itself...

    const db = defAtom<any>({ a: 1, b: 2 });
    const tx = defTransacted(db);
    // start transaction
    // alternatively use syntax sugar for:
    // `defTransacted(db).begin()`
    tx = beginTransaction(db);
    // perform multiple updates
    // (none of them are applied to the parent state
    // until `commit` is called)
    // IMPORTANT: calling any of these update methods without
    // a running transaction will throw an error!
    tx.resetIn(["a"], 11);
    tx.resetIn(["c"], 33);
    // tx.deref() will always return latest state
    // { a: 11, b: 2, c: 33 }
    // however, at this point the parent
    // still contains pre-transaction state...
    // { a: 1, b: 2 }
    // apply all changes at once (or `cancel()` transaction)
    // { a: 11, b: 2, c: 33 }
    // verify parent state
    // { a: 11, b: 2, c: 33 }

    Nested transactions

    Nested transactions on a single Transacted instance are not supported and attempting to do so will throw an error. However, nested transactions can be achieved by wrapping another Transacted container.

    const tx1 = beginTransaction(db);
    tx1.resetIn(["a"], 10);
    // nested transaction
    const tx2 = beginTransaction(tx1);
    tx2.resetIn(["b"], 20);
    // { a: 10, b: 20 }

    External modifications during active transaction

    An error will be thrown if the parent change receives any updates whilst a transaction is active. This is to guarantee general data integrity and to signal race conditions due to erroneous / out-of-phase state update logic.

    const tx = beginTransaction(db);
    tx.resetIn(["a"], 10);
    // attempting to update parent will throw an error
    db.resetIn(["a"], 2);


    Cursors provide direct & immutable access to a nested value within a structured atom. The path to the desired value must be provided when the cursor is created and cannot be changed later. Since v4.0.0, the path itself is type checked and MUST be compatible with the type of the parent state (or use defCursorUnsafe() as fallback, see breaking changes). The path is then compiled into a getter and setter to allow cursors to be used like atoms and update the parent state in an immutable manner (i.e. producing an optimized copy with structural sharing of the original (as much as possible)) - see further details below.

    It's important to remember that cursors also cause their parent state (atom or another cursor) to reflect their updated local state. I.e. any change to a cursor's value propagates up the hierarchy of parent states and also triggers any watches attached to the parent.

    a = defAtom({a: {b: {c: 1}}})
    // cursor to `b` value
    b = defCursor(a, "a.b")
    // cursor to `c` value, relative to `b`
    c = defCursor(b, "c")
    // { c: 2 }
    // { a: { b: { c: 2 } } }

    For that reason, it's recommended to design the overall data layout rather wide than deep (my personal limit is 3-4 levels) to minimize the length of the propagation chain and maximize structural sharing.

    // main state
    main = defAtom({ a: { b: { c: 23 }, d: { e: 42 } }, f: 66 });
    // cursor to `c` value
    cursor = defCursor(main, ["a", "b", "c"]);
    // or
    cursor = defCursorUnsafe<number>(main, "a.b.c");
    // add watch just as with Atom
    cursor.addWatch("foo", console.log);
    // 23
    cursor.swap(x => x + 1);
    // foo 23 24
    // { a: { b: { c: 24 }, d: { e: 42 } }, f: 66 }

    Derived views

    Whereas cursors provide read/write access to nested key paths within a state atom, there are many situations when one only requires read access and the ability to (optionally) produce transformed versions of such a value. The View type provides exactly this functionality:

    db = defAtom({ a: 1, b: { c: 2 } });
    // create a view for a's value
    viewA = defView(db, ["a"]);
    // create a view for c's value w/ transformer
    viewC = defView(db, ["b","c"], (x) => x * 10);
    // or unchecked
    viewC = defViewUnsafe(db, "b.c", (x) => x * 10);
    // 1
    // 20
    // update the atom
    db.resetIn(["b","c"], 3)
    // views can indicate if their value has changed
    // (will be reset to `false` after each deref)
    // here viewA hasn't changed (we only updated `c`)
    // false
    // true
    // the transformer function is only executed once per value change
    // 30
    // just returns current cached transformed value
    // 30
    // discard views

    Since v1.1.0 views can also be configured to be eager, instead of the "lazy" default behavior. If the optional lazy arg is true (default), the view's transformer will only be executed with the first deref() after each value change. If lazy is false, the transformer function will be executed immediately after a value change occurred and so can be used like a selective watch which only triggers if there was an actual value change (in contrast to normal watches, which execute with each update, regardless of value change).

    Related, the actual value change predicate can be customized. If not given, the default will be used.

    let x = 0;
    let a = defAtom({ value: 1 })
    // create an eager view by passing `false` as last arg
    view = defView(a, ["value"], (y) => (x = y, y * 10), false);
    // check `x` to verify that transformer already has run
    x === 1
    // true
    // reset x
    x = 0
    // verify transformed value
    view.deref() === 10
    // true
    // verify transformer hasn't rerun because of deref()
    x === 0
    // true

    Atoms & views are useful tools for keeping state outside UI components. Here's an example of a tiny web app, demonstrating how to use derived views to switch the UI for different application states / modules.

    Note: The constrained nature of this next example doesn't really do justice to the powerful nature of the approach. Also stylistically, in a larger app we'd want to avoid the use of global variables (apart from db) as done here...

    For a more advanced / realworld usage pattern, check the related event handling package and bundled examples.

    This example is also available in standalone form:

    Source | Live demo

    import type { Nullable, Path } from "";
    import { defAtom, defView } from "";
    import { start } from "";
    import { capitalize } from "";
    interface State {
        state: string;
        error?: string;
        user: {
            name?: string;
    // central immutable app state
    const db = defAtom<State>({ state: "login", user: {} });
    // define views for different state values
    const appState = defView(db, ["state"]);
    // the error view converts the state value into a UI component array
    const error = defView(db, ["error"], (error) =>
        error ? ["div.error", error] : null
    // view transformer for the username value
    const user = defView(db, ["user", "name"], (name) =>
        name ? capitalize(name) : null
    // state update functions
    // trigger new route / UI view
    const setState = (s: string) => setValue(appState.path, s);
    const setError = (err: Nullable<string>) => setValue(error.path, err);
    const setUser = (e: Event) => setValue(user.path, (<any>;
    const setValue = (path: Path, val: any) => db.resetInUnsafe(path, val);
    const loginUser = () => {
        if (user.deref() === "admin") {
        } else {
            setError("sorry, wrong username (try 'admin')");
    const logoutUser = () => {
        setValue(user.path, null);
    // UI components for different app states
    // note how the value views are used here
    const uiViews: any = {
        // dummy login form
        login: () => [
            ["h1", "Login"],
            // embedded error view (will auto-deref)
            ["input", { type: "text", onchange: setUser }],
            ["button", { onclick: loginUser }, "Login"],
        logout: () => [
            ["h1", "Good bye"],
            "You've been logged out. ",
            ["a", { href: "#", onclick: () => setState("login") }, "Log back in?"],
        main: () => [
            ["h1", `Welcome, ${user.deref()}!`],
            ["div", "Current app state:"],
                    { cols: 40, rows: 10 },
                    JSON.stringify(db.deref(), null, 2),
            ["button", { onclick: logoutUser }, "Logout"],
    // finally define another derived view for the app state value
    // including a transformer, which maps the current app state value
    // to its correct UI component (incl. a fallback for illegal app states)
    const currView = defView(
        (state) => uiViews[state] || ["div", ["h1", `No component for state: ${state}`]]
    // app root component
    // embedded view (will auto-deref)
    start(() => ["div", currView]);

    Undo / Redo history

    The History type can be used with & behaves just like an Atom or Cursor, but too creates snapshots of the current state before applying the new state. These snapshots are stored in a doubly-linked list and can be navigated via .undo() / .redo(). Each time one of these methods is called, the parent state will be updated and any attached watches are notified. By default, the history has length of 100 steps, though this is configurable via ctor args.

    // create history w/ max. 100 steps
    db = defHistory(defAtom({ a: 1 }), 100)
    // { a: 1 }
    db.reset({ a: 2, b: 3 })
    db.reset({ b: 4 })
    // { a: 2, b: 3 }
    // { a: 1 }
    // undefined (no more undo possible)
    // false
    // { a: 2, b: 3 }
    // { b: 4 }
    // undefined (no more redo possible)
    // false


    Karsten Schmidt

    If this project contributes to an academic publication, please cite it as:

      title = "",
      author = "Karsten Schmidt",
      note = "",
      year = 2017


    © 2017 - 2022 Karsten Schmidt // Apache Software License 2.0


    npm i

    DownloadsWeekly Downloads






    Unpacked Size

    112 kB

    Total Files


    Last publish