[dfabulich]

> A React application can be thought of as modeling a state machine. Each render takes a state and produces the UI for that state. This is the famous UI = f(state) mental model of React. But, for complex applications, formally enumerating a transition table is often not feasible. When the number of possible states is not finite, a table will not suffice and we must instead define a mapping: a conceptual function which takes in a state and returns the set of valid transitions for that state.

Not really, though. While you can model any program as a state machine, doing so typically adds nothing to your understanding of the program.

State-machine diagrams are especially useless. A diagram is only useful if it has about a dozen things in it, maybe two dozen, maximum. But that doesn't mean you can model a dozen states in a state-machine diagram; in these diagrams, the transitions, the arrows between the states, are at least as important as the states themselves. So the diagrams are useless when the number of states + the number of transitions between them are greater than a few dozen. Typically that means state diagrams are only with a handful of states with a few transitions hanging off of each.

But, if your problem is simple enough that you can represent it with a handful of states with two or three transitions each, then you have a very trivial problem, so trivial that the state-machine diagram likely added nothing at all to your understanding of it.

This is why no popular UI frameworks actually do model UI as a set of states with transitions. It's easier to model the state diagram as a function and then just forget about the state diagram.

That's what React is all about! A pure function, UI = f(state). It's better than a state diagram.

This article is saying: "Hey, you could think of React, something conceptually simple, as something unnecessarily complicated, instead!" Gee, thanks?

[captbaritone]

Author here. I think we might actually be in agreement. My point is that in React you don't formally describe the transition table because (and I think this is where we agree) that's infeasible for an app of any reasonable size.

The observation I'm trying to capture in this post is that even though we don't define a formal transition table, we actually _do_ implicitly define the set of valid (user) transitions for each state via the event handlers we bind into the DOM when our React component tree renders that state.

[tshaddox]

> But, if your problem is simple enough that you can represent it with a handful of states with two or three transitions each, then you have a very trivial problem, so trivial that the state-machine diagram likely added nothing at all to your understanding of it.

And yet, it's extremely common to see apps with clearly broken states and state transitions for what should be relatively "trivial" state machines. Think play/pause buttons, buttons with loading states, form fields with error states, etc.