Hacker News Reader

> State machines are great but they get quite complicated when you have two machines interacting at some point. I find this happens quite a bit for complicated UIs, like a data grid

Even before you get to a data grid, you get an exponential explosion of states. Since most FSMs are not a part of the actual UI frameworks, and are and addon on top of that, you end up with just so much stuff.

I had a rather simple checkout form in the form of "list ticket types, when clicked select number of people, click `reserve`". Sounds like a few states, right? Until you throw in "is user logged in?", "is the user VIP" (requires adding some other tickets with their states), "do we require user consent?", "do we require user info?", "can user use their bonus points?", "is there a min/max amount of tickets allowed?" etc. etc. etc.

Suddenly you have an explosion of states and validations between these states. It's no longer A -> B. It's A -> (if X then B else if then Y C else if Z ерут В) for many if not all state transitions.

And that's just to show screens in the checkout process. Now let's talk about form controls and fields on each page... :)

The number of possible states exploding is indeed a problem with frameworks like React.

One mental model that helps reduce this load, that you alluded to, is avoiding product types where possible in favor of sum types.

Eg. Imaging you have a type describing React props for some component: {a?: number} and {a: number} | {} seem very similar on the surface — they both describe an object with a single field that may or may not be defined. In both cases you have 2 possible states.

But as soon as you add another field, the number of states can grow quickly unless you’re thoughtful: {a?: number, b?: string} has 4 states, while the model you might have been trying to describe — {a: number} | {b: string} — still has just two.

The less states you have, the easier it is to reason about and automatically verify your model. But in practice, people often accidentally introduce product type where they meant to use sums. I see this with Flow and TypeScript-typed React code all the time.

"{a?: number, b?: string} has 4 states, while the model you might have been trying to describe — {a: number} | {b: string} — still has just two."

The problem I've run into with the second approach as the number of states expand is 1 - you end up with tons of boilerplate to discriminate between types, and 2 - it becomes hard to treat objects polymorphically.

I sometimes end up doing {a: number, b?: undefined} | {b: string, a?: undefined} so that I can write `if (obj.a) doSomething()`, but it obviously gets unwieldy with a lot of properties and states. Imo it would be nice if TS did this automatically so that I could check for the existence of any property that might be defined on an object.

I don't know TypeScript, but can't you expend a few lines to write a function 'getA : State -> number?'? Paired with the TypeScript equivalent of Swift's / Rust's if-let, it should be just as convenient.

Right, TS wants you to go full-on tagged union.

    {type: 'a', a: number} | {type: 'b', b: string}

When you do this you consume it with a switch(x.type) statement, not an if() statement, so that you can write `default: assertImpossible(x.type)` for some function `assertImpossible(y: never): never` that throws an exception of your choice.

This gives clear fail-at-runtime semantics if JS hands you some crap your types weren’t anticipating, but also fail-at-compile-time semantics if your pattern match is no longer exhaustive (i.e. you added a new case, now TypeScript tells you everything you need to change).

In general it's really nice to view any data structure as isomorphic to the control structure that consumes it. “lists” are consumed by for..of loops, “dicts” are consumed by for..of Object.keys() loops, sum types are consumed by switches, objects are consumed by property accesses, etc.

Right, tagged unions are what I use, but when you start having many variants, nested tagged unions, etc., it gets quite awkward imo when you need a big ol’ switch statement to get at some property or other instead of just a simple property check.

If your code is fully typed, you don't need the default, since you know at compile time that you've handled your cases (Playground link: [0]):

    type Props =
      | { type: 'a', a: number }
      | { type: 'b', b: string }

    function f(props: Props): number {
      switch (props.type) {
        case 'a': return 1
        case 'b': return 2
      }
    }

Unfortunately you're right that this breaks when using `if` instead of `switch` (unless you have a default return at the end of your function, or replace one of your `if`s with an `else`; Playground link: [1]):

    type Props =
      | { type: 'a', a: number }
      | { type: 'b', b: string }

    // Error TS2366: Function lacks ending return statement and return
    // type does not include 'undefined'.
    function f(props: Props): number {
      if (props.type === 'a') {
        return 3
      }
      if (props.type === 'b') {
        return 4
      }
    }

This second case is a bug in TSC, and is tracked in https://github.com/microsoft/TypeScript/issues/18319.

[0] https://www.typescriptlang.org/play/#code/AQ4FwTwBwU2AFATgey...

[1] https://www.typescriptlang.org/play/#code/AQ4FwTwBwU2AFATgey...

The fundamental problem is that Typescript (and JavaScript) doesn't have tagged unions. In Rust or even C++ using std::variant this isn't a problem.

TypeScript does support tagged unions, actually: https://www.typescriptlang.org/docs/handbook/advanced-types....

As does Flow: https://flow.org/blog/2015/07/03/Disjoint-Unions/

Every language can do tagged unions with "kind" or "tag" markers and switch statement. But it's going to be verbose without pattern matching/destructuring combo.

It’s not that bad, to be honest. Maybe a few more keystrokes than Haskell, but so is everything else in a C-style language.

Definitely a fair point that it is a few more keystrokes, though.

Thankfully TypeScript's type system is powerful enough (and JS's syntax flexible enough) to decently simulate pattern matching:

https://gist.github.com/frankpf/cde7f792580f731dfe886ed2d91b... (see the second file for usage)

Swift handles this exact problem quite elegantly with the "if case let" construct, allowing you to destructure sum types directly within an if statement.

https://alisoftware.github.io/swift/pattern-matching/2016/05...

You can use an `in` check for this, since TypeScript version 2.7 [0].

Here's an example (Playground link: [1]):

    import * as React from 'react'

    type Props =
       | {a: number}
       | {b: string}

    function MyComponent(props: Props): JSX.Element {
      if ('a' in props) {
        return <div>a is {props.a}</div>
      }
      return <div>b is {props.b}</div>
    }

    let x = <MyComponent a={3} />
    let y = <MyComponent b="foo" />

[0] https://www.typescriptlang.org/docs/handbook/release-notes/t...

[1] https://www.typescriptlang.org/play/?jsx=2#code/JYWwDg9gTgLg...

Oh nice! I’ll give that a try, thanks.

Trouble with "stage" is that is collides with the "stages" in "multistage programming" - so you're kind of adding to overloading in another field! It's also a field that has lots of applicability to the front-end space (eg. server-side rendering, Svelte, etc.)

That is a ridiculously niche term to worry about confusing with. I would put money on 99% of programmers having never heard of it.

Swift enums and std::variant would work the same.

> State machines are great but they get quite complicated when you have two machines interacting at some point.

I suppose this depends a bit on how transitions are triggered.

If an ux even can trigger a change in state machine a, from state a1 to a2, and that transition can fire off an event that trigger a transition in b, from b1 to b2, and that transition fires an event that triggers a transition from a1.... Then you have problems.

It would probably be better to model a and b as a bigger machine c, that models all states and transitions, and allow the various components/widgets to be "views" of this machine c?

Or; make sure that a state transition won't in and of itself fire an event that triggers a transition in another state machine. Ie: a and could both respond to window resize, but should not trigger a window resize.