In React {Transitions} = F(state)

Every time I delve into a large React codebases (and I have worked on some real monsters) I have a laugh to myself at how badly these guys tie themselves up in knots in order to preserve the supposed simplicity of the state -> UI function. When you invent something as insane as the hooks API in order to maintain purity it's time to step back and consider if you're really on the right track.

The #1 reason I push for SSR&#x2F;vanilla web is to consolidate all state to the server. Literally the only thing on the client could be a session cookie. A few hundred bits of entropy. That&#x27;s the client&#x27;s state. Imagine how simple that would be.<p>The cost of a round trip for every UI interaction might seem high, but I&#x27;ve never seen a distributed client&#x2F;server state machine model that could compensate for any of these alleged UX harms without simultaneously bringing in more complexity than anyone was prepared to deal with.

&quot;This is the famous UI = f(state) mental model of React&quot;. Famously incorrect generalization. Why? For example, the useRef hook enables components to hold their own state. React components are not guaranteed to be pure functions. Of course, it can depend on how one writes their code, but it&#x27;s not a guaranteed that UI = f(state) in React in general.

The most direct way of solving the immediate problem is to make transitions idempotent. Why must it be an error to complete an already complete TODO? Completing an already complete TODO should be a no-op. That simplifies things greatly.<p>Of course many actions logically cannot be made idempotent, but for the subset that can, do it as much as possible.

Why does it feel like React (not just the lib but the community&#x2F;ecosystem&#x2F;everything) took something as straightforward and easy to understand as functional programming and surrounded it with so much fluffy pomp and circumstance that it is unrecognizable?

I dont think this is really true in practice. Most of the time there is context and 3rd party sources components get from. It is good idea to have your actual view use this paradigm though.

I&#x27;ve never seen a Teact project where UI = f(state). There is always heavy reliance on the &quot;lifecycle&quot; of components. So you compose &quot;functions&quot;, but every function is using some global state, shared or not, it&#x27;s meaningless to describe it as &quot;functions&quot;.<p>The one project I&#x27;ve used that had redux was also a complete nightmare to work with, and hooks are the blessed way now apparently.

&gt; 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.<p>Not really, though. While you <i>can</i> model any program as a state machine, doing so typically adds nothing to your understanding of the program.<p>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&#x27;t mean you can model a dozen <i>states</i> in a state-machine diagram; in these diagrams, the <i>transitions</i>, 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.<p>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 <i>very</i> trivial problem, so trivial that the state-machine diagram likely added nothing at all to your understanding of it.<p>This is why no popular UI frameworks actually <i>do</i> model UI as a set of states with transitions. It&#x27;s easier to model the <i>state diagram</i> as a <i>function</i> and then just forget about the state diagram.<p>That&#x27;s what React is all about! A pure function, UI = f(state). It&#x27;s <i>better</i> than a state diagram.<p>This article is saying: &quot;Hey, you could think of React, something conceptually simple, as something unnecessarily complicated, instead!&quot; Gee, thanks?

I might just not be aware of a better alternative for React hooks, but I don&#x27;t like useEffect. I feel like it makes it much more difficult to manage state and transitions compared to SolidJS or other frameworks that use signals.

The vast majority of state problems in React are a result of nonsense cargo culting around the idea that classes are somehow bad.

That is a valid way of thinking.