DEV Community: Patrick G

Proposed API Reference

Patrick G — Mon, 20 Jul 2026 19:23:22 +0000

This appendix defines the concrete API surface and observable semantics of the explicit reactive-dependency proposal.

The API is intentionally low-level. It provides invalidation sources, lazy cached derivations, synchronous notification, deterministic disposal, notification batching, opt-in equality cutoff, and revision-based cache validation. It does not provide writable value cells, ambient dependency tracking, effects, scheduling policy, ownership, or asynchronous computation semantics.

API overview

The proposal introduces a global Reactive namespace with the following functions:

Reactive.createSource(options)
Reactive.derive(dependencies, compute, options)
Reactive.deriveDynamic(selectionDependencies, resolveDependencies, compute, options)
Reactive.batch(callback)
Reactive.revision()
Reactive.inspect(target)

The factories produce two kinds of built-in objects:

Object	Purpose
Source	A valueless announcement that associated state may have changed
Derivation	A lazy cached computation over explicit dependencies

Both objects implement the Dependency protocol through onInvalidate(), and both additionally implement the optional revision extension through revision().

Informative TypeScript declarations

declare namespace Reactive {
  type Unsubscribe = () => void;
  type Revision = number;

  interface Dependency {
    onInvalidate(listener: () => void): Unsubscribe;

    /**
     * Optional revision extension. See "The revision extension".
     */
    revision?(): Revision;
  }

  interface SourceOptions {
    name?: string;
  }

  interface Source extends Dependency {
    invalidate(): void;
    revision(): Revision;
    [Symbol.dispose](): void;
  }

  interface DerivationOptions<T> {
    name?: string;

    /**
     * Opt-in equality cutoff. Never called with thrown values.
     */
    equals?: (previous: T, next: T) => boolean;
  }

  interface Derivation<T> extends Dependency {
    get(): T;
    invalidate(): void;
    revision(): Revision;
    [Symbol.dispose](): void;
  }

  function createSource(options?: SourceOptions): Source;

  function derive<
    const D extends readonly Dependency[],
    T,
  >(
    dependencies: D,
    compute: (dependencies: D) => T,
    options?: DerivationOptions<T>,
  ): Derivation<T>;

  function deriveDynamic<
    const S extends readonly Dependency[],
    const D extends readonly Dependency[],
    T,
  >(
    selectionDependencies: S,
    resolveDependencies: (
      selectionDependencies: S,
    ) => D,
    compute: (dependencies: D) => T,
    options?: DerivationOptions<T>,
  ): Derivation<T>;

  function batch<T>(callback: () => T): T;

  function revision(): Revision;

  interface InspectionRecord {
    kind: "source" | "derivation";
    name: string | undefined;
    state:
      | "unevaluated"
      | "computing"
      | "clean"
      | "stale"
      | "disposed";
    watched: boolean;
    revision: Revision;
    dependencies: Dependency[] | undefined;
  }

  function inspect(
    target: Source | Derivation<unknown>,
  ): InspectionRecord;
}

These declarations are informative. ECMAScript does not expose the generic types.

Terminology

Dependency

A Dependency is an object with a callable onInvalidate method that follows the contract defined below.

A dependency does not need to contain a readable value. It represents the capability to announce that associated state may have changed.

Invalidation

An invalidation means "this dependency may have changed." It does not imply that an observable value is different.

Invalidation is conservative by default. A derivation constructed without an equals option performs no value comparison. A derivation constructed with equals participates in equality cutoff as described under "Value revisions and equality cutoff".

Completion

A derivation caches a JavaScript completion produced by its compute callback:

a normal completion, containing a returned value; or
an abrupt completion, containing a thrown JavaScript value.

Both forms are memoized.

Notification callback

A callback registered with onInvalidate() is a notification callback. It is a wake-up or scheduling hook, not an effect and not a stable-snapshot callback.

The revision clock

Each agent maintains a single monotonically increasing revision clock. The clock advances by at least one immediately before any built-in source or derivation dispatches invalidation to its listeners, and immediately before any manual or upstream invalidation transitions a derivation from clean to stale.

Reactive.revision() returns the current clock value. Revision values are primitive numbers, are totally ordered within an agent, and have no meaning across agents.

Every built-in source and derivation records the clock value at which it last invalidated. This enables cache validation by integer comparison, without requiring a subscription (see "Watched and unwatched derivations").

Informative note: implementations should ensure the clock cannot plausibly exhaust safe-integer range during a program's lifetime; a program invalidating one million times per second would take longer than 285 years to do so.

Value revision

Each derivation additionally records a value revision: the clock value at which its cached completion last changed. A reevaluation that produces an equal result (per the derivation's equals option) does not advance the derivation's value revision. Derivation.prototype.revision() returns the value revision.

For a source, revision() returns the clock value of its most recent invalidation, or 0 if it has never invalidated.

Watched

A source or derivation is watched while it has at least one active notification subscription. Subscriptions created internally by downstream derivations count. Watchedness determines whether a derivation maintains upstream subscriptions (see "Watched and unwatched derivations").

The Dependency protocol

A conforming dependency provides:

const unsubscribe =
  dependency.onInvalidate(listener);

listener must be callable. Otherwise, onInvalidate() throws a TypeError.

A conforming implementation must satisfy the following rules:

Registering a listener does not invoke it.
Each registration creates an independent subscription.
Registering the same function more than once creates multiple subscriptions.
The returned unsubscribe function is callable and idempotent.
Calling the unsubscribe function after removal is a no-op.
Unsubscribing does not invoke the listener.
Invalidation listeners are invoked synchronously, except as deferred by an active batch (see "Reactive.batch()").
Listeners receive no arguments; their return values are ignored.
If the dependency permanently disables future subscriptions, it issues one final invalidation before discarding existing subscriptions.
Listener mutation, re-entrancy, and failure follow the dispatch rules below.

User-defined dependencies should generally delegate their listener storage and dispatch to a built-in Source. This guarantees the notification restrictions, dispatch behavior, and batching integration required by this proposal, and provides the revision extension automatically.

The revision extension

A dependency may additionally expose:

const rev = dependency.revision();

returning the clock value at which the dependency most recently invalidated, or 0 if it has never invalidated. Built-in sources and derivations implement this method. A user-defined dependency that delegates to an internal Source can implement it by forwarding to that source.

The extension is optional. A dependency lacking revision() is fully conforming; derivations that depend on it simply cannot validate its cache state without a subscription, and fall back to subscription retention as described under "Watched and unwatched derivations".

Notification dispatch

Built-in sources and derivations use the same dispatch rules.

Snapshot semantics

At the beginning of each dispatch pass, the notifier records the subscriptions that are currently active.

During that pass:

a listener added during dispatch is not invoked;
a listener removed before its turn is skipped;
removing one subscription does not affect another registration of the same callback;
listeners are considered in registration order.

Re-entrancy

A recursive invalidation of the same built-in notifier is queued rather than dispatched recursively.

Queued dispatches are drained synchronously before the outermost invalidation, disposal, or batch-flush operation returns.

Each call to Source.prototype.invalidate() outside a batch represents a distinct source invalidation. Queued source invalidations outside a batch are not deduplicated.

A derivation deduplicates stale propagation: after it has become stale, additional invalidations do not notify its downstream listeners again until it successfully becomes clean.

Notification restrictions

While a built-in source or derivation is invoking a public notification callback, user code must not synchronously read from or mutate the built-in reactive graph.

The following operations throw a TypeError during such a callback:

derivation.get();
source.invalidate();
derivation.invalidate();
source.onInvalidate();
derivation.onInvalidate();
source[Symbol.dispose]();
derivation[Symbol.dispose]();
Reactive.batch().

Calling an already-created unsubscribe function remains permitted. Reactive.revision() and Reactive.inspect() remain permitted; they read bookkeeping, not graph values.

Creating a source or constructing an unevaluated derivation remains permitted because construction does not access or mutate an existing graph.

Implementation-created callbacks used for internal invalidation propagation are exempt from this restriction. If a user-defined dependency invokes such an internal callback from inside a public notification callback, the internal callback throws a TypeError rather than mutating the graph.

These restrictions prevent a notification callback from observing or creating a partially propagated graph. A callback should enqueue later work instead:

view.onInvalidate(() => {
  queueMicrotask(() => {
    reconcile(view.get());
  });
});

Listener failures

Every eligible listener is attempted even when an earlier listener throws.

After propagation completes:

if exactly one listener threw, that value is rethrown;
if multiple listeners threw, an AggregateError containing those values is thrown.

Listener failures do not roll back the mutation or invalidation that caused dispatch.

Reactive.batch(callback)

Reactive.batch(() => {
  count++;
  countChanged.invalidate();
  total++;
  totalChanged.invalidate();
});

Runs callback synchronously and returns its result. While a batch is active, public notification callbacks are deferred and coalesced. Internal staleness propagation is not deferred.

Semantics

callback must be callable. Otherwise, batch() throws a TypeError.

While the batch is active:

Internal invalidation propagation remains synchronous and immediate. Derivations become stale at the moment their dependency invalidates. Reads inside the batch therefore never observe a cache that a completed mutation should have invalidated.
Public notification callbacks are not invoked. Instead, each subscription that would have been notified is recorded at most once.
get(), invalidate(), subscription, and disposal all remain permitted inside the batch body, subject to the ordinary rules.

When the outermost batch exits — whether callback returned or threw — a single flush pass runs:

Deferred notifications are dispatched, at most once per recorded subscription, grouped by notifier, in registration order within each notifier, in the order the notifiers first recorded a deferred notification.
The standard dispatch rules apply during the flush, including the notification restrictions and re-entrancy queueing.
If a notifier was disposed during the batch, its deferred final invalidation is dispatched during the flush, after which its remaining subscriptions are discarded.

Batches nest. Only the outermost batch() call flushes.

Failure semantics

If callback throws and no flushed listener throws, the callback's thrown value is rethrown after the flush completes.

If listeners also throw during the flush, an AggregateError containing the callback's thrown value followed by the listener failures is thrown.

A batch does not roll back mutations or invalidations performed before the failure.

Interaction with source deduplication

Outside a batch, each invalidate() call on a source dispatches separately. Inside a batch, multiple invalidate() calls on the same source coalesce into at most one deferred notification per subscription. Frameworks requiring per-call granularity should not batch those invalidations.

Reactive.createSource(options)

const source = Reactive.createSource({
  name: "cartChanged",
});

Creates a live, valueless Source with no listeners.

options is optional. options.name, when present, is coerced to a string and used only for introspection and diagnostic messages.

A source does not:

store application state;
expose get() or set();
compare values;
evaluate derivations;
schedule work.

Its role is only to announce that associated state may have changed.

Source.prototype.invalidate()

source.invalidate();

Advances the revision clock, records the new clock value as the source's revision, and notifies the source's active listeners — synchronously outside a batch, deferred inside one.

The method returns undefined.

Outside a batch, each call is a separate invalidation; a source does not suppress repeated invalidations. Inside a batch, repeated invalidations coalesce as described under "Reactive.batch()".

Calling invalidate() after the source has been disposed is a no-op and does not advance the clock.

Example

let count = 0;
const countChanged =
  Reactive.createSource();

function increment() {
  count++;
  countChanged.invalidate();
}

Source.prototype.revision()

const rev = source.revision();

Returns the clock value of the source's most recent invalidation, or 0 if it has never invalidated. Disposal counts as an invalidation for this purpose.

Source.prototype.onInvalidate(listener)

const unsubscribe =
  source.onInvalidate(listener);

Registers listener and returns an idempotent unsubscribe function.

Registration does not invoke listener.

Calling onInvalidate() after disposal throws a TypeError.

Source.prototypeSymbol.dispose

source[Symbol.dispose]();

Permanently disables the source.

Disposal is idempotent. The first call performs the following observable steps:

The source becomes disposed and rejects new subscriptions.
The revision clock advances and the source records the new value as its revision.
One final invalidation is dispatched to listeners active when disposal began (deferred if a batch is active).
Every remaining subscription is discarded.
Any listener failures are reported after cleanup completes.

The final invalidation prevents a clean downstream derivation from silently retaining a cached result after its dependency becomes unavailable.

After disposal:

source.invalidate();              // no-op
source[Symbol.dispose]();         // no-op
source.onInvalidate(() => {});    // TypeError

Reactive.derive(dependencies, compute, options)

const total = Reactive.derive(
  [price, quantity],
  ([price, quantity]) =>
    price.get() * quantity.get(),
  {
    name: "total",
    equals: Object.is,
  },
);

Creates a lazy Derivation with a static dependency list.

Arguments

dependencies must be an Array. Its entries must be dependency objects.

compute must be callable. Otherwise, derive() throws a TypeError.

options is optional.

options.name is coerced to a string and used only for introspection and diagnostic messages.
options.equals, when present, must be callable and enables equality cutoff (see "Value revisions and equality cutoff"). When absent, every successful reevaluation is treated as producing a changed value.

The dependency Array is synchronously copied when derive() is called. Later mutation of the caller's Array does not affect the derivation.

Array order, length, and duplicate positions are preserved for the compute callback. Dependencies are deduplicated by object identity only for internal subscription management.

Construction behavior

Construction does not:

call compute or equals;
call a dependency's onInvalidate() or revision() method;
subscribe to any dependency;
produce a cached completion.

The derivation remains unevaluated until its first get() or until it becomes watched (see "Connection").

Reactive.deriveDynamic(selectionDependencies, resolveDependencies, compute, options)

const selected =
  Reactive.deriveDynamic(
    [mode],

    ([mode]) =>
      mode.get() === "advanced"
        ? [advanced]
        : [basic],

    ([selectedValue]) =>
      selectedValue.get(),
  );

Creates a lazy derivation whose computation dependencies may change over time.

options behaves as for derive().

Selection dependencies

selectionDependencies is a static Array of dependencies capable of changing which computation dependencies should be used.

The Array is copied at construction. Its order and duplicate positions are preserved when passed to the resolver.

The resolver is not ambiently tracked. Every mutable input capable of changing its result must be represented by a selection dependency.

Resolver

resolveDependencies must be callable. It receives a fresh Array containing the selection dependencies and must return an Array of computation dependencies.

The returned Array is copied before it is committed. Later mutation does not affect the derivation.

Computation dependencies

The resolver's returned dependencies are passed, in their original order and with duplicates preserved, to compute.

The active internal subscription set is the identity-deduplicated union of:

the selection dependencies; and
the current computation dependencies.

If the same dependency occurs in both groups, only one internal subscription is created. An invalidation from that dependency is treated as a selection invalidation.

When the resolver runs

The resolver runs:

during the first evaluation;
during connection of an unevaluated derivation (see "Connection");
after a selection dependency invalidates;
after derivation.invalidate() is called manually;
after a previously cached resolver failure is invalidated.

An invalidation from a computation-only dependency does not require the resolver to run again. The derivation may reuse its committed computation dependency list and rerun only compute.

Derivation states

A derivation is in exactly one of the following states:

State	Meaning
unevaluated	No completion has been cached
computing	The resolver or compute callback is active
clean	A cached completion is current
stale	The cached completion may be outdated
disposed	The derivation is permanently disabled

The clean state may contain either a cached return value or a cached thrown value.

Independently of its state, a derivation is either watched or unwatched.

Watched and unwatched derivations

A derivation is watched while at least one notification subscription to it is active. Subscriptions created internally by downstream derivations count, so watchedness propagates transitively upstream through built-in derivations.

Watch

A Smaller Foundation for JavaScript Reactivity

Patrick G — Mon, 20 Jul 2026 19:13:30 +0000

A Smaller Signals Standard

JavaScript frameworks all ended up at reactive programming. They just didn't end up at the same kind of reactive programming.

Signals, computed values, stores, effects, watchers—every major framework has its own graph implementation, its own tracking rules, its own scheduling model, its own lifecycle semantics. Moving reactive logic between frameworks means rewriting it. Composing two reactive libraries usually means they can't even see each other's dependencies.

The TC39 Signals proposal tries to fix this by standardizing an integrated reactive graph: writable signals, automatic dependency tracking, equality-aware propagation, watcher semantics, the whole thing.

That might be the right call. But there's another option worth considering: standardize less. Specifically, standardize an invalidation protocol and a lazy, cached derivation primitive with explicit dependencies. Let frameworks handle automatic tracking, equality, scheduling, ownership, and effects on top.

Here's what that might look like:

const changed = Reactive.createSource();

const total = Reactive.derive(
  [changed],
  () => calculateTotal(),
);

The source doesn't hold state. It just announces that something may have changed.

let count = 0;
const countChanged = Reactive.createSource();

count++;
countChanged.invalidate();

A derivation declares what can make it stale:

const label = Reactive.derive(
  [countChanged],
  () => `Count: ${count}`,
);

Call label.get() and it evaluates if needed, otherwise returns cache. That's it.

This is intentionally less ambitious than full signals. That restraint might make it a better standard.

Why smaller?

ECMAScript features are basically permanent. Once a reactive architecture ships in the language, every framework either adopts it or works around it for years. The abstraction boundary matters a lot.

Some reactive concepts are genuinely universal:

Dependencies can become invalid.
Derived values can be evaluated lazily.
Successful evaluations can be cached.
Invalidation can propagate transitively.
Consumers need to know when to re-check.
Subscriptions eventually need cleanup.

Others vary wildly between frameworks:

Automatic vs. explicit dependency tracking.
Equality semantics (Object.is? structural? version numbers?).
Graph liveness and memory management.
Ownership trees.
Effect scheduling and batching.
Transaction semantics.
Rendering integration.
Error boundaries.

A smaller proposal standardizes the mechanism. It doesn't standardize the policies built on top.

Framework policy
────────────────────────────────────
Signals, stores, proxies
Automatic dependency tracking
Equality and versioning
Effects and scheduling
Ownership and batching
Rendering integration
────────────────────────────────────
Standardized substrate
Invalidation protocol
Lazy cached derivation
Dependency replacement
Notification
Cleanup

Frameworks get a common foundation. They keep room to experiment above it.

Protocol interoperability, not graph unification

The current proposal's big selling point is interoperability: two reactive systems participating in the same automatic-tracking context. It achieves this by moving everyone onto a shared reactive graph.

The alternative achieves interoperability through a behavioral protocol:

dependency.onInvalidate(listener);

Anything implementing that can be a dependency. Not just built-in signals. Proxies. Immutable state containers. Reactive collections. Class instances. Caches. Remote resources. Framework-native signals. Even plain mutable objects paired with an invalidation source.

Example:

class ReactiveStore {
  #source = Reactive.createSource();
  #data = new Map();

  get(key) {
    return this.#data.get(key);
  }

  set(key, value) {
    this.#data.set(key, value);
    this.#source.invalidate();
  }

  onInvalidate(listener) {
    return this.#source.onInvalidate(listener);
  }
}

Another library derives from it without knowing its internals:

const summary = Reactive.derive(
  [store],
  ([store]) => calculateSummary(store),
);

The systems agree on how possible change is communicated. They don't have to agree on how values are stored, how reads are tracked, how equality works, or how ownership is represented.

That's a narrower interoperability. It might also be a more adoptable one.

Same architecture, different dependency discovery

Both approaches use the same broad shape: write pushes invalidation through the graph synchronously, framework decides when work matters, values are pulled lazily.

The difference is how edges get discovered.

Automatic tracking:

const total = new Signal.Computed(
  () => price.get() * quantity.get(),
);

Explicit dependencies:

const total = Reactive.derive(
  [price, quantity],
  ([price, quantity]) =>
    price.get() * quantity.get(),
);

Automatic tracking is often more ergonomic. Explicit dependencies are more visible and less contextual.

The tradeoff isn't reactive vs. non-reactive programming. It's two ways of building the same dependency graph.

Why explicit dependencies might matter for a standard

Automatic tracking introduces ambient execution context. Calling get() does different things depending on whether some outer computation is currently recording reads. You need untrack() and APIs to expose the current computation.

Explicit dependencies remove that ambient context.

Reactive.derive(
  [account, exchangeRates],
  computeBalance,
);

The edge is declared where the derivation is created.

This means:

Dependencies are visible in code review.
Unrelated callbacks can't accidentally become graph dependencies.
Tools can inspect intended edges without running the computation.
Ordinary reads keep ordinary JavaScript semantics.
Cross-realm behavior doesn't depend on a shared current-tracker context.
Callbacks can call into abstraction layers without implicitly capturing every reactive read underneath.

The cost: you have to declare dependencies correctly. Dynamic dependency selection needs careful API design so the values controlling selection are themselves in the graph.

This isn't obviously better for app developers. It might be a better semantic foundation for a language standard, though.

State stays where it is

A value-bearing signal isn't the only useful reactive abstraction. State already lives in:

Private class fields
Maps and sets
Proxies
Immutable snapshots
Database-backed models
Native objects
Remote caches
Framework-specific stores

A valueless invalidation source lets those systems participate without moving their data into a standardized container.

let count = 0;
const countChanged = Reactive.createSource();

function increment() {
  count++;
  countChanged.invalidate();
}

You can still build a familiar writable signal on top:

function signal(value, equals = Object.is) {
  const changed = Reactive.createSource();

  return {
    get() { return value; },

    set(next) {
      if (equals(value, next)) return;
      value = next;
      changed.invalidate();
    },

    onInvalidate(listener) {
      return changed.onInvalidate(listener);
    },

    [Symbol.dispose]() {
      changed[Symbol.dispose]();
    },
  };
}

Value storage and equality policy stay outside the standardized core.

Equality becomes a framework decision

One of the most valuable features of an integrated signal graph is equality-aware propagation: a computed value gets invalidated, reevaluates, produces the same result, and the graph prevents downstream work.

The smaller alternative makes a weaker guarantee: invalidation means a dependency may have changed. That's conservative, not value-sensitive.

Some systems use Object.is. Others use structural equality, version numbers, collection-specific checks, or no comparison at all. This flexibility matters for dependencies that don't represent a single comparable value—like an entire mutable store or a remote resource.

The cost is real: conservative invalidation schedules more work and causes more reevaluation. Whether that tradeoff is acceptable needs framework prototypes and benchmarks, not just API aesthetics.

Scheduling stays with frameworks

The current proposal (correctly) avoids standardizing a general effect() because scheduling is too tied to rendering, batching, transactions, and framework lifecycle.

The explicit alternative reaches the same conclusion. An invalidation callback is a wake-up signal:

view.onInvalidate(() => {
  queueMicrotask(() => view.get());
});

A framework might instead use:

An animation frame
A priority queue
A server-rendering pass
A transaction-aware scheduler
A synchronous test harness
A component rendering queue

The primitive reports that work may be stale. The framework decides when and how to run it.

Safety during propagation

Reactive invalidation isn't automatically a stable snapshot. In a graph with converging branches, one path may invalidate before another. If user code reads the graph during propagation, it sees partially invalidated state.

Any serious proposal needs to handle this.

The smaller alternative can preserve the same safety invariant as the current Signals design:

Internal invalidation propagation completes synchronously.
Public callbacks are scheduling notifications, not immediate work.
Reactive reads and writes are prohibited during the notification phase.
Consumers schedule later evaluation instead of rendering immediately.

A smaller API doesn't mean ignoring the soundness problems the existing proposal identified. It means keeping the necessary invariant without standardizing the entire watcher architecture around it.

Explicit cleanup instead of hidden liveness

Reactive graphs create memory-management problems. If a computed value subscribes to its dependencies, those dependencies keep it alive. An integrated runtime can try to infer liveness and disconnect unused nodes automatically.

The smaller alternative uses deterministic disposal:

using total = Reactive.derive(
  [price, quantity],
  computeTotal,
);

Or:

total[Symbol.dispose]();

This gives predictable cleanup and fits JavaScript's explicit resource-management model.

Upsides:

Cleanup is observable and testable.
Subscription removal doesn't depend on GC timing.
Engines don't need a hidden graph-liveness algorithm.
User-defined dependencies participate without exposing internal reachability.
Frameworks can tie disposal to component, owner, request, or scope lifetimes.

Downside: forgetting to dispose retains subscriptions.

That's a deliberate tradeoff. The question for TC39 is whether implicit liveness is universal and implementable enough to standardize, or whether explicit lifetime is the more conservative foundation.

Asymmetry

Here's maybe the strongest argument.

Start with a small explicit core, and libraries can add:

explicit reactive substrate
    ├── writable signals
    ├── equality-aware computed values
    ├── automatic tracking
    ├── proxy stores
    ├── ownership scopes
    ├── effects
    └── rendering systems

Start with a complete built-in graph, and frameworks can't remove its ambient tracking semantics, equality model, liveness behavior, watcher topology, or dependency-discovery rules.

They can ignore those features, but that undermines the interoperability benefits that justified standardization in the first place.

A smaller protocol might be a more durable meeting point between systems with different internal architectures.

What this maps to

Signals goal	Explicit alternative
Shared reactive infrastructure	Standard dependency and invalidation protocol
Framework interoperability	Explicit cross-library dependencies
Lazy computed values	Lazy cached derivations
Memoization	Cached successful evaluations
Dynamic dependencies	Explicit dependency replacement
Framework-controlled scheduling	No built-in scheduler or effect
Rendering independence	No component or DOM concepts
Support for stores	Existing stores implement the protocol
Multiple reactive styles	Signals, proxies, classes, collections can wrap the core
Cross-realm composition	Behavioral protocol, not `instanceof`
Cleanup	Deterministic disposal
Native optimization	Engines can optimize subscriptions and derivations
Shared vocabulary	Dependency, invalidation, stale, derivation, disposal

Meaningful overlap. Not complete equivalence.

What this gives up

A credible alternative should be explicit about its costs.

Shared automatic tracking. The current proposal lets libraries participate in the same ambient tracking context. The explicit alternative doesn't provide that automatically. Libraries interoperate through declared dependencies, but they don't inherently share a current computation.

Equality-minimal propagation. The explicit model guarantees conservative invalidation, not minimal recomputation. Frameworks can add equality-aware layers, but the base protocol doesn't ensure unchanged computed values suppress downstream work.

Automatic graph liveness. Strong subscriptions need explicit disposal. Unused computed nodes that remain connected to live dependencies aren't automatically garbage-collected.

Complete engine-visible graphs. A protocol with user-defined dependency objects is less inspectable than a graph of built-in signal objects. Native derivations can be inspected, but engines and dev tools may not understand every framework-owned edge.

These are real differences. They should be evaluated, not minimized.

The actual disagreement

The current Signals proposal isn't misguided. Signals, computed values, lazy evaluation, scheduling, reactive interoperability—all valuable.

The disagreement is about how much of the architecture ECMAScript should standardize.

The current proposal standardizes a shared reactive runtime.

The alternative standardizes a shared reactive protocol and lazy derivation substrate.

That smaller boundary could still support portable reactive models, cached computation, transitive invalidation, framework-controlled scheduling, and cross-library composition. At the same time, it would leave automatic tracking, equality, graph liveness, ownership, effects, and rendering open to continued ecosystem development.

That might make it the stronger standardization candidate—if TC39 concludes that those higher-level policies aren't yet universal, stable, or implementation-independent enough to become permanent JavaScript semantics.

The deciding evidence should come from real integrations. Prototype this beneath several distinct reactive systems. Evaluate it against the current proposal on interoperability, ergonomics, rendering correctness, recomputation overhead, memory retention, scheduler integration, dynamic dependencies, developer tooling, and implementation complexity.

The goal isn't to pick the smallest API because small is good. The goal is to find the smallest standard that creates meaningful ecosystem coordination without freezing more reactive policy than JavaScript needs.

See the proposed api

The Hidden Type System of Reactive Code

Patrick G — Fri, 17 Jul 2026 16:12:32 +0000

Change one thing and another thing changes. The second change follows because the system contains a relation between them: A → B. That arrow is the basis of reactivity.

The arrow may live in an event subscription, an invalidation rule, a dependency graph edge, or a callback. Wherever it lives, it creates type structure. It distinguishes one operation from another by what each can cause.

Operation Logs

Consider a cart operation log:

type CartOperation =
  | { type: "item-added"; productId: string; quantity: number }
  | { type: "item-removed"; productId: string }
  | { type: "quantity-changed"; productId: string; quantity: number };

item-added describes a transition: Cart --AddItem→ Cart. But inside the system it means more than that. It induces other operations: AddItem → InventoryReservation, AddItem → PriceRecalculation, AddItem → AnalyticsRecord. Those consequences are part of what AddItem means.

The log records which operations occurred. The subscriptions record what those operations can cause. Together they define a schema of possible change.

A system with Open, Close, Lock, Unlock has a different type structure from one with Increment, Decrement, Reset. Both may serialize state as JSON. Both may use strings as operation names. Their runtime representation can be identical. But their arrows differ, and the arrows are what distinguish the types.

Keyed Caches

A global cache hides the same structure behind generic methods: get, set, invalidate. The application assigns meaning to keys:

["user", userId]
["user-posts", userId]
["product", productId]
["cart", cartId]

A write to one entry may make several others stale:

UserChanged → UserCacheUpdated → MemberListInvalidated → PermissionsRecomputed → UIUpdated

These relations may be encoded with tags, key prefixes, callbacks, refetch rules, or ordinary procedural code. Each rule establishes an arrow. The cache key gives the value an address. The invalidation and synchronization rules give it a place in the reactive type structure.

This is why manually synchronized caches become hard to reason about: their type system is scattered across the codebase. Every invalidate call makes a claim about causation. Every callback saying "when this changes, update that" adds another arrow. No single place records the full graph. The member list goes stale, and the failure surfaces as a bug report instead of an error.

Reactive DAGs

Fine-grained systems like SolidJS record causal relations in a dependency graph:

const [price, setPrice] = createSignal(10);
const [quantity, setQuantity] = createSignal(2);
const total = createMemo(() => price() * quantity());

The graph records that total reads price and quantity. Operationally: PriceChanged → TotalRecomputed. Another computation consumes total:

const formattedTotal = createMemo(() => formatCurrency(total()));

Now the chain runs: PriceChanged → TotalRecomputed → FormattedTotalRecomputed → DOMUpdated.

The important relation is not just Price × Quantity → Total. That describes a function. The reactive relation is ΔPrice → ΔTotal, ΔQuantity → ΔTotal. An operation on a source induces an operation downstream, and that downstream operation can become the source of another arrow.

The DAG records these induced operations. Its edges say that a change here may require work there. This is where the type structure lives.

A derived node becomes a distinct position in the graph because it has its own incoming and outgoing operations. Two nodes may both contain booleans—IsAuthorized and IsMenuOpen—but their causal neighborhoods differ. IsAuthorized → AvailableOperations. IsMenuOpen → VisibleMenu. The graph tells them apart by their arrows, the same work a type system does with names.

Dynamic Dependencies

SolidJS can change the graph while the program runs:

const value = createMemo(() => enabled() ? primary() : fallback());

When enabled() is true, PrimaryChanged induces ValueRecomputed. When false, FallbackChanged does. The predicate does more than choose a value: it changes which operations can induce recomputation downstream. The runtime discovers these relations by observing which signals are read. Once recorded, they become the active schema of causation. The graph is dynamic because the operational type structure is dynamic.

But this flexibility creates a problem. A static type system cannot see the active graph because it changes at runtime. The arrows are real, but they are not present in the source code. A compiler can check that total is a number. It cannot check that total will be recomputed when price changes, because the set of dependencies may shift. The type structure exists but is invisible to the tools we normally use to verify type structure.

Predicates as Type Boundaries

A predicate divides a space of values: P : A → Boolean. Reactive systems use predicates to change which operations are available.

const canCheckout = createMemo(() => 
  cartItems().length > 0 && paymentMethod() !== null
);

The boolean marks a division in application state. In one region, SubmitOrder is invalid. In the other, it is available. The predicate creates two regions with different lawful arrows. The same pattern appears throughout: Anonymous → login allowed, Authenticated → logout allowed, EmptyCart → checkout unavailable, NonEmptyCart → checkout available. Each side of the line admits a different set of operations.

When the predicate changes, the operational structure changes with it. But here too the structure is implicit. The code does not declare that SubmitOrder becomes available when canCheckout is true. The availability is encoded in conditional rendering, guarded function calls, or disabled button states. The arrow from predicate to permitted operation is present in the behavior but not in any declaration.

One Structure, Different Machinery

An event log names operations and records them. A keyed cache embeds them in invalidation rules. A reactive DAG embeds them in dependency edges. The arrows live in different places, but the structure is the same: operation → induced operation → induced operation. That sequence is the reactive schema.

A schema of values might say that a user has an ID, name, and email. A reactive schema also says: UserNameChanged → ProfileChanged → SearchIndexChanged → RenderedNameChanged. It contains the possible states, the available operations, and the consequences of those operations.

The Problem

If the arrows are the type structure, they should be treated as type structure: declared, inspected, and checked. Most systems don't. The arrows exist, but they're spread across subscriptions, callbacks, and invalidation calls. Nothing can notice when an arrow is missing.

A stale value is a type error in this structure—a consequence the schema requires that the system failed to produce:

UserChanged → MemberListInvalidated   (declared, implicitly)
UserChanged → ∅                        (observed)

Some tools move in the right direction. Fine-grained runtimes discover arrows by tracking reads, so a dependency can't silently go missing. Query caches with hierarchical keys let one invalidation cover a family of entries. Incremental computation frameworks record every derivation and recompute exactly what a change reaches. Event-sourced systems replay logs through declared projections, making consequences enumerable rather than scattered.

But these are partial solutions. They capture arrows in one part of the system while the rest remains implicit. A SolidJS graph knows its signal dependencies but not that UserChanged should invalidate a member list. A cache invalidation rule knows that ["user", id] affects ["user-posts", id] but not that it should also affect a permission computation in a different module.

The deeper problem is that reactive arrows cross boundaries. They run from a database write through a cache layer through a UI framework to a DOM update. No single tool sees the whole path. The type structure is real but fragmented.

What would it mean to make it whole? Not just to track dependencies within a framework, but to declare and verify causal chains across the entire system. That would require a language or a set of conventions that can express arrows between subsystems written in different styles, stored in different places, maintained by different teams. It is a hard problem. It is also the problem that matters, because the bugs that cost the most are the ones where a change happens and something that should follow doesn't.

The causal graph of an application is not incidental wiring. It is the schema the application actually runs on. Like any schema, it works better declared than implied. But declaring it is not enough. It must be declared in a way that can be checked across the boundaries where the arrows actually run.

How to Build a JavaScript Framework

Patrick G — Tue, 14 Jul 2026 15:16:59 +0000

"Framework" is one of those words that sounds heavier than it is. Say it out loud and a whole vocabulary comes tumbling after: components, state, rendering, reactivity, reconciliation, virtual DOM, lifecycle hooks, compilers. It's enough to make you assume there's some deep magic happening that only a handful of people at Meta actually understand.

There's no magic. Strip the jargon away and a UI framework is a small idea wearing a big coat. By the end of this post we'll have built a working one, and it'll fit comfortably in your head. Let me show you the idea. We'll name the parts as we go.

Step 1: Bring your UI into JavaScript

Normally the browser thinks about UI as HTML:

<h1>Hello World!</h1>

We want to describe that same UI as plain JavaScript data instead. Why? Because once your interface is data, you can generate it, transform it, and diff it with ordinary code, no template language required.

There are a dozen ways to represent it. Objects, functions, arrays, JSX, template strings, whatever a compiler spits out. We'll use an object, because objects are easy to read and even easier to poke at in a console.

const ourUI = {
  tag: "h1",
  attributes: {},
  children: ["Hello World!"],
};

Three fields, and each one maps to something the browser cares about. tag is the kind of element to create, here an "h1". attributes is whatever gets attached to it, nothing in this case. children is what goes inside, some text.

Nesting works the way you'd hope, since a child can be another one of these objects:

const ourUI = {
  tag: "main",
  attributes: {
    id: "welcome",
  },
  children: [
    {
      tag: "h1",
      attributes: {},
      children: ["Hello World!"],
    },
    {
      tag: "p",
      attributes: {},
      children: [
        "We are building a framework.",
      ],
    },
  ],
};

Notice that nothing has actually appeared on the page. This is still an object sitting in memory, a description of a UI rather than a UI. That distinction is the whole game, so hold onto it. The next step is turning the description into something the browser can render.

Step 2: Turn the data into UI

Start with the smallest possible case. Say we're handed this:

const description = {
  tag: "h1",
  attributes: {},
  children: ["Hello World!"],
};

First we create the actual element:

const element = document.createElement(
  description.tag,
);

Since description.tag is "h1", that's the same as writing document.createElement("h1"). Either way we're left with an empty <h1> in hand.

Now for the contents. Our only child is a string, and the browser represents text inside an element as a text node, so we make one and stick it inside:

const text = document.createTextNode(
  "Hello World!",
);

element.appendChild(text);

We've reconstructed <h1>Hello World!</h1> from scratch. The move we just performed, description in and DOM node out, is the one operation this entire framework is built around. Let's wrap it in a function so we can reuse it.

Constructing one element

We'll call it construct(). It takes a UI description and hands back a real DOM node.

const construct = (description) => {
  const element = document.createElement(
    description.tag,
  );

  return element;
};

Right now it only builds the shell. Given { tag: "h1", attributes: {}, children: [] }, it returns an empty <h1> and nothing more. Let's teach it the rest, starting with attributes.

Adding attributes

Descriptions can carry attributes like these:

{
  tag: "button",
  attributes: {
    id: "save-button",
    class: "primary",
  },
  children: ["Save"],
}

Object.entries() flattens that object into name and value pairs, [["id", "save-button"], ["class", "primary"]], which is exactly the shape a loop wants:

for (
  const [name, value]
  of Object.entries(
    description.attributes ?? {},
  )
) {
  element.setAttribute(name, value);
}

Each pair goes straight to setAttribute(), and the constructor grows accordingly:

const construct = (description) => {
  const element = document.createElement(
    description.tag,
  );

  for (
    const [name, value]
    of Object.entries(
      description.attributes ?? {},
    )
  ) {
    element.setAttribute(name, value);
  }

  return element;
};

It can build an element and dress it. Onto the children.

Adding text children

The simplest child is a string:

children: ["Hello World!"]

We already know the drill. Turn it into a text node and append it. Folded into the constructor, that's:

const construct = (description) => {
  const element = document.createElement(
    description.tag,
  );

  for (
    const [name, value]
    of Object.entries(
      description.attributes ?? {},
    )
  ) {
    element.setAttribute(name, value);
  }

  for (
    const child
    of description.children ?? []
  ) {
    const textNode =
      document.createTextNode(child);

    element.appendChild(textNode);
  }

  return element;
};

Good enough for a lone heading. But it falls apart the moment a child isn't a string:

const ourUI = {
  tag: "main",
  attributes: {},
  children: [
    {
      tag: "h1",
      attributes: {},
      children: ["Hello World!"],
    },
  ],
};

That child is an object, another full description, and document.createTextNode() has no idea what to do with it. We need to build the child the same way we build its parent.

Constructing children recursively

We already have a function that turns a description into a DOM node, and it's construct() itself. So when a child turns out to be another description, we hand it back to construct() and let the function call itself.

That's recursion, and it fits the problem cleanly. A child can have children, and those can have children of their own, all the way down. The function keeps descending until it hits plain text and stops.

const construct = (description) => {
  if (
    typeof description === "string" ||
    typeof description === "number"
  ) {
    return document.createTextNode(
      String(description),
    );
  }

  const element = document.createElement(
    description.tag,
  );

  for (
    const [name, value]
    of Object.entries(
      description.attributes ?? {},
    )
  ) {
    element.setAttribute(name, value);
  }

  for (
    const child
    of description.children ?? []
  ) {
    const childNode = construct(child);

    element.appendChild(childNode);
  }

  return element;
};

The function now handles two cases.

When the description is text, we've hit the bottom of the tree:

if (
  typeof description === "string" ||
  typeof description === "number"
) {
  return document.createTextNode(
    String(description),
  );
}

A string becomes a text node. A number like 5 becomes the text "5". Either way we return and unwind.

Otherwise it's an element, so we do the full routine. Create it, apply its attributes, and construct each child, which is where the function calls back into itself:

const element = document.createElement(
  description.tag,
);

for (
  const [name, value]
  of Object.entries(
    description.attributes ?? {},
  )
) {
  element.setAttribute(name, value);
}

for (
  const child
  of description.children ?? []
) {
  element.appendChild(construct(child));
}

return element;

That's the core of the framework. Mostly one recursive function. Follow this part and the rest is detail.

Rendering the result

construct() builds a DOM tree but never puts it anywhere. For that we need a tiny render():

const render = (
  description,
  container,
) => {
  const element = construct(description);

  container.appendChild(element);
};

Give it a mount point in your HTML:

<div id="app"></div>

and you can drop your UI onto the page:

render(
  ourUI,
  document.querySelector("#app"),
);

The whole pipeline reads top to bottom. ourUI goes into construct(), a DOM tree comes out, and it gets appended to #app. That is a working UI framework. It's a small one, but it does the real job of taking JavaScript data and producing DOM.

Making descriptions easier to write

Spelling out the full object every single time gets old fast:

const heading = {
  tag: "h1",
  attributes: {},
  children: ["Hello World!"],
};

A little helper takes the sting out:

const h = (
  tag,
  {
    attributes = {},
    children = [],
  } = {},
) => ({
  tag,
  attributes,
  children,
});

Now the same heading is a one-liner:

const heading = h("h1", {
  children: ["Hello World!"],
});

But h() doesn't change anything underneath. Same { tag, attributes, children } object as before. Just a friendlier way to type it. That idea is bigger than it looks, because almost every fancy framework syntax you've met is doing the same thing. JSX, template literals, helper functions, whole compilers, they're all just different front doors to one thing: data that describes a UI.

Adding events

Attributes like id and class are strings, and setAttribute() handles them fine. Events are functions, though:

attributes: {
  onclick: () => {
    console.log("Clicked");
  },
}

Hand a function to setAttribute() and you won't get the behavior you want. It'll stringify the function and set a useless attribute. So we branch on a simple rule. If the name starts with on and the value is a function, assign it to the element directly. Otherwise fall back to setAttribute().

for (
  const [name, value]
  of Object.entries(
    description.attributes ?? {},
  )
) {
  if (
    name.startsWith("on") &&
    typeof value === "function"
  ) {
    element[name] = value;
  } else {
    element.setAttribute(name, value);
  }
}

Even with events in the mix, the whole constructor stays small:

const construct = (description) => {
  if (
    typeof description === "string" ||
    typeof description === "number"
  ) {
    return document.createTextNode(
      String(description),
    );
  }

  const element = document.createElement(
    description.tag,
  );

  for (
    const [name, value]
    of Object.entries(
      description.attributes ?? {},
    )
  ) {
    if (
      name.startsWith("on") &&
      typeof value === "function"
    ) {
      element[name] = value;
    } else {
      element.setAttribute(name, value);
    }
  }

  for (
    const child
    of description.children ?? []
  ) {
    element.appendChild(
      construct(child),
    );
  }

  return element;
};

This isn't production-grade, to be clear. It ignores plenty of DOM edge cases on purpose so the shape stays visible. What it does comes down to five steps: turn text into text nodes, turn element descriptions into elements, apply attributes, build children recursively, and hand back the finished tree.

Step 3: Give yourself a way to update the data

So far we can render UI, but only the frozen kind. Real interfaces don't hold still. Buttons get clicked, inputs change, a fetch resolves, a timer fires. Some value shifts, and the screen is supposed to keep up.

The pattern for handling that is almost boringly direct:

Store some data.
Describe the UI using that data.
Change the data.
Describe the UI again.

Before we hide any of this behind a component abstraction, let's do it by hand once, so there's no mystery left in it.

A counter with no components

We need some data:

let count = 5;

Then a function that describes the UI in terms of that data:

const view = () =>
  h("button", {
    children: [`Count: ${count}`],
  });

The point is that view() reads count fresh every time it runs. Call it now and it describes a button reading "Count: 5". Bump the count:

count += 1;

and the next call describes "Count: 6" instead. The view isn't a fixed thing. It's a function of the current data. Change the data, call again, get a new description.

Now put the first version on the page and hang onto a reference to it:

let currentNode = construct(view());

document
  .querySelector("#app")
  .appendChild(currentNode);

We keep currentNode around for one reason. When the data changes, we'll need to know which node to swap out.

Writing `update()`

The update routine has an obvious job. Run the view again, build the new DOM, replace the old DOM, and remember what's now on screen:

const update = () => {
  const nextNode = construct(view());

  currentNode.replaceWith(nextNode);

  currentNode = nextNode;
};

Wire the button up to call it, and the counter comes alive:

let count = 5; // the state
let currentNode; // whatever button is on the page right now

// Describes the UI for the current count. Reads count fresh on every call.
const view = () =>
  h("button", {
    attributes: {
      onclick: () => {
        count += 1; // change the data
        update(); // then ask the UI to catch up
      },
    },
    children: [`Count: ${count}`],
  });

const update = () => {
  const nextNode = construct(view()); // build the new button
  currentNode.replaceWith(nextNode); // swap it in for the old one
  currentNode = nextNode; // remember it for next time
};

// First render.
currentNode = construct(view());

document
  .querySelector("#app")
  .appendChild(currentNode);

Every click runs two lines, count += 1 and then update(), and that's the entire loop. Change the data, then ask the UI to catch up. No state object here, no virtual DOM, no compiler. Just change a value, run the view again, replace the old node. That turns out to be enough to build an interactive interface.

Spotting the pattern

Look at what the counter is made of and you'll see four moving parts. There's some state:

let count = 5;

a function describing the current UI:

const view = () => {
  return h(/* ... */);
};

an update function:

const update = () => {
  const nextNode = construct(view());

  currentNode.replaceWith(nextNode);

  currentNode = nextNode;
};

and one initial render:

currentNode = construct(view());

You could copy-paste this for every interactive corner of an app. But the DOM bookkeeping, the currentNode juggling and the replace-and-remember dance, would be identical every time:

let currentNode;

const update = () => {
  const nextNode = construct(view());

  currentNode.replaceWith(nextNode);

  currentNode = nextNode;
};

Repetition like that is a signal. When the same shape shows up over and over, it's asking to be packaged, and that package is what we call a component.

Formalizing the pattern

Here's the shape we're aiming for:

const Counter = component((update) => {
  let count = 5;

  return () =>
    h("button", {
      attributes: {
        onclick: () => {
          count += 1;
          update();
        },
      },
      children: [`Count: ${count}`],
    });
});

Read it as two nested functions with different jobs. The outer one is setup:

(update) => {
  let count = 5;

  // Return the view function.
}

It runs exactly once, when the component is born, which is why count gets initialized a single time. Setup then returns a second function, the view:

return () => {
  return h(/* current UI */);
};

This one runs as often as you like. And because it was defined inside setup, it can still reach count every time it runs, long after setup has finished. That's a closure, and it's doing real work here. It's what lets each component keep its own private state alive between renders.

So the component lifecycle is just:

Run setup once.
Create private data.
Return a view function.
Re-run the view whenever update() is called.

The wrapper isn't inventing anything. It's the by-hand counter from a minute ago with a name attached.

Representing a component

A regular element description looks like this:

{
  tag: "button",
  attributes: {},
  children: [],
}

Components need a description of their own, and we need a reliable way to tell the two apart. A Symbol works well, because it's a value that can't be confused with anything else:

const COMPONENT = Symbol("component");

With that, the component() helper is short:

const component = (setup) => {
  return (props = {}) => ({
    type: COMPONENT,
    setup,
    props,
  });
};

Calling Counter() doesn't run anything or touch the DOM. It just returns a description:

{
  type: COMPONENT,
  setup,
  props: {},
}

The component stays as data in the tree until something decides to build it, which keeps it consistent with everything else we've made.

That description object can do one more job for us: it can be the component's identity. If the exact same object appears in the tree again, we'll treat it as the same live component. A fresh call to Counter() makes a fresh object, and therefore a fresh instance.

That gives us a tiny identity rule without inventing IDs or keys yet:

const first = Counter();
const second = Counter();

first === first; // same instance description
first === second; // false: two separate instances

Each description represents one mounted component instance. To render two counters, call Counter() twice.

Constructing components

We teach construct() to recognize the new shape:

if (description.type === COMPONENT) {
  return constructComponent(description);
}

Then we move the repeated bookkeeping into constructComponent(), where it can live once and for all.

We'll also keep a WeakMap from component descriptions to their live instances:

const componentInstances = new WeakMap();

A WeakMap is useful here because its keys are objects, exactly what our component descriptions are. When the same description comes through construct() again, we can hand back the component that already exists instead of running setup a second time.

const constructComponent = (
  description,
) => {
  const existing =
    componentInstances.get(description);

  if (existing) {
    return existing.currentNode;
  }

  const {
    setup,
    props,
  } = description;

  const instance = {
    currentNode: null,
    view: null,
  };

  const update = () => {
    const nextNode = construct(
      instance.view(),
    );

    instance.currentNode.replaceWith(
      nextNode,
    );

    instance.currentNode = nextNode;
  };

  instance.view = setup(update, props);

  instance.currentNode = construct(
    instance.view(),
  );

  componentInstances.set(
    description,
    instance,
  );

  return instance.currentNode;
};

The first time a description arrives, setup runs and returns the view:

instance.view = setup(update, props);

The first render follows:

instance.currentNode = construct(
  instance.view(),
);

Then we remember the live instance under that description object:

componentInstances.set(
  description,
  instance,
);

Later, when either the component or one of its parents renders the same description again, we take the short path:

const existing =
  componentInstances.get(description);

if (existing) {
  return existing.currentNode;
}

That detail matters. An update calls only instance.view(), the function returned by setup. It does not call setup() again, so the closure holding the component's private state stays alive.

The developer never has to think about currentNode, instance storage, or the replace-and-remember dance again. Those chores belong to the framework now.

The whole thing

Here's the complete implementation, top to bottom:

// Tags a description as a component so construct() can spot it later.
const COMPONENT = Symbol("component");

// Keeps each component description connected to its live instance.
const componentInstances = new WeakMap();

// Sugar for building a plain element description.
const h = (
  tag,
  {
    attributes = {},
    children = [],
  } = {},
) => ({
  tag,
  attributes,
  children,
});

// Wraps a setup function. Calling the result returns a component description,
// not DOM — nothing runs until construct() gets to it.
const component = (setup) => {
  return (props = {}) => ({
    type: COMPONENT,
    setup,
    props,
  });
};

// Builds one live component instance and owns its update loop.
const constructComponent = (
  description,
) => {
  // The same description means the same component instance.
  const existing =
    componentInstances.get(description);

  if (existing) {
    return existing.currentNode;
  }

  const {
    setup,
    props,
  } = description;

  const instance = {
    currentNode: null,
    view: null,
  };

  // Re-run only the returned view and swap this component's root node.
  const update = () => {
    const nextNode = construct(
      instance.view(),
    );

    instance.currentNode.replaceWith(
      nextNode,
    );

    instance.currentNode = nextNode;
  };

  // Setup runs once for this description and returns the reusable view.
  instance.view = setup(update, props);

  // First render.
  instance.currentNode = construct(
    instance.view(),
  );

  componentInstances.set(
    description,
    instance,
  );

  return instance.currentNode;
};

// The heart of it: description in, DOM node out.
const construct = (description) => {
  // Base case: text and numbers become text nodes.
  if (
    typeof description === "string" ||
    typeof description === "number"
  ) {
    return document.createTextNode(
      String(description),
    );
  }

  // Hand components off to their own builder.
  if (description.type === COMPONENT) {
    return constructComponent(description);
  }

  // Otherwise it's an element description.
  const element = document.createElement(
    description.tag,
  );

  for (
    const [name, value]
    of Object.entries(
      description.attributes ?? {},
    )
  ) {
    // onclick, oninput, etc. are functions — assign them directly.
    if (
      name.startsWith("on") &&
      typeof value === "function"
    ) {
      element[name] = value;
    } else {
      element.setAttribute(name, value);
    }
  }

  // Build each child the same way, recursively.
  for (
    const child
    of description.children ?? []
  ) {
    element.appendChild(
      construct(child),
    );
  }

  return element;
};

// Construct a description and mount it into a container.
const render = (
  description,
  container,
) => {
  container.replaceChildren(
    construct(description),
  );
};

That's the entire framework. It now does one small but important piece of identity handling: when the same component description object appears again, the existing live instance is reused, so its setup and closure survive.

It's still teaching code, and it skips the hard, unglamorous stuff a real framework has to sweat: cleanup, fragments, boolean attributes, namespaces, general reconciliation, keyed lists, efficient DOM patching, scheduling, and error handling. Those matter enormously in practice, but pile them in here and they'd bury the idea worth taking away. A description goes into construct(), and a DOM node comes out. A component description that comes back is recognized and kept alive.

Rendering the counter

Define the component:

const Counter = component((update) => {
  let count = 5;

  return () =>
    h("button", {
      attributes: {
        onclick: () => {
          count += 1;
          update();
        },
      },
      children: [`Count: ${count}`],
    });
});

and render it:

render(
  Counter(),
  document.querySelector("#app"),
);

On first construction, setup runs, count starts at 5, setup returns the view, the view returns a button description, construct() turns it into DOM, and the DOM lands on the page. On each click, count ticks up, the component calls update(), the view runs again and describes a button reading "Count: 6", construct() builds a fresh button, and it replaces the old one.

Setup, importantly, does not run a second time for that component description. This line runs exactly once:

let count = 5;

The view keeps reaching that variable through the closure, and that closure is the component's state. The instance map keeps the description connected to the latest DOM node, so calling construct() with that description again does not reset the closure.

Adding props

Setup gets a second argument, props, so components can be configured from outside:

const Counter = component(
  (update, props) => {
    let count =
      props.initialCount ?? 0;

    const step =
      props.step ?? 1;

    return () =>
      h("button", {
        attributes: {
          onclick: () => {
            count += step;
            update();
          },
        },
        children: [
          `Count: ${count}`,
        ],
      });
  },
);

Which lets you stamp out counters that behave differently:

const app = h("main", {
  children: [
    Counter({
      initialCount: 5,
      step: 1,
    }),

    Counter({
      initialCount: 100,
      step: 10,
    }),
  ],
});

Every Counter() call produces a separate description, and every description that gets constructed gets its own everything: its own setup call, its own closure, its own state, its own view, its own update(), and its own DOM node. They stay out of each other's way because nothing is shared between them.

Keeping child components alive

The instance map gives us a useful rule: reuse the same component description, and you reuse the same component.

That matters when one component renders another. Imagine a dashboard whose own button changes the surrounding layout while a counter inside it keeps counting:

const Dashboard = component((update) => {
  let compact = false;

  // Created during setup, so this description is made once.
  const counter = Counter({
    initialCount: 5,
  });

  return () =>
    h("main", {
      attributes: {
        class: compact
          ? "compact"
          : "comfortable",
      },
      children: [
        h("button", {
          attributes: {
            onclick: () => {
              compact = !compact;
              update();
            },
          },
          children: [
            compact
              ? "Use comfortable layout"
              : "Use compact layout",
          ],
        }),

        counter,
      ],
    });
});

Dashboard's setup runs once. During setup it calls Counter() once and holds onto the resulting description in counter.

When the dashboard updates, only its returned view runs again. The new <main> is constructed, but it contains the same counter object. When construct() reaches it, the WeakMap finds the existing counter instance and returns its current DOM node. The node moves into the rebuilt parent, while the counter's setup, closure, and current count stay intact.

The placement of Counter() is what makes the difference. This preserves the child:

const child = Counter();

return () =>
  h("main", {
    children: [child],
  });

This creates a new child on every parent render:

return () =>
  h("main", {
    children: [Counter()],
  });

For our tiny framework, object identity is the key. Real frameworks can recover identity from component type, position, explicit keys, or compiler-generated bookkeeping. We're using the smallest rule that lets the idea stay visible.

Composition

Because our UI is plain data, you compose it with plain functions. There's no special API to learn, just JavaScript:

const Card = ({
  title,
  children,
}) =>
  h("section", {
    attributes: {
      class: "card",
    },
    children: [
      h("h2", {
        children: [title],
      }),

      ...children,
    ],
  });

Drop a counter inside a card and it just works:

const app = h("main", {
  children: [
    Card({
      title: "My Counter",
      children: [
        Counter({
          initialCount: 5,
        }),
      ],
    }),
  ],
});

Elements can hold components, components can return elements, and functions can produce either one. Stateful child descriptions can be created once during setup and reused wherever the returned view places them. That freedom to mix is where a real composition model starts, and we barely had to do anything to get it.

Where React, Vue, and Svelte actually differ

We've now arrived at the pattern every UI framework is built to package:

Store some state.
Describe UI using that state.
Change the state.
Update the UI.

Once you see past the syntax, the differences between React, Vue, Svelte and the rest come down to two questions. How do they package this pattern, and how do they figure out when and what to update?

Our version packages it with a closure and an explicit call. State is a variable:

let count = 5;

and updating is something you say out loud:

count += 1;
update();

We respond by re-running the view and replacing the component's root node. It's about as blunt as an approach can get, and it works.

The big frameworks make different bets. React asks your component to return a description of the current UI, routes state changes through setter functions, and decides on its own when to re-run you and how to reconcile the result. Vue wraps state in a reactive system that tracks which bits of UI depend on which values, then updates only what's affected when those values change. Svelte pushes the work earlier, into a compile step, analyzing your component and generating code that makes surgical updates when state changes.

The syntax differs and the strategies differ, but the questions underneath don't move:

What data changed?
Which UI depends on it?
When should the UI update?
How should the DOM change?

Our answers are deliberately naive. The developer changes a variable, the developer calls update(), the returned view reruns, and the component's root gets rebuilt. If that view reuses a child component description, we preserve the child's live instance by object identity. Everything else is blunt.

A serious framework does far more. It detects dependencies automatically, batches updates, schedules rendering, compares old and new descriptions, touches individual DOM properties instead of whole subtrees, matches children by type, position, or key, compiles targeted updates, and cleans up what's removed. All of that is sophistication layered on top of the same loop. The pattern was doing the load-bearing work the whole time, not the syntax.

The recipe, start to finish

Bring the UI into JavaScript. Represent the interface as data:

const ui = h("h1", {
  children: ["Hello World!"],
});

Turn the data into DOM with a recursive function:

const node = construct(ui);

Give yourself a way to update the data. Change ordinary state, then ask the UI to catch up:

count += 1;
update();

Package the pattern so you're not rewriting the DOM bookkeeping every time:

const Counter = component((update) => {
  let count = 5;

  return () => {
    // Describe the current UI.
  };
});

Keep an instance alive by keeping and reusing its component description:

const counter = Counter();

return () =>
  h("main", {
    children: [counter],
  });

Profit. Or the less triumphant version: spend the next several years optimizing updates, chasing edge cases, maintaining compiler tooling, and arguing about state-management APIs on the internet. That frontier really is endless. But the loop at the center never gets more complicated than this:

Data
  ↓
UI description
  ↓
DOM
  ↓
User interaction
  ↓
Updated data
  ↓
Updated UI description
  ↓
Updated DOM

Describe the interface as data. Turn the data into UI. Run the returned view again when the data changes. Reuse a component description when you want that instance to survive. Everything else is framework design.

The 16-Line Pattern That Eliminates Prop Drilling, & Understanding How Effect Systems Work

Patrick G — Mon, 21 Jul 2025 13:47:02 +0000

Learn how a tiny runtime using JavaScript generators can transform how you structure applications

Building Intuition: The Restaurant Analogy

Imagine two restaurants:

Restaurant A (Dependency Passing)

Every order must go through: Host → Manager → Head Chef → Line Cook → Prep Cook
Even if the prep cook just needs salt, the entire chain must know about salt
Adding a new ingredient requires updating everyone's job description
Each person handles things they don't need, just to pass them along

Restaurant B (Our Pattern)

Each cook has a button: "I need salt"
A runner brings exactly what's needed
Cooks focus on cooking, not supply chain management
New ingredients? Just add a new button

This is the shift we're making in code.

The Problem: Dependency Passing Hell

Let's see this in code you've probably written:

// ❌ The problem: Every function needs ALL dependencies passed through
async function saveUserHandler(req, res, db, logger, cache, emailService, validator) {
  const { userId, data } = req.body;

  // This function only uses logger, but needs all deps to pass them down
  logger.info(`Request to save user ${userId}`);

  const result = await updateUserProfile(userId, data, db, logger, cache, emailService, validator);
  res.json(result);
}

async function updateUserProfile(userId, data, db, logger, cache, emailService, validator) {
  // This function doesn't use emailService, but must pass it along
  logger.info(`Updating profile for ${userId}`);

  const user = await loadAndValidateUser(userId, db, logger, cache, validator);
  const updatedUser = await saveUser(user, data, db, logger, emailService);

  return updatedUser;
}

async function loadAndValidateUser(userId, db, logger, cache, validator) {
  // More dependency passing...
  const cached = await cache.get(`user:${userId}`);
  if (cached) {
    logger.info('Cache hit');
    return cached;
  }

  const user = await db.findUser(userId);
  if (!validator.isValidUser(user)) {
    throw new Error('Invalid user');
  }

  await cache.set(`user:${userId}`, user);
  return user;
}

async function saveUser(user, data, db, logger, emailService) {
  // Finally using emailService, 3 levels deep!
  const updated = await db.updateUser(user.id, data);
  await emailService.sendUpdateEmail(user.email, updated);
  logger.info('User saved and email sent');
  return updated;
}

What is Dependency Passing?
This pattern of passing dependencies through multiple function layers is known as "dependency passing" or "parameter threading". In React, it's called "prop drilling", but the problem exists in all JavaScript code - functions receiving dependencies they don't use, just to pass them to other functions.

Visualizing the Pain:

Dependency Passing Visualization:

saveHandler ━━━━━━━━━━━━━━━━━━━━━━━━━━┓
    ↓ (db, logger, cache, email, ...) ┃
updateProfile ━━━━━━━━━━━━━━━━━━━━━━━━┫
    ↓ (db, logger, cache, email, ...) ┃ Height = Pain
loadUser ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
    ↓ (db, logger, cache, email, ...) ┃
validateUser ━━━━━━━━━━━━━━━━━━━━━━━━━┫
    ↓ (db, logger, cache, email, ...) ┃
saveUser ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
    (finally uses email!)

The Mind-Shift: From PUSH to PULL

Here's the key insight that changes everything:

// The traditional way: "How do I get dependencies TO my function?"
// Structure dictates dependencies - PUSH model
function doWork(logger, db, cache, validator, emailer, metric, queue) { 
  // Must accept ALL dependencies, even if we only use logger
  logger.info('Working...');
}

// The new way: "How can my function GET dependencies when needed?"
// Logic dictates dependencies - PULL model
function* doWork() {
  // Only get what you need, when you need it!
  const logger = yield getLogger();
  logger.info('Working...');

  if (someCondition) {
    const db = yield getDatabase();  // Pull conditionally
    // ...
  }
  // Never needed cache, validator, emailer, metric, or queue? Never pulled them!
}

The Pattern Visualized:

Generator Pattern:

saveHandler ●
            │
updateProfile ● ←──── runtime ←──── context
            │           ↑           (all deps)
loadUser    ● ←─────────┘
            │
validateUser ● ←────────┘
            │
saveUser    ● ←─────────┘

"Why Not Just..." - Addressing the Alternatives

You might be thinking of alternatives. Let's address them:

Why not just use a global object?

// Global approach
global.db.findUser(123); 

// Problems:
// ❌ Can't test without modifying globals
// ❌ No dependency tracking - what does this function use?
// ❌ Breaks with multiple contexts (e.g., multi-tenant)
// ❌ Hidden coupling - dependencies aren't explicit

Why not use classes and constructor injection?

class UserService {
  constructor(db, logger, cache, validator, emailer) {
    // Back to dependency passing in the constructor!
    this.db = db;
    this.logger = logger;
    // ...
  }
}
// ❌ Still need to pass all dependencies
// ❌ Instances become stateful
// ❌ Hard to compose operations

Why not use React Context or similar?

const UserContext = React.createContext();
// ❌ Only works in React
// ❌ Still requires provider setup
// ❌ Can't compose workflows
// ❌ Limited to component tree

Our solution achieves the same goals with just 16 lines of vanilla JavaScript.

Understanding Generators: The Pause/Resume Mechanism

Before we build our solution, let's understand generators:

function* simpleExample() {
  console.log('1. Generator starts');

  const value = yield 'Hello';  // PAUSE here, send 'Hello' out

  console.log('2. Generator resumes with:', value);

  const value2 = yield 'World'; // PAUSE again, send 'World' out

  console.log('3. Generator resumes with:', value2);
  return 'Done';
}

// Let's manually control the generator
const gen = simpleExample();

console.log('Starting...');
const result1 = gen.next();      // Run until first yield
console.log('Got:', result1);     // { value: 'Hello', done: false }

const result2 = gen.next('Hi!');  // Resume with 'Hi!'
console.log('Got:', result2);     // { value: 'World', done: false }

const result3 = gen.next('Bye!'); // Resume with 'Bye!'
console.log('Got:', result3);     // { value: 'Done', done: true }

Output:

Starting...
1. Generator starts
Got: { value: 'Hello', done: false }
2. Generator resumes with: Hi!
Got: { value: 'World', done: false }
3. Generator resumes with: Bye!
Got: { value: 'Done', done: true }

🤔 Check Your Understanding #1

Before continuing, make sure you can answer:

Why do generators allow us to "pause" execution?
What happens when we call yield?
How do we send values back into a generator?

Answers

Generators pause at each yield, returning control to the caller
yield pauses the generator and sends out a value
We send values back using gen.next(value) - the value becomes the result of the yield

Building the Pattern Step by Step

Step 1: The Operation Description Pattern

Let's build up to our pattern progressively:

// Building up to the pattern:

// Step 1: We need to call this operation
context.db.findUser(123)

// Step 2: But we don't have context yet! Wrap in a function
() => context.db.findUser(123)

// Step 3: But context isn't in scope! Accept as parameter
(context) => context.db.findUser(123)

// Step 4: But we need to capture the ID! Wrap again
(id) => (context) => context.db.findUser(id)

// Final pattern: Parameter capture + Context injection
const getUser = (id) => (context) => context.db.findUser(id);

This creates a description of an operation without executing it:

// Operation descriptions - these DON'T execute anything
const getUser = (id) => (context) => context.db.findUser(id);
const log = (msg) => (context) => context.logger.info(msg);
const validate = (data) => (context) => context.validator.validate(data);

Step 2: Building the Runtime - Basic Version

Let's build our runtime step by step to understand how it works:

// Version 1: Manual execution (no loop)
async function simpleRuntime(generatorFn, context) {
  const gen = generatorFn();

  // Start the generator
  let step1 = await gen.next();
  console.log('Generator yielded:', step1.value);

  // Execute what it asked for
  let result1 = await step1.value(context);

  // Give it back
  let step2 = await gen.next(result1);
  console.log('Generator yielded:', step2.value);

  // This gets repetitive... we need a loop!
}

// Version 2: Add the loop
async function runtimeWithLoop(generatorFn, context) {
  const gen = generatorFn();
  let result = await gen.next();

  while (!result.done) {
    // Execute the operation
    const value = await result.value(context);
    // Continue the generator
    result = await gen.next(value);
  }

  return result.value;
}

// Version 3: Add error handling (our final version)
function runtime(generatorFunction) {
  return async function execute(context) {
    const generator = generatorFunction();
    let result = await generator.next();

    while (!result.done) {
      const operation = result.value;

      try {
        const operationResult = await operation(context);
        result = await generator.next(operationResult);
      } catch (error) {
        result = await generator.throw(error);
      }
    }

    return result.value;
  };
}

🤔 Check Your Understanding #2

Why do we need a loop in our runtime?
What does operation(context) do?
Why do we have a try/catch block?

Answers

Generators can yield multiple times, we need to handle each yield
It executes the operation description with the actual context
To forward errors from operations back to the generator

Common Mistakes and How to Avoid Them

Let's learn from common errors:

// ❌ MISTAKE 1: Yielding values instead of operations
async function* wrong() {
  const user = yield db.getUser(1); // ❌ This executes immediately!
  // db is not defined, this will crash
}

// ✅ CORRECT: Yield operation descriptions
async function* correct() {
  const user = yield (ctx) => ctx.db.getUser(1); // ✅ Executes later
  // Or better, use an operation creator:
  const user2 = yield getUser(1); // ✅ Much cleaner
}

// ❌ MISTAKE 2: Forgetting to return from operation
const badOperation = (id) => (ctx) => {
  ctx.db.getUser(id); // ❌ Forgot to return!
};

// ✅ CORRECT: Always return the promise
const goodOperation = (id) => (ctx) => {
  return ctx.db.getUser(id); // ✅
};
// Or use arrow function's implicit return:
const bestOperation = (id) => (ctx) => ctx.db.getUser(id); // ✅

// ❌ MISTAKE 3: Trying to store context
async function* contextMistake() {
  const ctx = yield getContext(); // ❌ Don't do this!
  // Context should only exist in the runtime
}

// ✅ CORRECT: Let operations access context
async function* contextCorrect() {
  const user = yield getUser(123); // ✅ Runtime handles context
}

// ❌ MISTAKE 4: Yielding non-functions
async function* yieldMistake() {
  yield 'Hello'; // ❌ Runtime expects functions!
}

// ✅ CORRECT: Always yield operations
async function* yieldCorrect() {
  yield log('Hello'); // ✅ log returns a function
}

Complete Working Example

Let's see it all together:

// ============================================
// 1. THE RUNTIME (copy this to use the pattern)
// ============================================
function runtime(generatorFunction) {
  return async function execute(context) {
    const generator = generatorFunction();
    let result = await generator.next();

    while (!result.done) {
      const operation = result.value;

      try {
        const operationResult = await operation(context);
        result = await generator.next(operationResult);
      } catch (error) {
        result = await generator.throw(error);
      }
    }

    return result.value;
  };
}

// ============================================
// 2. OPERATION DEFINITIONS
// ============================================
const log = (message) => 
  (context) => context.logger.info(message);

const getUser = (id) => 
  (context) => context.db.findUser(id);

const updateUser = (id, data) => 
  (context) => context.db.updateUser(id, data);

const sendEmail = (to, subject, body) =>
  (context) => context.email.send(to, subject, body);

const cacheGet = (key) => 
  (context) => context.cache.get(key);

const cacheSet = (key, value) => 
  (context) => context.cache.set(key, value);

// ============================================
// 3. BUSINESS LOGIC (using generators)
// ============================================
async function* updateUserProfile(userId, newData) {
  yield log(`Starting update for user ${userId}`);

  // Check cache first
  const cacheKey = `user:${userId}`;
  let user = yield cacheGet(cacheKey);

  if (!user) {
    yield log('Cache miss - loading from database');
    user = yield getUser(userId);

    if (!user) {
      throw new Error('User not found');
    }

    // Cache for next time
    yield cacheSet(cacheKey, user);
  } else {
    yield log('Cache hit');
  }

  // Update the user
  const updated = { ...user, ...newData, updatedAt: new Date() };
  yield updateUser(userId, updated);
  yield cacheSet(cacheKey, updated);

  // Send notification
  yield sendEmail(
    user.email,
    'Profile Updated',
    `Hi ${updated.name}, your profile was updated.`
  );

  yield log('Update completed successfully');
  return updated;
}

// ============================================
// 4. USAGE
// ============================================
async function main() {
  // Create the context with real implementations
  const context = {
    logger: {
      info: (msg) => console.log(`[LOG] ${msg}`)
    },
    db: {
      findUser: async (id) => {
        console.log(`[DB] Finding user ${id}`);
        return { id, name: 'John Doe', email: 'john@example.com' };
      },
      updateUser: async (id, data) => {
        console.log(`[DB] Updating user ${id}`);
        return data;
      }
    },
    email: {
      send: async (to, subject, body) => {
        console.log(`[EMAIL] To: ${to}, Subject: ${subject}`);
      }
    },
    cache: (() => {
      const storage = new Map();
      return {
        get: async (key) => {
          console.log(`[CACHE] Getting ${key}`);
          return storage.get(key);
        },
        set: async (key, value) => {
          console.log(`[CACHE] Setting ${key}`);
          storage.set(key, value);
        }
      };
    })()
  };

  // Create executable function
  const runUpdate = runtime(() => updateUserProfile(123, { name: 'Jane Doe' }));

  // Execute with our context
  const result = await runUpdate(context);
  console.log('\n[RESULT]', result);
}

main();

Side-by-Side Comparison

Let's see the difference clearly:

// ❌ Traditional: 7 parameters, dependency passing
async function createUserTraditional(
  name, email, db, logger, validator, emailer, cache
) {
  logger.info('Creating user');
  if (!validator.isValidEmail(email)) {
    logger.error('Invalid email');
    throw new Error('Invalid email');
  }
  const user = await db.createUser({ name, email });
  await cache.set(`user:${user.id}`, user);
  await emailer.sendWelcome(email);
  logger.info('User created');
  return user;
}

// ✅ Generator: 2 parameters, clear intent
async function* createUserGenerator(name, email) {
  yield log('Creating user');
  const isValid = yield validateEmail(email);
  if (!isValid) {
    yield logError('Invalid email');
    throw new Error('Invalid email');
  }
  const user = yield createUser({ name, email });
  yield cacheUser(user);
  yield sendWelcomeEmail(email);
  yield log('User created');
  return user;
}

// Result: 71% fewer parameters, 100% clearer intent

Error Handling: Complete Understanding

Let's deeply understand how errors flow through the system:

// Example 1: Generator handles the error
async function* safeWorkflow() {
  try {
    yield log('Attempting risky operation');
    const user = yield getUser(999); // This might throw
    return user;
  } catch (error) {
    yield log(`Error caught: ${error.message}`);
    return null; // Generator handles it gracefully
  }
}

// Example 2: Generator doesn't catch - error propagates
async function* unsafeWorkflow() {
  const user = yield getUser(999); // If this throws...
  return user; // Never reached
}

// Error flow visualization:
// 1. getUser(999) throws in context.db.findUser
// 2. Runtime catches in its try/catch
// 3. Runtime calls generator.throw(error)
// 4. If generator has try/catch: error is caught there
// 5. If not: error propagates to runtime caller

// Example 3: Cleanup on error
async function* workflowWithCleanup() {
  yield log('Starting transaction');
  const transaction = yield beginTransaction();

  try {
    const user = yield createUser({ name: 'Test' });
    const profile = yield createProfile(user.id);
    yield commitTransaction(transaction);
    return { user, profile };
  } catch (error) {
    yield log('Error occurred, rolling back');
    yield rollbackTransaction(transaction);
    throw error; // Re-throw after cleanup
  }
}

Exercise: Convert This Code

Here's a real function that suffers from dependency passing. Try converting it yourself:

// ❌ Traditional approach - lots of dependencies
async function processOrder(
  customerId, 
  items, 
  db, 
  logger, 
  inventory, 
  payment, 
  email, 
  metrics
) {
  logger.info(`Creating order for customer ${customerId}`);
  metrics.increment('orders.started');

  const customer = await db.findCustomer(customerId);
  if (!customer) {
    logger.error('Customer not found');
    throw new Error('Customer not found');
  }

  for (const item of items) {
    const available = await inventory.check(item.productId, item.quantity);
    if (!available) {
      logger.error(`Product ${item.productId} out of stock`);
      throw new Error('Out of stock');
    }
  }

  const total = items.reduce((sum, item) => sum + item.price * item.quantity, 0);
  const paymentResult = await payment.charge(customer.paymentMethodId, total);

  const order = await db.createOrder({
    customerId,
    items,
    total,
    paymentId: paymentResult.id
  });

  await email.sendOrderConfirmation(customer.email, order);
  metrics.increment('orders.completed');
  logger.info(`Order ${order.id} created successfully`);

  return order;
}

✅ Solution: Using the generator pattern

// First, create the operations
const log = (msg) =&gt; (ctx) =&gt; ctx.logger.info(msg);
const logError = (msg) =&gt; (ctx) =&gt; ctx.logger.error(msg);
const findCustomer = (id) =&gt; (ctx) =&gt; ctx.db.findCustomer(id);
const checkInventory = (productId, quantity) =&gt; 
  (ctx) =&gt; ctx.inventory.check(productId, quantity);
const chargePayment = (methodId, amount) =&gt; 
  (ctx) =&gt; ctx.payment.charge(methodId, amount);
const createOrder = (data) =&gt; (ctx) =&gt; ctx.db.createOrder(data);
const sendOrderEmail = (email, order) =&gt; 
  (ctx) =&gt; ctx.email.sendOrderConfirmation(email, order);
const incrementMetric = (name) =&gt; (ctx) =&gt; ctx.metrics.increment(name);

// Then, the generator workflow
async function* processOrder(customerId, items) {
  yield log(`Creating order for customer ${customerId}`);
  yield incrementMetric('orders.started');

  const customer = yield findCustomer(customerId);
  if (!customer) {
    yield logError('Customer not found');
    throw new Error('Customer not found');
  }

  for (const item of items) {
    const available = yield checkInventory(item.productId, item.quantity);
    if (!available) {
      yield logError(`Product ${item.productId} out of stock`);
      throw new Error('Out of stock');
    }
  }

  const total = items.reduce((sum, item) =&gt; sum + item.price * item.quantity, 0);
  const paymentResult = yield chargePayment(customer.paymentMethodId, total);

  const order = yield createOrder({
    customerId,
    items,
    total,
    paymentId: paymentResult.id
  });

  yield sendOrderEmail(customer.email, order);
  yield incrementMetric('orders.completed');
  yield log(`Order ${order.id} created successfully`);

  return order;
}

Notice how the generator version:

Takes only 2 parameters instead of 8
Doesn't need to know about dependencies
Is easier to read and follow
Can be tested with simple mocks

Relating to Familiar Patterns

This pattern might feel new, but it's similar to things you already know:

Like Express Middleware

// Express middleware passes control
app.use((req, res, next) => {
  console.log('Logging');
  next(); // Pass control to next middleware
});

// Our pattern is similar
async function* workflow() {
  yield log('Logging');        // Pass control to runtime
  const user = yield getUser(); // Pass control to runtime
  return user;
}

Like Async/Await

// async/await: pause for TIME (waiting for I/O)
async function fetchUser() {
  const user = await fetch('/api/user'); // Pause for network
  return user;
}

// generators: pause for DEPENDENCIES (waiting for context)
async function* fetchUser() {
  const user = yield getUser(); // Pause for dependency
  return user;
}

Like Dependency Injection Containers

// Traditional DI container (like Angular)
@Injectable()
class UserService {
  constructor(private db: Database) {}
}

// Our pattern - same concept, no framework
async function* userService() {
  const db = yield getDatabase();
}

Real-World Case Study: Redux-Saga

Redux-Saga, used by millions, implements this exact pattern:

// Redux-Saga code
function* watchUserLogin() {
  while (true) {
    const action = yield take('USER_LOGIN');        // Pause for action
    const user = yield call(api.login, action.payload); // Pause for API
    yield put({ type: 'LOGIN_SUCCESS', user });     // Pause for dispatch
  }
}

// Our pattern - identical concept
async function* watchUserLogin() {
  while (true) {
    const action = yield waitForAction('USER_LOGIN');
    const user = yield callApi('/login', action.payload);
    yield dispatch({ type: 'LOGIN_SUCCESS', user });
  }
}

The pattern you're learning powers production systems handling millions of requests.

Gradual Migration Guide

You don't need to rewrite everything at once. Here's how to migrate gradually:

Step 1: Start with Leaf Functions

// Before: Leaf function with dependencies
async function sendNotification(userId, message, db, emailService) {
  const user = await db.getUser(userId);
  await emailService.send(user.email, message);
}

// After: Convert to generator
async function* sendNotification(userId, message) {
  const user = yield getUser(userId);
  yield sendEmail(user.email, message);
}

Step 2: Create a Hybrid Wrapper

// Wrapper that works both ways
function sendNotification(userId, message, db, emailService) {
  // New way: single context argument
  if (arguments.length === 1 && typeof userId === 'object') {
    const context = userId;
    return runtime(function* () {
      const user = yield getUser(context.userId);
      yield sendEmail(user.email, context.message);
    })(context);
  }

  // Old way: multiple dependencies
  return (async () => {
    const user = await db.getUser(userId);
    await emailService.send(user.email, message);
  })();
}

Step 3: Update Callers One by One

// Old caller
await sendNotification(123, 'Hello', db, emailService);

// New caller
await sendNotification({
  userId: 123,
  message: 'Hello',
  // context goes here
});

Step 4: Remove Old Code Path

Once all callers are updated, remove the old code path and fully embrace the pattern.

Why This Works: Inversion of Control

This pattern implements a fundamental principle called "Inversion of Control" (IoC):

Traditional Control Flow:

Your Code → Calls → Dependencies
(You control when/how dependencies are called)

Inverted Control Flow:

Your Code → Describes → What It Needs
Runtime → Provides → Dependencies
(Runtime controls when/how dependencies are provided)

This is the same principle behind:

Dependency Injection containers (Spring, Angular)
React hooks (useContext, useState)
Middleware systems (Express, Koa)
Effect systems (Effect-TS, ZIO)

But implemented in just 16 lines of vanilla JavaScript!

Testing: Now It's Trivial

Testing becomes incredibly simple:

test('updateUserProfile updates user correctly', async () => {
  // Create test context - only mock what you use!
  const mockUser = { id: 1, name: 'Old Name' };
  const testContext = {
    logger: { info: jest.fn() },
    db: {
      findUser: jest.fn().mockResolvedValue(mockUser),
      updateUser: jest.fn().mockResolvedValue({ ...mockUser, name: 'New Name' })
    },
    cache: { 
      get: jest.fn().mockResolvedValue(null),
      set: jest.fn() 
    },
    email: { 
      send: jest.fn() 
    }
  };

  // Run workflow
  const runUpdate = runtime(() => updateUserProfile(1, { name: 'New Name' }));
  const result = await runUpdate(testContext);

  // Assert
  expect(testContext.db.findUser).toHaveBeenCalledWith(1);
  expect(result.name).toBe('New Name');
  expect(testContext.email.send).toHaveBeenCalled();
});

TypeScript Support

The pattern works beautifully with TypeScript:

// Define your context shape
interface AppContext {
  db: {
    findUser(id: number): Promise<User | null>;
    updateUser(id: number, data: Partial<User>): Promise<User>;
  };
  logger: {
    info(message: string): void;
  };
  email: {
    send(to: string, subject: string, body: string): Promise<void>;
  };
}

// Type for operations
type Operation<T> = (context: AppContext) => Promise<T>;

// Type-safe operations
const getUser = (id: number): Operation<User | null> => 
  (ctx) => ctx.db.findUser(id);

const log = (message: string): Operation<void> => 
  (ctx) => { ctx.logger.info(message); return Promise.resolve(); };

// Type-safe workflow
async function* updateUserWorkflow(
  userId: number, 
  data: Partial<User>
): AsyncGenerator<Operation<any>, User, any> {
  yield log(`Updating user ${userId}`);

  const user = yield getUser(userId);
  if (!user) throw new Error('User not found');

  return user; // TypeScript knows this returns User
}

Composing Workflows

Real applications need to compose smaller workflows:

// Helper to run sub-workflows
const runWorkflow = (workflowGenerator) => async (context) => {
  const execute = runtime(workflowGenerator);
  return execute(context);
};

// Compose workflows
async function* createUserWithProfile(userData, profileData) {
  yield log('Creating user account');

  // Run sub-workflow
  const user = yield runWorkflow(function* () {
    yield log('Validating user data');
    const isValid = yield validateUserData(userData);
    if (!isValid) throw new Error('Invalid user data');

    const newUser = yield createUser(userData);
    yield sendWelcomeEmail(newUser.email);
    return newUser;
  });

  // Run another sub-workflow
  const profile = yield runWorkflow(function* () {
    yield log('Creating user profile');
    const newProfile = yield createProfile(user.id, profileData);
    yield indexProfileForSearch(newProfile);
    return newProfile;
  });

  yield log('User and profile created');
  return { user, profile };
}

🤔 Check Your Understanding #3

What's the difference between yield getUser(1) and yield runWorkflow(...)?
Why do we need the runWorkflow helper?
Can workflows call other workflows recursively?

Answers

getUser(1) yields an operation, runWorkflow(...) yields a workflow executor
To execute sub-generators within our main generator
Yes! Workflows can call other workflows, enabling full composition

When to Use This Pattern

✅ Use it when:

You have complex business workflows with many dependencies
You're tired of dependency passing through multiple layers
You want highly testable code
You need to swap implementations (test vs production)
You're building multi-step processes
You want clean separation of concerns

❌ Don't use it when:

You have simple, flat code structure
Your team isn't comfortable with generators
You're building a library (generators aren't tree-shakeable)
You need to support very old browsers

Your Next Steps

Copy the 16-line runtime from this article
Convert one function in your codebase that has dependency passing
Create your first operations - start with logging
Build your operation library for your domain
Share your experience - what worked? what didn't?

Here's a starter template:

// runtime.js - The 16-line runtime
export function runtime(generatorFunction) {
  return async function execute(context) {
    const generator = generatorFunction();
    let result = await generator.next();

    while (!result.done) {
      const operation = result.value;
      try {
        const operationResult = await operation(context);
        result = await generator.next(operationResult);
      } catch (error) {
        result = await generator.throw(error);
      }
    }

    return result.value;
  };
}

// operations.js - Your operation library
export const log = (msg) => (ctx) => ctx.logger.info(msg);
export const getUser = (id) => (ctx) => ctx.db.users.findById(id);
export const createUser = (data) => (ctx) => ctx.db.users.create(data);
// Add more as needed...

// workflows/user.js - Your business logic
import { log, getUser, createUser } from '../operations.js';

export async function* createUserWorkflow(userData) {
  yield log('Creating new user');

  const existingUser = yield getUser(userData.email);
  if (existingUser) {
    throw new Error('User already exists');
  }

  const user = yield createUser(userData);
  yield log(`User ${user.id} created`);

  return user;
}

// app.js - Wire it together
import { runtime } from './runtime.js';
import { createUserWorkflow } from './workflows/user.js';

const context = {
  logger: console,
  db: {
    users: {
      findById: async (id) => {/* your implementation */},
      create: async (data) => {/* your implementation */}
    }
  }
};

const createUser = runtime(() => 
  createUserWorkflow({ email: 'test@example.com', name: 'Test' })
);

const user = await createUser(context);

Conclusion

In just 16 lines of runtime code, we've built a powerful pattern that eliminates entire categories of problems. The beauty is in its simplicity: generators pause, the runtime provides what they need, they resume.

This isn't just a clever trick - it's a fundamental architectural pattern that scales from simple scripts to complex applications. The same principle that powers Redux-Saga, Effect-TS, and other production systems is now yours to use.

The key insight is the shift from PUSH to PULL:

PUSH: Force dependencies through every function
PULL: Let functions request what they need

This simple change transforms how you structure applications. No more dependency passing through layers of functions. No more tightly coupled code. Just clean, testable, composable workflows.

Start small. Copy the runtime. Convert one function. Experience the freedom.

Found this useful? Share it with your team. The pattern is powerful, but it's even better when everyone understands it.

The JavaScript Library for the DOM You Don't Control

Patrick G — Fri, 11 Jul 2025 18:17:44 +0000

I want you to think about a specific, and very common, kind of web development. It’s not the pristine, greenfield world of a brand-new Next.js or SvelteKit application.

It’s messier. I’m talking about adding features to a big, server-rendered Rails or Django app. I’m talking about writing a user script to enhance a third-party website. I’m talking about building a Chrome extension that needs to inject life into pages you have no control over.

In this world, the classic JavaScript approach falls apart.

// You write this on Monday. It works.
document.querySelectorAll('.product-card .add-to-cart').forEach(button => {
  button.addEventListener('click', () => { /* ... */ });
});

// On Tuesday, a new feature loads more products.
// None of the new buttons work. Your JavaScript is broken.

The fundamental issue is that most JavaScript assumes a stable DOM. Components mount once, manage their own lifecycle, and live in a world where they control their own rendering. But what if you don't control the rendering? What if the server can replace your DOM at any moment?

You could reach for a full framework like React, but then you're committed to client-side rendering, build tools, and explaining to your team why a simple form enhancement now requires a complete architectural overhaul.

For years, jQuery offered a elegant solution to this exact problem with .live(). You could attach event listeners to elements that didn't exist yet:

// jQuery's magical .live() - worked on future elements
$('.add-to-cart').live('click', handleAddToCart);

It was brilliant. No matter when those .add-to-cart buttons appeared in the DOM, they would automatically have click handlers. But .live() had its own problems: state management was a nightmare, cleanup was manual and error-prone, and performance suffered as the DOM grew larger.

When jQuery deprecated .live() in favor of .on(), we lost the intuitive "just make it work" approach that made dynamic content feel manageable.

Introducing Watch

Watch is a JavaScript library that embraces DOM chaos rather than fighting it. It's the spiritual successor to jQuery's .live(), rebuilt for the modern era with components, state management, and automatic cleanup. Watch is built on a simple premise: you declare behaviors for CSS selectors, and those behaviors persist no matter what the server throws at you.

import { watch } from 'watch-selector';

// This works on Monday, Tuesday, and every day after
watch('.product-card .add-to-cart', function* () {
  yield on('click', handleAddToCart);
});

The Secret Sauce: Generators as Component Contexts

Here's where Watch makes its most important design decision. Instead of callbacks or classes, it uses generators as the foundation for component behavior. This is the key that makes everything else work so elegantly.

Let's look at the classic "click counter" problem. The traditional, intuitive first draft fails spectacularly because the state is shared across all instances:

// This fails. The `clicks` variable is shared by all buttons.
let clicks = 0;
document.querySelectorAll('button').forEach(btn => {
  btn.addEventListener('click', () => {
    clicks++;
    btn.textContent = `Clicked ${clicks} times`;
  });
});

Here is the Watch way:

// Each button gets its own persistent, isolated world.
watch('.counter-btn', function* () {
  let count = 0; // This state is scoped ONLY to this one button!

  yield text(`Clicked ${count} times`); // Set initial text

  yield click(() => {
    count++; // The state persists across clicks.
    yield text(`Clicked ${count} times`);
  });

  // When the button is removed from the DOM, this entire context,
  // including the state and event listener, is automatically garbage collected.
});

This is the "aha!" moment. The generator function creates a persistent execution context for each matching element. Unlike callbacks that execute and disappear, generators maintain their state between yields, creating a perfect, lightweight component lifecycle with three crucial properties:

Isolated State: Each button gets its own count variable.
Persistent Context: The state survives across multiple interactions and events.
Automatic Cleanup: When an element is removed, its generator instance is discarded. No memory leaks.

It's everything .live() promised, but with a modern component model you're used to.

The "Un-Component" Philosophy

Watch represents a different philosophy from Web Components or framework-based approaches. Instead of replacing HTML with custom elements, Watch enhances existing HTML with rich behavior.

You're not creating new kinds of elements; you're creating new behaviors for existing ones. This "enhancement over replacement" approach solves real problems:

No Build Tools Required: Drop in a script tag and start writing components
Works with Any Backend: Your Rails, Django, or PHP app doesn't need to change
CSS Just Works: No Shadow DOM isolation to fight with
Progressive Enhancement: Start simple, add complexity only where needed
Team Friendly: Different teams can enhance the same elements without conflicts

Compare this to Web Components, which require you to define custom elements, manage Shadow DOM, and convince your entire stack to adopt new HTML tags. Or framework approaches, which require you to abandon server-side rendering and commit to client-side architecture. It’s like jQuery’s ethos, but with modern primitives and a real component model.

A System for Composition

Where most tools give you components that render DOM, Watch gives you behaviors that attach to it. That shift unlocks a surprising amount of composability.

🧱 Layering Behavior

Let’s say Team A owns cart logic, and Team B wants to track analytics. Watch lets both teams enhance the same element—no coordination required.

// Cart logic
const productCard = watch('.product-card', function* () {
  const inCart = createState('inCart', false);
  yield on('click', '.add-btn', () => inCart.set(true));
});

// Analytics logic
productCard.layer(function* () {
  const productId = self().dataset.productId;
  yield onVisible(() => analytics.track('product-viewed', { id: productId }));
});

✅ Takeaway: Layers let you stack behaviors like middleware—cleanly, safely, and independently.

🌲 Parent-Child Composition

Need interaction between components? Watch handles parent-child structure through functional composition, not global state or props.

// A reusable counter component
function* counterWidget() {
  let count = 0;
  yield text(`Count: ${count}`);
  yield click(() => {
    count++;
    yield text(`Count: ${count}`);
  });

  return {
    getCount: () => count,
    reset: () => {
      count = 0;
      yield text(`Count: ${count}`);
    }
  };
}

In the parent:

watch('.dashboard', function* () {
  const counters = child('.counter', counterWidget);

  yield click('.reset-all', () => {
    for (const api of counters.values()) api.reset();
  });
});

✅ Takeaway: Components don’t just render—they expose APIs. You get clean, scoped communication without a framework.

🧩 Higher-Order Behavior

Now imagine you want error handling, feature flags, and performance tracking—without jamming it into every component manually.

Watch supports behavior composition out of the box:

const composedEnhancer = compose(
  gen => withFeatureFlag('new-widget-ui', gen),
  gen => withErrorBoundary(gen, '<p>Widget failed to load.</p>'),
  gen => withPerformanceMonitoring('MySuperWidget', gen)
);

Your core logic stays focused:

const enhancedWidget = composedEnhancer(function* mySuperWidget() {
  const count = createState('count', 0);
  yield text(`Clicked ${count.get()} times`);
  yield click(() => {
    count.update(c => c + 1);
    yield text(`Clicked ${count.get()} times`);
  });
});

watch('.super-widget', enhancedWidget);

✅ Takeaway: compose() gives you declarative pipelines for UI behavior—just like middleware, but for components.

Finding Watch's Niche

These are valid alternatives, and I considered them carefully when building Watch. Here's why I chose a different path:

Alpine.js is excellent for declarative interactions. The key difference is architectural: Alpine encourages you to place logic and state directly in your HTML (<div x-data="{ count: 0 }" x-on:click="count++">), while Watch keeps all logic in JavaScript using selectors to connect it to the DOM.

<!-- Alpine approach -->
<div x-data="{ count: 0 }" x-on:click="count++">
  <span x-text="count"></span>
</div>

// Watch approach
watch('[data-counter]', function* () {
  let count = 0;
  yield text(count);
  yield on('click', () => {
    count++;
    yield text(count);
  });
});

Watch is a better fit if you prefer clean separation of concerns, want the full power of TypeScript for complex logic, or need the kind of programmatic composition patterns I've shown above.

Web Components work well when you control the entire application, but they're a non-starter for our use cases. You can't get third-party sites to adopt your <my-awesome-button> custom elements. Watch enhances existing HTML instead of requiring custom tags.

More importantly, Web Components come with significant overhead:

Shadow DOM isolation fights with existing CSS
Custom element registration requires polyfills in older browsers
The imperative lifecycle API (connectedCallback, disconnectedCallback) is verbose compared to Watch's declarative approach

Watch sidesteps these issues by working with standard HTML and CSS, making it perfect for browser extensions, userscripts, and server-rendered applications.

When Watch Shines (And When It Doesn't)

So, who is this for? Watch sits in a fascinating middle-ground, somewhere between the "bag of utilities" feel of jQuery and the structured component model of modern frameworks. It provides structure without forcing a complete architectural commitment.
It works well when you find yourself in these scenarios:

Browser extensions that enhance third-party sites
Userscripts that add functionality to existing pages
HTMX applications where the server controls rendering
Legacy modernization where you're gradually replacing jQuery

Not ideal for:

Single-page applications where you control the entire rendering pipeline
Performance-critical applications that need virtual DOM optimizations
Teams fully committed to React/Vue ecosystems
Simple sites that don't need complex interactions

Watch isn't trying to replace React—it's here to solve a different class of problems. The ones that exist in the messy, unpredictable, and often uncontrollable reality of web development.

The Bigger Picture

Watch represents a return to the web's core philosophy: progressive enhancement. The idea that you start with working HTML and gradually layer on richer interactions.

In a time where frameworks own everything on the page, Watch suggests a different approach: embrace the chaos, listen to the DOM, and build behaviors that adapt.

Sometimes the most elegant solution isn't to own the DOM, but to watch it come to life.

Ready to give it a try? Check out the README and let me know what you think. Watch is still evolving, and feedback from real-world usage helps make it better.

DEV Community: Patrick G

Proposed API Reference

API overview

Informative TypeScript declarations

Terminology

Dependency

Invalidation

Completion

Notification callback

The revision clock

Value revision

Watched

The Dependency protocol

The revision extension

Notification dispatch

Snapshot semantics

Re-entrancy

Notification restrictions

Listener failures

Reactive.batch(callback)

Semantics

Failure semantics

Interaction with source deduplication

Reactive.createSource(options)

Source.prototype.invalidate()

Example

Source.prototype.revision()

Source.prototype.onInvalidate(listener)

Source.prototypeSymbol.dispose

Reactive.derive(dependencies, compute, options)

Arguments

Construction behavior

Reactive.deriveDynamic(selectionDependencies, resolveDependencies, compute, options)

Selection dependencies

Resolver

Computation dependencies

When the resolver runs

Derivation states

Watched and unwatched derivations

A Smaller Foundation for JavaScript Reactivity

A Smaller Signals Standard

Why smaller?

Protocol interoperability, not graph unification

Same architecture, different dependency discovery

Why explicit dependencies might matter for a standard

State stays where it is

Equality becomes a framework decision

Scheduling stays with frameworks

Safety during propagation

Explicit cleanup instead of hidden liveness

Asymmetry

What this maps to

What this gives up

The actual disagreement

The Hidden Type System of Reactive Code

Operation Logs

Keyed Caches

Reactive DAGs

Dynamic Dependencies

Predicates as Type Boundaries

One Structure, Different Machinery

The Problem

How to Build a JavaScript Framework

Step 1: Bring your UI into JavaScript

Step 2: Turn the data into UI

Constructing one element

Adding attributes

Adding text children

Constructing children recursively

Rendering the result

Making descriptions easier to write

Adding events

Step 3: Give yourself a way to update the data

A counter with no components

Writing update()

Spotting the pattern

Formalizing the pattern

Representing a component

Constructing components

The whole thing

Writing `update()`