DEV Community: YAMAMOTO Yuji

Flexiblly Extend Nested Structures - "Trees that Grow" in TypeScript

YAMAMOTO Yuji — Mon, 20 Mar 2023 05:08:42 +0000

Among Haskell developers familiar with ASTs, an idiom called Trees that Grow is so common that their most popular compiler GHC adopts it. Today, I'll share you with how to implement the idea in TypeScript.

Summary

In Haskell, the "Tree-Decoration Problem" is solved by combining open type families with the base nested type, while TypeScript doesn't support open type families (at least no straightforward approach). But I found that open type families are not necessary because the actual key to solving the "Tree-Decoration Problem" is packing up type parameters into one structure. TypeScript supports it with Indexed Access Types, but as far as I know, Haskell doesn't.

Some important part of the example code in this article is available with running examples in https://github.com/igrep/ts-that-grow. And you can run it directly in CodeSandbox.

Problem

Compilers written in a statically-typed language usually have their AST (abstract syntax tree) type somewhere in the source code to represent the target language's syntax. Most AST types are defined recursively, which makes them hard to extend by adding some additional information to each type of node.

As an example used everywhere in this article, let me define a simple AST type:

// An AST type for a fictitious language that supports
// only numeric literals, variables, assignment to a variable,
// function expressions, and calling a function.
type Expression = Literal | Variable | SetVariable | Func | CallFunc;

type Literal = {
  type: "Literal";
  value: number;
};

type Variable = {
  type: "Variable";
  name: string;
};

type SetVariable = {
  type: "SetVariable";
  name: string;
  value: Expression;
};

type Func = {
  type: "Func";
  argumentName: string;
  body: Expression;
};

type CallFunc = {
  type: "CallFunc";
  function: Expression;
  argument: Expression;
};

This is the basic type containing just the essential information of each node. We'll fill it with richer data for different use cases.

Say, let's add the location where each node is found in the source file:

type Expression = Literal | Variable | SetVariable | Func | CallFunc;

type Location = { row: number; column: number };

type Literal = {
  type: "Literal";
  value: number;
  location: Location;
};

type Variable = {
  type: "Variable";
  name: string;
  location: Location;
};

type SetVariable = {
  type: "SetVariable";
  name: string;
  value: Expression;
  location: Location;
};

type Func = {
  type: "Func";
  argumentName: string;
  body: Expression;
  location: Location;
};

type CallFunc = {
  type: "CallFunc";
  function: Expression;
  argument: Expression;
  location: Location;
};

We could also, qualify the variable names after resolving where every variable comes from:

type Expression = Literal | Variable | SetVariable | Func | CallFunc;

type Location = { row: number; column: number };

type Literal = {
  type: "Literal";
  value: number;
  location: Location;
};

type Variable = {
  type: "Variable";
  name: string;
  location: Location;
  namespace: { qualifier: string }
};

type SetVariable = {
  type: "SetVariable";
  name: string;
  value: Expression;
  location: Location;
  namespace: { qualifier: string }
};

type Func = {
  type: "Func";
  argumentName: string;
  body: Expression;
  location: Location;
};

type CallFunc = {
  type: "CallFunc";
  function: Expression;
  argument: Expression;
  location: Location;
};

And we might want to add even more!

But here is a problem: not all properties are always necessary or available. Thus adding an extension to the single type would result in an overload. We should split the types for separation of concerns.

Of course, we often see this kind of problem for any complex types we define for daily life as a programmer. In such a case, we may intuitively think of a solution that is just wrapping the top-level of the Expression type:

type Expression = Literal | Variable | SetVariable | Func | CallFunc;

type Location = { row: number; column: number };

type ExpressionWithLocation = Expression & Location;

...

This does not work when the type is recursive. For example in Expression, several kinds of nodes (namely SetVariable, Func, and CallFunc) contain Expression itself. Hence the & Location of ExpressionWithLocation is not applied to the Expression inside such nodes. This is the "Tree-Decoration Problem".

Incomplete Solution 1: Parameterize an Extension to Pass Around

You might invent one thing after reading the last example: "How about parameterizing Location?":

type Expression<Extension> =
  Literal<Extension> | Variable<Extension> | SetVariable<Extension> | Func<Extension> | CallFunc<Extension>;

type Location = { row: number; column: number };

type ExpressionWithLocation = Expression<Location>;

type Literal<Extension> = {
  type: "Literal";
  value: number;
} & Extension;

type Variable<Extension> = {
  type: "Variable";
  name: string;
} & Extension;

type SetVariable<Extension> = {
  type: "SetVariable";
  name: string;
  value: Expression<Extension>;
} & Extension;

type Func<Extension> = {
  type: "Func";
  argumentName: string;
  body: Expression<Extension>;
} & Extension;

type CallFunc<Extension> = {
  type: "CallFunc";
  function: Expression<Extension>;
  argument: Expression<Extension>;
} & Extension;

& Extension is now applied to every type of node by replacing all of the Expressions with Expression<Extension>, including ones in SetVariable, Func, and CallFunc.

Yes, this does perfectly with Location, and sometimes fairly enough to avoid extra complexity. But this approach doesn't allow us to make the ExpressionWithNamespace type: namespace should be added only to the Variable and SetVariable nodes.

To generalize the problem, if we have extensions that add fields that differ by node type, parameterizing with a single type variable isn't sufficient.

According to the paper I referred to at the beginning of this article, the GHC developers were faced with the same problem. GHC's AST type HsSyn is used across various compiler phases with different addition to the core AST, and some external libraries also want to reuse the HsSyn with their customization. Before inventing "Trees that Grow", they had to make a compromise with some imperfect solutions such as creating independent AST types.

Solutions

Follow the Original Idea: Use Type Families

The "Trees that Grow" paper overcame the "Tree-Decoration Problem" with open type families. Unfortunately, TypeScript doesn't support open type families. The first page I found by googling with "typescript type family" introduces TypeScript's type families, but they are only closed type families. "Open" type families and "closed" type families are different in that the former enables us to append a condition and the result type afterward. Let's grab the idea by imagining if TypeScript had the open type families feature to compare them.

First of all, review how closed type families are implemented in TypeScript:

type CloseTypeFamily<SomeType> =
  SomeType extends number ? boolean : string;

This is one of the simplest type families in TypeScript. A type family is a function over a type, which receives types as arguments and returns another type. The example CloseTypeFamily receives a type as SomeType, and if SomeType is number (or a subtype of number), it returns the boolean type, then returns the string type otherwise.

This is all about closed type families. They are just functions receiving and returning types. TypeScript doesn't have any special keyword for type families and is written so easily as above, therefore few people refer to the concept explicitly.

Next, it's time for open type families. Let me show an open type family by writing in a pseudo-TypeScript supporting it:

type OpenTypeFamily<SomeType extends number> = boolean;
type OpenTypeFamily<SomeType extends string> = object[];
type OpenTypeFamily<SomeType extends any[]> = { another: "case", youCan: "add" };

Notice that there are multiple type declarations with the same name OpenTypeFamily, which TypeScript prohibits. This is open type families' indispensable feature that they are open to extending by adding other conditions of the arguments and the return type when the arguments satisfy them.

How does OpenTypeFamily behave after being declared multiple times? If I were the designer of the open type families feature of TypeScript, I would make it do like below:

type OpenTypeFamily<number>   // Returns boolean.
type OpenTypeFamily<string>   // Returns object[].
type OpenTypeFamily<number[]> // Returns { another: "case", youCan: "add" }.
type OpenTypeFamily<boolean>  // Type error because no matching argument is provided.

I omit the detailed rationale here because it's not important for this article. But speaking in short, an open type family searches all the declared conditions for one matching best with the given argument types to decide which type to return.

Simulate Open Type Families Using Global Interfaces

As described at the beginning of the last section, TypeScript doesn't provide open type families. But it doesn't actually need the complete functionality of the open type families just to reproduce "Trees that Grow". TypeScript already has a feature that resembles open type families as well as it can satisfy the requirement of "Trees that Grow".

The answer is interface. We can use TypeScript's interface as a type family that receives a string literal type¹ to return a type:

interface TypeFamily {
  foo: boolean;
  bar: object[];
  baz: { another: "type"; };
}

TypeFamily["foo"] // Returns boolean.
TypeFamily["bar"] // Returns object[].
TypeFamily["baz"] // Returns { another: "type"; }.

Try in the playground.

Thanks to Indexed Access Types, we can see an interface as a type family that takes a key type via the indexing operator.

We can pass even a parameterized key type:

interface TypeFamily {
  foo: boolean;
  bar: object[];
  baz: { another: "type"; };
}

type GetTheValueType<Key extends keyof TypeFamily> = TypeFamily[Key];

GetTheValueType<"foo"> // Returns boolean.
GetTheValueType<"bar"> // Returns object[].
GetTheValueType<"baz"> // Returns { another: "type"; }.

Try in the playground

This is why an interface can be a type family. Then, how about its openness? To tell the truth, an interface is by design open to extending:

// Append to the last example
interface TypeFamily {
  anotherProperty: string;
}

GetTheValueType<"anotherProperty"> // Returns string.

Try in the playground

If a module contains several interface declarations with the same name, TypeScript interprets them as a unified single interface (See Merging Interfaces in the document for details).

But there is still an obstacle: Merging declarations of interface is limited within the module. This makes interface not suitable for "Trees that Grow" because it requires the type family extendable across modules (I'll show that with an example later).

For a workaround for this issue, we have to declare the interface within a declare global:

declare global {
  interface TypeFamily {
    foo: boolean;
    bar: object[];
    baz: { another: "type"; };
  }
}

// ... In another file ...
declare global {
  interface TypeFamily {
    anotherProperty: string;
  }
}

declare global makes TypeFamily literally "globally available"². Now we can append new definitions to TypeFamily anywhere anytime.

Make `Expression` Extensible with a Global Interface

In the last section, we finally got all stuff necessary to implement "Trees that Grow". It's time to introduce the solution for the "Tree-Decoration Problem" in TypeScript using global interfaces to simulate open type families.

To begin with, I'll show you the original, non-extensible Expression type again:

type Expression = Literal | Variable | SetVariable | Func | CallFunc;

type Literal = {
  type: "Literal";
  value: number;
};

type Variable = {
  type: "Variable";
  name: string;
};

type SetVariable = {
  type: "SetVariable";
  name: string;
  value: Expression;
};

type Func = {
  type: "Func";
  argumentName: string;
  body: Expression;
};

type CallFunc = {
  type: "CallFunc";
  function: Expression;
  argument: Expression;
};

Let me update to make this type extensible step by step in the following paragraphs.

First, add a new type parameter to every type of node of Expression and Expression itself:

type Expression<Descriptor> =
  | Literal<Descriptor>
  | Variable<Descriptor>
  | SetVariable<Descriptor>
  | Func<Descriptor>
  | CallFunc<Descriptor>;

type Literal<Descriptor> = {
  type: "Literal";
  value: number;
};

type Variable<Descriptor> = {
  type: "Variable";
  name: string;
};

type SetVariable<Descriptor> =
  {
    type: "SetVariable";
    name: string;
    value: Expression<Descriptor>;
  };

type Func<Descriptor> = {
  type: "Func";
  argumentName: string;
  body: Expression<Descriptor>;
};

type CallFunc<Descriptor> = {
  type: "CallFunc";
  function: Expression<Descriptor>;
  argument: Expression<Descriptor>;
};

Second, introduce a global interface with just one property for each type of node:

declare global {
  interface ExtendExpression {
    plain: object;
  }
  interface ExtendLiteral {
    plain: object;
  }
  interface ExtendVariable {
    plain: object;
  }
  interface ExtendSetVariable {
    plain: object;
  }
  interface ExtendFunc {
    plain: object;
  }
  interface ExtendCallFunc {
    plain: object;
  }
}

Those Extend* interfaces will serve as open type families. The only property plain represents "no extensions", used as the default extension to Expression.

Next, restrict the type parameter to each node type of Expression to be one of the keys of the Extend* interfaces:

type Expression<Descriptor extends keyof ExtendExpression> =
  | Literal<Descriptor>
  | Variable<Descriptor>
  | SetVariable<Descriptor>
  | Func<Descriptor>
  | CallFunc<Descriptor>;

type Literal<Descriptor extends keyof ExtendLiteral> = {
  type: "Literal";
  value: number;
};

type Variable<Descriptor extends keyof ExtendVariable> = {
  type: "Variable";
  name: string;
};

type SetVariable<Descriptor extends keyof ExtendSetVariable> =
  {
    type: "SetVariable";
    name: string;
    value: Expression<Descriptor>;
  };

type Func<Descriptor extends keyof ExtendFunc> = {
  type: "Func";
  argumentName: string;
  body: Expression<Descriptor>;
};

type CallFunc<Descriptor extends keyof ExtendCallFunc> = {
  type: "CallFunc";
  function: Expression<Descriptor>;
  argument: Expression<Descriptor>;
};

Note that each node type takes a differently restricted type parameter: ExtendLiteral for Literal, ExtendVariable for Variable, etc. This is the important point that enables us to append different properties to each node.

And, as the final step, extend every type of node with the corresponding Extend* interface using the intersection operator & and pass the type parameter Descriptor as an indexed access type of the Extend*:

type Literal<Descriptor extends keyof ExtendLiteral> = {
  type: "Literal";
  value: number;
} & ExtendLiteral[Descriptor]; // <- Append this!

type Variable<Descriptor extends keyof ExtendVariable> = {
  type: "Variable";
  name: string;
} & ExtendVariable[Descriptor]; // <- Append this!

type SetVariable<Descriptor extends keyof ExtendSetVariable> =
  {
    type: "SetVariable";
    name: string;
    value: Expression<Descriptor>;
  } & ExtendSetVariable[Descriptor]; // <- Append this!

type Func<Descriptor extends keyof ExtendFunc> = {
  type: "Func";
  argumentName: string;
  body: Expression<Descriptor>;
} & ExtendFunc[Descriptor]; // <- Append this!

type CallFunc<Descriptor extends keyof ExtendCallFunc> = {
  type: "CallFunc";
  function: Expression<Descriptor>;
  argument: Expression<Descriptor>;
} & ExtendCallFunc[Descriptor]; // <- Append this!

Then, how can we add properties as we like? Extend all global Extend* interfaces. For example, to add the namespace property only to Variable and SetVariable, add it to Extend* interfaces:

declare global {
  interface ExtendExpression {
    namespace: object;
  }
  interface ExtendLiteral {
    namespace: object;
  }
  interface ExtendVariable {
    namespace: { qualifier: string };
  }
  interface ExtendSetVariable {
    namespace: { qualifier: string };
  }
  interface ExtendFunc {
    namespace: object;
  }
  interface ExtendCallFunc {
    namespace: object;
  }
}

To leave the other types of nodes unextended, their namespace is object, which stands for "any object". As typescript-eslint recommends, I use object instead of {} for "any object type", which is the identity element (which doesn't change anything that is applied with) of the intersection operator &.

Now, see the result by actually using the Expression type by passing the name of the new property:

type MyExpression = Expression<"namespace">;

Let's confirm how Expression is extended by expanding the type aliases step by step:

// (1) By definition of `Expression`,
//     replace the `Descriptor` type argument to `"namespace"`:
type Expression<"namespace"> =
  | Literal<"namespace">
  | Variable<"namespace">
  | SetVariable<"namespace">
  | Func<"namespace">
  | CallFunc<"namespace">;

// (2A) By definition of `Literal`:
type Literal<"namespace"> = {
  type: "Literal";
  value: number;
} & ExtendLiteral["namespace"];

// (3A) By definition of `ExtendLiteral`,
//     `ExtendLiteral["namespace"]` is `object`:
type Literal<"namespace"> = {
  type: "Literal";
  value: number;
} & object;

// (4A) Appending `object` with `&` makes no change:
type Literal<"namespace"> = {
  type: "Literal";
  value: number;
};

(2A)-(4A) applies to the Func and CallFunc types. Go on to expand the Variable type:

/* (Continued from (1) above) */

// (2B) By definition of `Variable`:
type Variable<"namespace"> = {
  type: "Variable";
  name: string;
} & ExtendVariable["namespace"];

// (3B) By definition of `ExtendVariable`,
//      `ExtendVariable["namespace"]` is `{ qualifier: string }`.
type Variable<"namespace"> = {
  type: "Variable";
  name: string;
} & { qualifier: string };

// (4B) By definition of the `&` operator:
type Variable<"namespace"> = {
  type: "Variable";
  name: string;
  qualifier: string;
}

(2B)-(3B) applies to the SetVariable type.

As the expansion before shows, only the Variable and SetVariable type is extended by the Expand* interfaces. Consequently, we found a method to solve the "Tree-Decoration Problem" by extending each globally declared interface.

New Problem: Can We Make it Simpler?

The workaround I explained in the previous sections is a port of the "Trees that Grow" technique in Haskell to TypeScript. It allows us to freely extend nested recursive types with additional properties just as necessary for applications using the types, via open type families (globally appendable interfaces in TypeScript).

But it involves a new problem: using declare global-ed interfaces is a very indirect way. Code readers that see the global interfaces for the first type would have difficulties in finding the relationship between the type to extend and them, similar to traditional global variables.

You might get confused by my explanation, to wish for an easier-to-understand solution. I'll invent and develop a much more succinct solution for TypeScript in the following sections.

Incomplete Solution 2: Parameterize Every Extension to Pass Around

As a first step, review again the "Incomplete Solution 1: Parameterize an Extension to Pass Around":

type Expression<Extension> =
  Literal<Extension> | Variable<Extension> | SetVariable<Extension> | Func<Extension> | CallFunc<Extension>;

type Literal<Extension> = {
  type: "Literal";
  value: number;
} & Extension;

type Variable<Extension> = {
  type: "Variable";
  name: string;
} & Extension;

type SetVariable<Extension> = {
  type: "SetVariable";
  name: string;
  value: Expression<Extension>;
} & Extension;

type Func<Extension> = {
  type: "Func";
  argumentName: string;
  body: Expression<Extension>;
} & Extension;

type CallFunc<Extension> = {
  type: "CallFunc";
  function: Expression<Extension>;
  argument: Expression<Extension>;
} & Extension;

The problem with this solution is that it cannot switch the extension type by a different type of node because Expression has only one type parameter.

In other words, that means it can fix the problem by passing type parameters as many as the node types:

type Expression<
  ExtendLiteral,
  ExtendVariable,
  ExtendSetVariable,
  ExtendFunc,
  ExtendCallFunc,
> =
  | Literal<ExtendLiteral>
  | Variable<ExtendVariable>
  | SetVariable<
      ExtendLiteral,
      ExtendVariable,
      ExtendSetVariable,
      ExtendFunc,
      ExtendCallFunc
    >
  | Func<
      ExtendLiteral,
      ExtendVariable,
      ExtendSetVariable,
      ExtendFunc,
      ExtendCallFunc
    >
  | CallFunc<
      ExtendLiteral,
      ExtendVariable,
      ExtendSetVariable,
      ExtendFunc,
      ExtendCallFunc
    >;

// ... Types of nodes go on ...

You'll find the type parameters (ExtendLieteral, ExtendVariable, ...) are so repetitiously referenced at the first glance. This is because SetVariable, Func, and CallFunc contain Expression as their child nodes.

And as a matter of course, the type parameters have to be passed down again in their definition. For example in CallFunc:

type CallFunc<
  ExtendLiteral,
  ExtendVariable,
  ExtendSetVariable,
  ExtendFunc,
  ExtendCallFunc,
> = {
  type: "CallFunc";
  function: Expression<
    ExtendLiteral,
    ExtendVariable,
    ExtendSetVariable,
    ExtendFunc,
    ExtendCallFunc
  >;
  argument: Expression<
    ExtendLiteral,
    ExtendVariable,
    ExtendSetVariable,
    ExtendFunc,
    ExtendCallFunc
  >;
} & ExtendCallFunc;

The repetition of the type arguments is not only noisy but also hard to maintain. We have to keep the order of the parameters consistent across the node types anytime when adding/removing a node type. This is unsatisfactory.

Final Solution: Packing up Type Parameters Into One Structure

From our programming experience with an ordinary function, we usually fix such a problem by making all the arguments available as a single structure to pass around to all the callee functions:

type Arguments = {
  foo: string;
  bar: number;
  baz: boolean;
  qux: number | undefined;
  quux: string[];
};

function callee1(arguments: Arguments);
function callee2(arguments: Arguments);

function rootCaller(arguments: Arguments) {
  // ...
  callee1(arguments);
  // ...
  callee2(arguments);
  // ...
}

// v.s. Unpacking all the arguments like below:

function callee1(foo: string, bar: number, baz: boolean, qux: number | undefined, quux: string[]);
function callee2(foo: string, bar: number, baz: boolean, qux: number | undefined, quux: string[]);

function rootCaller(foo: string, bar: number, baz: boolean, qux: number | undefined, quux: string[]) {
  // ...
  callee1(foo, bar, baz, qux, quux);
  // ...
  callee2(foo, bar, baz, qux, quux);
  // ...
}

In Haskell, we have to reproduce that indirectly via open type families. Meanwhile, in TypeScript, we can easily achieve the goal by combining an interface with Indexed Access Types in fact:

// Interface with one property per node type.
interface ExtendExpression {
  Literal: object;
  Variable: object;
  SetVariable: object;
  Func: object;
  CallFunc: object;
}

// Specify the default type for `Extend` to make it easier to use.
type Expression<Extend extends ExtendExpression = ExtendExpression> =
  | Literal<Extend>
  | Variable<Extend>
  | SetVariable<Extend>
  | Func<Extend>
  | CallFunc<Extend>;

type Literal<Extend extends ExtendExpression = ExtendExpression> = {
  type: "Literal";
  value: number;
} & Extend["Literal"];

type Variable<Extend extends ExtendExpression = ExtendExpression> = {
  type: "Variable";
  name: string;
} & Extend["Variable"];

type SetVariable<Extend extends ExtendExpression = ExtendExpression> = {
  type: "SetVariable";
  name: string;
  value: Expression<Extend>;
} & Extend["SetVariable"];

type Func<Extend extends ExtendExpression = ExtendExpression> = {
  type: "Func";
  argumentName: string;
  body: Expression<Extend>;
} & Extend["Func"];

type CallFunc<Extend extends ExtendExpression = ExtendExpression> = {
  type: "CallFunc";
  function: Expression<Extend>;
  argument: Expression<Extend>;
} & Extend["CallFunc"];

Each property of the ExtendExpression interface is for the corresponding type of node. Hence, we can extract only part of the Extend type variable for each type of node, as well as we can handily pass around the Extend to the child node types.

Example

I created a trivial example with a function to convert a raw Expression into one whose variables are qualified with the namespace:

https://github.com/igrep/ts-that-grow/blob/main/src/app.ts

Try and see how it works!

Final Thoughts: Really Impossible in Haskell?

You might be surprised at the simplicity of the final solution in comparison with the other ideas shown before. But according to the original "Trees that Grow" paper, Haskell requires a relatively complex method using open type families. It seems that the biggest reason is that Haskell doesn't provide functionality similar to TypeScript's packing type arguments into a single structure.

From another perspective, the "packing" feature of TypeScript is a restricted version of higher-order type families (type families that takes type families, like higher-order functions) in a way: the Extend type variable of Expression can be seen as a type function that takes the name of its property and returns a type via Indexed Access Type.

By contrast, Haskell doesn't support higher-order type families at least in a straightforward way, due to the limitation of its type families (Ref. Higher order type families in Haskell - Stack Overflow). But I might miss something: I'll write up a separate post if I find a new technique in Haskell.

Strictly speaking, the argument type can be any that can be the key of an object, such as number and Symbol. ↩
I learned declare global in depth with this article (in Japanese). ↩

Why I failed to create the "Solid.js's store" for Svelte, and announcing svelte-store-tree v0.3.1

YAMAMOTO Yuji — Tue, 08 Nov 2022 04:54:22 +0000

Recently I released a new version of svelte-store-tree. It's a state management library for Svelte that I started to develop two months ago, and redesigned its API in the latest version. Today, let me introduce the detailed usage of svelte-store-tree, and compare with a similar library: Solid.js's store feature. Then, I'll share you with a problem of Svelte's store. I'm glad if this article helps you review the design of Svelte in the future.

Summary

svelte-store-tree is a state management library for managing tree-like nested structures in Svelte.
I referred a similar library, Solid.js's store, before creating it. But by contrast with Solid.js's store, svelte-store-tree requires selecting the value inside the store with its choose function to handle union type values. It's due to the design of Svelte's store that confines "the API to read the current value of the store" and "the API to update the value of the store" into a single store object.

Introduction to svelte-store-tree

As the name shows, svelte-store-tree adds¹ methods to the store objects of Svelte, to easily work with trees (nested structures). I developed it for building a complex tree structure intuitively in my current job with Svelte.

Example Usage

From this section, I'll use the type below in the example app you can run here.

export type Tree = string | undefined | KeyValue | Tree[];

export type KeyValue = {
  key: string;
  value: string;
};

It's really a recursive structure with various possible values.

NOTE: I uploaded the code of the example app onto GitHub, so I'll put the link to the corresponding lines in GitHub after quoting the part of the code.

Creating a `WritableTree` Object

To create a WritableTree object provided by svelte-store-tree, use the writableTree function literally:

export const tree = writableTree<Tree>([
  "foo",
  "bar",
  ["baz1", "baz2", "baz3"],
  undefined,
  { key: "some key", value: "some value" },
]);

In the same way with the original writable function, writableTree receives the initial value of the store as its argument. Because Tree is a union type, we should specify the type parameter to help type inference in the example above.

`subscribe` and `set` like the original store of Svelte

svelte-store-tree complies with the store contract of Svelte. Accordingly prefixing the variable name with a dollar sign $, we can subscribe WritableTree/ReadableTrees and set WritableTrees. Of course two-way binding to the part of the store tree is also available!

<script lang="ts">
  export let tree: WritableTree<Tree>;
  ...
</script>
...
{#if typeof $tree === "string"}
  <li>
    <NodeTypeSelector label="Switch" bind:selected {onSelected} /><input
      type="text"
      bind:value={$tree}
    />
  </li>
...
{/if}

See in GitHub

Create a `WritableTree` for a part of the tree by `zoom`

svelte-store-tree provides a way to make a store for some part of the tree as these methods whose name begins with zoom:

zoom<C>(accessor: Accessor<P, C>): WritableTree<C>
- Returns a new WritableTree object with an Accessor object.
- An Accessor object implements a method to get the child C from the parent P, and a method to replace the child C of the parent P.
zoomNoSet<C>(readChild: (parent: P) => C | Refuse): ReadableTree<C>
- Takes a function to get the child C from the parent P and then returns a ReadableTree object.
- ReadableTree is a store tree that can't set. But child store trees zoomed from a ReadableTree can set. So it is NOT completely read-only.

In the example app, I created WritableTrees for writing the key and value field of the KeyValue object, using the into function for building Accessors:

const key = tree.zoom(into("key"));
const value = tree.zoom(into("value"));

However, this isn't correct. svelte-check warns me of type errors detected by TypeScript:

/svelte-store-tree/example/Tree.svelte:14:35
Error: Argument of type 'string' is not assignable to parameter of type 'never'. (ts)
...


/svelte-store-tree/example/Tree.svelte:15:37
Error: Argument of type 'string' is not assignable to parameter of type 'never'. (ts)
...

The messages are somewhat confusing as it says parameter of type 'never'. The type checker means the result of keyof Tree is never because the type of tree is WritableTree<Tree>, whose content Tree is by definition a union type that can be undefined.

To fix the problem, we have to convert the WritableTree<Tree> into WritableTree<KeyValue> by some means. The choose function helps us in such a case.

Subscribe the value only fulfilling the condition using `choose`

We can create a store tree that calls the subscriber functions only if the store value matches with the specific condition, by calling zoom with an Accessor from the choose function.

Here I used the choose function in the example app:

...
const keyValue = tree.zoom(choose(chooseKeyValue));
...

choose takes a function receiving a store value to return some other value, or Refuse. The chooseKeyValue function is the argument of choose in the case above. It's defined as following:

export function chooseKeyValue(tree: Tree): KeyValue | Refuse {
  if (tree === undefined || typeof tree === "string" || tree instanceof Array) {
    return Refuse;
  }
  return tree;
}

See in GitHub

A WritableTree object returned by choose calls the subscriber functions when the result of the function (passed to choose) is not Refuse, a unique symbol dedicated for this purpose².

You might wonder why choose doesn't judge by a boolean value or refuse undefined instead of the unique symbol. First, the function given to choose must specify the return type to make use of the narrowing feature of TypeScript. The user-defined type guard doesn't help us with a higher-order function like choose. Second, I made the unique symbol Refuse to handle objects with nullable properties such as { property: T | undefined } properly.

Let's get back to the problem of converting the WritableTree<Tree> into WritableTree<KeyValue>. The error by tree.zoom(into("key")) is corrected using choose:

const keyValue = tree.zoom(choose(chooseKeyValue));
const key = keyValue.zoom(into("key"));
const value = keyValue.zoom(into("value"));

See in GitHub

Finally, we can two-way bind the key and value returned by zoom:

<dl>
  <dt><input type="text" bind:value={$key} /></dt>
  <dd><input type="text" bind:value={$value} /></dd>
</dl>

See in GitHub

Parents can react to updates by their children

All examples so far doesn't actually need svelte-store-tree. Just managing the state in each component would suffice instead of managing the state as a single large structure. Needless to say, svelte-store-tree does more: it can propagate updates in the children only to their direct parents.

For example, assume that the <input> bound with the key from the last example got new input.

<dl>
      <!--------- THIS <input> ------------->
  <dt><input type="text" bind:value={$key} /></dt>
  <dd><input type="text" bind:value={$value} /></dd>
</dl>

Then, the value set to key is conveyed to the functions subscribeing the key itself, or key's direct ancestors including keyValue. Functions subscribeing sibling stores such as value or the parents' siblings, don't see the update.

To illustrate, imagine the tree were shaped as follows:

When updating the Key, the update is propagated to the three stores: List 1, KeyValue, and Key.

The Value, string, List 2, and List 2's children don't know the update. Thus, Svelte can avoid extra rerenderings.

To demonstrate that feature, the example app sums up the number of the nodes in the tree by their type:

<script lang="ts">
  import TreeComponent from "./Tree.svelte";
  import { tree, type NodeType, type Tree } from "./tree";

  $: stats = countByNode($tree);
  function countByNode(node: Tree): Map<NodeType, number> {
    ...
  }
</script>

<table>
  <tr>
    <th>Node Type</th>
    <th>Count</th>
  </tr>
    {#each Array.from(stats) as [nodeType, count]}
  <tr>
      <td>{nodeType}</td>
      <td>{count}</td>
  </tr>
    {/each}
</table>
...

See in GitHub

V.S. Solid.js's Store

As I wrote in the beginning of this article, I referred Solid.js's store feature in developing svelte-store-tree v0.3.1 because it's made for the similar goal with svelte-store-tree. From now on, let me explain in what way svelte-store-tree is similar to Solid.js's store, and what feature of Solid.js's store it failed to support because of the limitation of Svelte's store, respectively. I hope this would be a hint for discussion on the future design of Svelte.

Quick introduction to Solid.js's Store

Solid.js's store, as the page I referred in the last section described as "Solid's answer to nested reactivity", enables us to update a part of nested structures and track the part of the state. The createStore function returns a pair of the current store value, and the function to update the store value (slightly similar to React's useState):

ℹ️ All examples in this section are quoted from the official web site.

const [state, setState] = createStore({
  todos: [
    { task: 'Finish work', completed: false },
    { task: 'Go grocery shopping', completed: false },
    { task: 'Make dinner', completed: false },
  ]
});

The first thing of the pair, state is wrapped by a Proxy so that the runtime can track access to the value of the store including its properties.

Using the second value of the pair setState, we can specify "path" objects, such as names of the properties and predicate functions to decide which elements to update (if the value is an array), to tell which part of the store value should be updated. For example:

// Set true to the `completed` property of the 0th and 2nd elements in the `todos` property.
setState('todos', [0, 2], 'completed', true);

// Append `'!'` to the `task` property of `todos` elements whose `completed` property is `true`.
setState('todos', todo => todo.completed, 'task', t => t + '!');

The setState is so powerful that it can update arbitrary depth of the nested structure without any other library functions.

In addition, as introduced before, Solid.js's store is designed for separately using the Proxy-wrapped value and the function to update, while Svelte's store is designed for using as a single object with set and subscribe to make it available for two-way binding.

Feature that affected svelte-store-tree

Somewhat affected by Solid.js's store, I improved the Accessor API of svelte-store-tree, used to show how to get deeper into the nested structure. Specifically, svelte-store-tree can now compose Accessor objects by their and method as the setState function of Solid.js (the second value of the createStore's result) can compose the "path" objects given as its arguments.

For example, by combining the into and isPresent Accessor, we can make a store that calls subscriber functions if its foo property is not undefined:

store.zoom(into('foo').and(isPresent()));

Thanks to them, the code to obtain the key property from the tree in the example app can be rewritten like below:

const key = tree.zoom(choose(chooseKeyValue).and(into("key")));

Why don't I define the zoom method to receive multiple Accessors to compose? One of the reasons is to simplify the implementation of zoom, and another is that it's not a good idea to pile up many Accessors at once to access to too deep part of the nested structure, in my opinion.

In detail, the former means that the code of zoom is more concise because it doesn't have to take care of multiple Accessors. Composing Accessors is just the business of the and method.

And the latter is a design issue. Diving several levels down into a nested structure at a time is like surgery for the internal: it incurs a risk that the code gets vulnerable to change. Besides, composing Accessors by listing them in the arguments can't work well for recursively nested structures, which I suppose to be a primary use case of svelte-store-tree. Because their depth varies dynamically.

I determined this design based on the usage I assumed, at the sacrifice of verbosity of composing the and methods.

Feature that svelte-store-tree failed to support

I made svelte-store-tree aim for "the Solid.js's store for Svelte". But I couldn't reproduce one of its features anyway: Solid.js does NOT need a feature equivalent to svelte-store-tree's choose function³. I wasted a section for describing choose in a way!

Why doesn't Solid.js's store require a feature like choose? That is related to its design that the object to read the store value and the function to update the store value are separated.

Solid.js's store can select the value only by branching in the component on its value using Show or Switch / Match (if statements in Solid.js).

The same seems appied to svelte-store-tree, but that isn't true. Recall the first example of choose:

<script lang="ts">
  // ...
  const keyValue = tree.zoom(choose(chooseKeyValue));
  const key = keyValue.zoom(into("key"));
  const value = keyValue.zoom(into("value"));
  // ...
</script>

{#if typeof $tree === "string"}
  ...
{:else if $tree === undefined}
  ...
{:else if $tree instanceof Array}
  ...
{:else}
  ...
  <dt><input type="text" bind:value={$key} /></dt>
  <dd><input type="text" bind:value={$value} /></dd>
  ...
{/if}

The two stores key and value are used only when the value of tree is neither string, undefined, nor Array, but KeyValue, as it's chosen by the {#if} ... {/if}. Getting key and value via choose(chooseKeyValue) is actually repeating the narrowing-down by the {#if} ... {/if}.

So you might try modify the component like following with {@const ...} after key and value are used only in the {:else}:

{:else}
  ...
  {@const key = tree.zoom(into("key"))}
  {@const value = tree.zoom(into("value"))}
  <dt><input type="text" bind:value={$key} /></dt>
  <dd><input type="text" bind:value={$value} /></dd>
  ...
{/if}

Though svelte-check raises an error about the {@const ...} below:

/svelte-store-tree/example/Tree.svelte:69:42
Error: Stores must be declared at the top level of the component (this may change in a future version of Svelte) (svelte)

It says that stores must be declared at the top-level⁴, thus you can't define a new store in a {@const ...} to subscribe. It's impossible to make a store only on a specific condition so far.

To avoid that error forcibly, you have the option to split out a component containing only <input type="text" bind:value={$key} /> and <input type="text" bind:value={$value} /> then make the component take a WritableTree<KeyValue>. However, there is still a type error: the branching beginning with {#if typeof $tree === "string"} narrows only $tree, that is the current value of tree, so doesn't narrow the tree to WritableTree<KeyValue> from WritableTree<Tree>. TypeScript doesn't take that into consideration.

Due to the problem I showed here, I gave up adding the feature following the exisiting convention of the store of Svelte.

Why do we have to narrow the store itself as well as its value in Svelte? Because Svelte assigns both the API to read the store value (subscribe) and the API to update (set etc.) to the same single object. I'll simplify WritableTree to explain the detail:

WritableTree<T> = {
  // Get the current value of the store.
  // I replaced the `subscribe` method with this for simplicity.
  get: () => T;

  // Set a new value of the store. This is same as the original `set`.
  set: (newValue: T) => void;
};

Let's give a concrete type such as number | undefined to WritableTree to instantiate a store whose value can contain undefined:

WritableTree<number | undefined> = {
  get: () => number | undefined;
  set: (newValue: number | undefined) => void;
};

Now, let's say we want to remove the undefined to convert it to WritableTree<number>. Code to use the get method of WritableTree<number> doesn't expect get to return undefined, consequently we have to make it return only number. Meanwhile code to write a number on WritableTree<number> just passes numbers to the set method, then we can reuse the function (newValue: number | undefined) => void as is⁵.

Hence, what we have to narrow is only the API to read the store value in fact. While Solid.js's store just has to narrow the current store value by branching, svelte-store-tree has to narrow down both the functions because it forces a single object to contain both the method to read and the method to set.

Technically speaking, I implemented svelte-store-tree by rewriting the code of the store after copy-and-pasting it. So it doesn't add the methods. ↩
"zoom", "choose", and "refuse" rhyme. ↩
The feature to filter the store value with predicate functions in Solid.js, sounds similar to choose, but it's available only when the store value is an array. Note that it's not for narrowing types as choose does. ↩
The top-level here seems to mean the top in the <script> block of the component. ↩
This difference is widely known as "covariant and contravariant". The Japanese book "Introduction to TypeScript for Those Who Wants to Be a Pro" (プロを目指す人のためのTypeScript入門) also explains. ↩

Divergent States in a "Single Source of Truth" Framework

YAMAMOTO Yuji — Thu, 07 Apr 2022 10:02:34 +0000

I'll tell you what I've learnt from struggling with a bug that made me lose a couple of weeks. The application framework used in this post is Hyperapp, but I guess the same problem can be found in frameworks based on transforming the state of "Single Source of Truth" with pure functions (such as Elm, Redux, so on) if we use them in a wrong way.

Introduction to Hyperapp with an Example App without the Bug

Hyperapp is a minimalistic framework that enables us to create virtual DOM based apps with architecture similar to The Elm Architecture (TEA). Hyperapp gives us both a view framework based on virtual DOM and a Redux-like state management framework without learning Elm with its smaller-than-favicon size.

Here is an example app of Hyperapp written in TypeScript¹. I'll use this app to demonstrate the problem. So it's much simpler than the app I'm actually developing, but may look too complicated as an example of Hyperapp. Sorry!

const buildInit = (): State => {
  const result = new Map();
  for (let i = 0; i < 3; ++i){
    const key1 = randomKey();
    result.set(key1, {});
    for (let j = 0; j < 3; ++j){
      const key2 = randomKey();
      result.get(key1)[key2] = false;
    }
  }
  return result;
};

// Action functions to update the State object
const SetTrue = (state: State, [key1, key2]: [string, string]): State => {
  const newState = new Map(state);
  const childState = newState.get(key1);
  newState.set(key1, {
    ...childState,
    [key2]: true,
  });
  return newState;
};
const SetFalse = (state: State, [key1, key2]: [string, string]): State => {
  const newState = new Map(state);
  const childState = newState.get(key1);
  newState.set(key1, {
    ...childState,
    [key2]: false,
  });
  return newState;
};

const view = (state: State) => {
  const children1 = [];
  // Side note: I should use the `map` method here, but I couldn't find
  // it's available just until I write up most of this post....
  for (const [key1, childState] of state.entries()) {
    const children2 = [];
    for (const key2 of Object.keys(childState)) {
      children2.push(
        h(
          "span",
          {
            onmousemove: [SetTrue, [key1, key2]],
            onmouseleave: [SetFalse, [key1, key2]],
            class: { elem: true, true: childState[key2] },
          },
          text(key2),
        )
      );
    }
    children1.push(
      h(
        "div",
        { class: "elem" },
        [
          text(key1),
          ... children2,
        ]
      )
    );
  }
  return h("div", {}, children1);
};

// Run the app
app({
  init: buildInit(),
  view: view,
  node: document.getElementById("app"),
});

First of all, a basic application in Hyperapp like this is split into three parts: State, View, and Action. Each of them corresponds to Model, View, Update of TEA:

State: The application's internal state. Updated by Actions.
View: Function which takes a State to return a virtual DOM object.
Action: Function which takes a State to return a new State.

Like a View in TEA generates messages from its event handlers (event handlers set in the virtual DOM returned by the View), a View in Hyperapp dispatches Actions from its event handlers. This is a code to show how event handlers are set in the View, excerpted from the example view function above:

h(
  'span',
  {
    onmousemove: [SetTrue, [key1, key2]],
    onmouseleave: [SetFalse, [key1, key2]],
    class: { elem: true, false: state[key1][key2] },
  },
  text(key2)
)

The h function is the construtor of a virtual DOM object in Hyperapp, which takes the name of the tag (here it's span), attributes of the element as an object, and the element's child node(s) (here it's text(key2)). Actions dispatched by the event handlers are set in the second argument's on*** attributes, along with their extra argument (called "payload"). In the extracted code, the Action SetTrue with the payload [key1, key2] is dispatched by a mousemove event, and SetFalse with [key1, key2] is dispatched by a mouseleave.

What happens after SetTrue or SetFalse gets dispatched? Hyperapp calls the dispatched Action with the current State, its payload, and the event object created by the mousemove/mouseleave event (but the event object is not used in the example!). Then, it passes the State returned by the Action to the View to get the refreshed virtual DOM to update the actual DOM tree. And the (re)rendered DOM tree again waits for new events to dispatch Actions.

Okay, those are the important points of Hyperapp that I want you to know before explaining the problem.

Compare the Behavior of the Buggy App and Non-Buggy One

Now, let's see how the example app works and how it gets broken by the mistake I made. I created a StackBlitz project containing both one without the bug and one with the bug in a single HTML file:

https://stackblitz.com/edit/typescript-befryd?file=index.ts

And this is the screenshot of the working app:

The example app is as simple as it receives mouseover events to paint the <span> element blue, then gets it back by mouseleave events.

By contrast, the example app I injected the bug into doesn't restore the color of the mouseleaveed <span> element:

The Change that Caused the Problem

What's the difference between the buggy example and the non-buggy example? Before diggging into the details, let me explain the motive for the change. The function that made me anxious is the SetTrue Action (and SetFalse did too):

const SetTrue = (state: State, [key1, key2]: [string, string]): State => {
  const newState = new Map(state);
  const childState = newState.get(key1);
  newState.set(key1, {
    ...childState,
    [key2]: true,
  });
  return newState;
};

The expression newState.get(key1) may return undefined since newState is a Map in the standard library and its get method returns undefined if the Map doesn't contain the associated value. TypeScript doesn't complain about this because { ...undefined } returns {} without a runtime error!, but catching undefined here is not expected. And in my actual app, it isn't evident that the get method always returns a non-undefined value.

Checking if the result of newState.get(key1) is undefined or not is trivial enough, but looking out over the view and SetTrue/SetFalse functions, you will find that the value equivalent to newState.get(key1), childState, is available as the loop variable of the outermost for ... of statement in view:

const view = (state: State) => {
  // ...
  for (const [key1, childState] of state.entries()) {
    // ...
  }
  // ...
};

That's why I decided to pass childState as one of the payload of SetTrue/SetFalse Action. I modified them as following:

const SetTrue = (
  state: State,
  [childState, key1, key2]: [ChildState, string, string]
): State => {
  const newState = new Map(state);
  newState.set(key1, {
    ...childState,
    [key2]: true,
  });
  return newState;
};

Note that the line const childState = newState.get(key1); is removed, then the local variable childState is defined as the part of the second argument instead. Now the view function gives the childState loop variable to SetTrue/SetFalse :

const view = (state: State) => {
  // ...
  for (const [key1, childState] of state.entries()) {
    // ...
          {
            onmousemove: [SetTrue, [childState, key1, key2]],
            onmouseleave: [SetFalse, [childState, key1, key2]],
            // ...
          }
    // ...
  }
  // ...
};

ℹ️ In the StackBlitz project I showed before, the view, SetTrue and SetFalse functions containing theses changes are renamed into viewBuggy, SetTrueBuggy, and SetFalseBuggy, respectively.

These changes freed SetTrue/SetFalse from undefined-checking for every child of the state. That would improve the app's performance a little (But too little to see. Don't be obcessed with that!).

Unfortunately, this is the very trigger of the weird behavior! The application won't handle the mouseleave event correctly anymore. It leaves the mouseleaveed element blue if the mouse cursor moves onto another element which also reacts to the mousemove event.

What Hyperapp does After a DOM Event Occurs

Why does the change spoil the app? Learn how Hyperapp updates the state first of all to get the answer. According to the source code, Hyperapp handles DOM events as follows:

(1) Call the Action assigned to the event with the state, the payload, and event object.
- In the case of this article's app, the Action is SetTrue or SetFalse, and the payload is [key1, key2] or [childState, key1, key2].
(2) Update the internal variable named state if the Action returns a state different from the original state (compared by !==).
- Do nothing and stop the event handler if the returned state has no change.
(3) Unless the render function (introduce later) is still running, enqueue the render function by requestAnimationFrame (or setTimeout if requestAnimationFrame is unavailable).
(4) The render function runs: call the view function with the updated state to produce renewed virtual DOM object, then compares each child of the old and new virtual DOM tree to patch the real DOM.

This is sumarrized into the pseudo JavaScript code below:

// Variables updated while the app is alive
let state, virtualDom, rendering = false;

const eventHandlers = {
  onmousemove: [SetTrue, payload],
  onmouseleave: [SetFalse, payload],
};

// (1)
const [action, payload] = eventHandlers[eventName];
const newState = action(state, payload);

if (state !== newState){
  // (2)
  state = newState;

  // (3)
  if (!rendering){
    rendering = true;
    enqueue(render);
  }
}

// (4)
function render(){
  const newVirtualDom = view(state);
  compareVirtualDomsToPatchTheRealDom(virtualDom, newVirtualDom);
  virtualDom = newVirtualDom;
  rendering = false;
}

Recall how browsers handle JavaScript tasks. Task here is a function call associated with the event (by addEventListener etc). The browser keeps running the function until the call stack gets empty without any interruption. In respect to the event handler of Hyperapp, from (1) to (3) is recognized as a single task (if the state changes). Because (3) just calls requestAnimationFrame to put off calling the render function. What requestAnimationFrame does is only registering the given function as a new task to execute later, then finishes its business. So the task initiated by the event finishes after calling requestAnimationFrame. As (3) does, calling requestAnimationFrame and do nothing afterwards is a typical way to let the browser process another task. You will find that the browser treats requestAnimationFrame as a special function according to the call stack by setting a break point to step in to the render function:

This is an example call stack in Microsoft Edge's DevTools². This shows that requestAnimationFrame switched the task running. The replaced task doesn't techinacally share the call stack with the older one, but Edge's debugger artificially concatenates them for convinience.

Consecutive Events Update the State in Order

The flow I described in the last section can be interrupted between (3) and (4), if a new task is enqueued while Hyperapp is performing (1)-(3). Such interruptions unsurprisingly happen when a pair of events occur simultaneously like the example app. That interruptions are caused by say, mouseover after mouseleave, focus after blur, and so on. As long as your app's Actions just receive the state and return the updated one, there are no problem because (2) definitely updates the state before yielding the control to the subsequent event. When a couple of serial events take place, the pseudo JavaScript code is rewritten as this:

// ... omitted...

// (1) `eventName` can be `mouseleave`, `blur` etc.
const [action, payload] = eventHandlers[eventName];
const newState = action(state, payload);

if (state !== newState){
  // (2)
  state = newState;

  // (3)
  if (!rendering){
    rendering = true;

    // (1'): (1) for another event.
    // `anotherEventName` can be `mouseenter`, `focus` etc.
    const [action, payload] = eventHandlers[anotherEventName];
    const newState = action(state, payload);
    if (state !== newState){
      // (2')
      state = newState;

      // (3') is omitted because `rendering` here must be true.
    }

    // Now, `render` renders `state` updated by (2').
    // So the `render`ed State is up-to-date even after a sequence of
    // simultaneous events are dispatched.
    render();
  }
}

// (4)
function render(){
  // ... omitted...
}

State Diverges by Unexpected References in the View

The point in the previous pseudo code is that state doesn't get stale: State passed as the first argument to the View and any Actions is always up-to-date. They wouldn't refer the State before updated by older events. Thus Hyperapp achieves "State is the Single Source of the Truth" --- as far as the Actions and their payload use the State correctly.

Now, review the example app's view function with the problem:

const view = (state: State) => {
  // ...
  for (const [key1, childState] of state.entries()) {
    // ...
          {
            onmousemove: [SetTrue, [childState, key1, key2]],
            onmouseleave: [SetFalse, [childState, key1, key2]],
            // ...
          }
    // ...
  }
  // ...
};

To make sure childState is available for the SetTrue and SetFalse Action, I put it in their payload. Payload is set as the value of on*** attribute of the virtual DOM node with its Action. So childState remains unchanged until the view function is called with the updated state. That means Actions can take the State updated by the precedent event and one not-yet updated. The State has diverged!

Let's see the details by revising the pseudo JavaScript:

// Variables updated while the app is alive
let state, virtualDom, rendering = false;

// Up until now, `eventHandlers` is defined as an independent variable for
// simplicity. But it's actually set as properties of `virtualDom` by the
// `view` function.
virtualDom.eventHandlers = {
  onmousemove: [SetTrue, state.childState],
  onmouseleave: [SetFalse, state.childState],
};

// (1). `eventName` can be `mouseleave`, `blur` etc.
const [action, payload] = eventHandlers[eventName];
const newState = action(state, payload);

if (state !== newState){
  // (2)
  state = newState;

  // (3)
  if (!rendering){
    rendering = true;

    // (1') ⚠️`state` is already updated in (2), but `virtualDom` is not yet!
    // So `virtualDom.eventHandlers` with its payload aren't either!
    const [action, payload] = virtualDom.eventHandlers[anotherEventName];
    const newState = action(state, payload);
    if (state !== newState){
      // (2')
      state = newState;

      // (3') is omitted because `rendering` here must be true.
    }

    render();
  }
}

// (4)
function render(){
  const newVirtualDom = view(state);
  compareVirtualDomsToPatchTheRealDom(virtualDom, newVirtualDom);
  // `virtualDom.eventHandlers` are finally updated here. But too late!
  virtualDom = newVirtualDom;
  rendering = false;
}

The virtual DOM object is updated by View, and the State is updated by an Action. Due to the difference in when they are called, the Action can process an outdated state left in the virtual DOM as payload.

Conclusion and Extra Remarks

Don't refer to (some part of) the State in Actions except as their first argument.
- In addition to payload, we have to take care of free variables if we define Actions inside the View.
I suspect we might encounter the same problem in other frameworks with the similar architecture (e.g. React/Redux, Elm).

Hyperapp doesn't force you to use TypeScript of course. But I'll use TypeScript for easier description of the type of the state. ↩
I'm afraid I failed to reproduce a call stack like this with the debugger of my favorite Firefox's DevTools. 😞 ↩

DEV Community: YAMAMOTO Yuji

Flexiblly Extend Nested Structures - "Trees that Grow" in TypeScript

Summary

Problem

Incomplete Solution 1: Parameterize an Extension to Pass Around

Solutions

Follow the Original Idea: Use Type Families

Simulate Open Type Families Using Global Interfaces

Make Expression Extensible with a Global Interface

New Problem: Can We Make it Simpler?

Incomplete Solution 2: Parameterize Every Extension to Pass Around

Final Solution: Packing up Type Parameters Into One Structure

Example

Final Thoughts: Really Impossible in Haskell?

Why I failed to create the "Solid.js's store" for Svelte, and announcing svelte-store-tree v0.3.1

Summary

Introduction to svelte-store-tree

Example Usage

Creating a WritableTree Object

subscribe and set like the original store of Svelte

Create a WritableTree for a part of the tree by zoom

Subscribe the value only fulfilling the condition using choose

Parents can react to updates by their children

V.S. Solid.js's Store

Quick introduction to Solid.js's Store

Feature that affected svelte-store-tree

Feature that svelte-store-tree failed to support

Divergent States in a "Single Source of Truth" Framework

Introduction to Hyperapp with an Example App without the Bug

Compare the Behavior of the Buggy App and Non-Buggy One

The Change that Caused the Problem

What Hyperapp does After a DOM Event Occurs

Consecutive Events Update the State in Order

State Diverges by Unexpected References in the View

Conclusion and Extra Remarks

Make `Expression` Extensible with a Global Interface

Creating a `WritableTree` Object

`subscribe` and `set` like the original store of Svelte

Create a `WritableTree` for a part of the tree by `zoom`

Subscribe the value only fulfilling the condition using `choose`