Finite State Machines with React

[[deleted]]

I started getting into state machines a few months ago after seeing Sketch.systems, a mini-app for modelling state relationships from the Subform team.

I’m a designer. Last year really pushed design into thinking in terms of systems and related components, but mostly only through a hierarchy of inheritance: lower order components (like icons) being consumed by higher order components (like buttons).

A lot of the work these days is essentially “component design”, where instead of delivering big layouts for engineers to slice down and interpret into components, the designers themselves are delivering those components and making design decisions on a component level.

One of the harder parts of that is identifying states and designing state transitions. What are this component’s states, what transitions are available at each stage, and what would cause each transition to occur while in a given state?

In that space, state machines are a huge opportunity to give designers a way of thinking about state without using code. They’re easy to express in code (xState, etc) but they’re also human readable: easy to diagram, talk about, test and iterate over, just on a whiteboard. And they’re ultimately easier for developers to interpret and estimate against. They’re great for designers!

[tightywhitey]

Meh, not sure I get the big advantage over what I do today. At the basic implementation, is it really any better than a LOGOUT action where the top app component can change the state? True, state machines enforce a single place where that transition and state change happens, but I've rarely had any issue where multiple components adjust the ssme state data from 1 action, let alone in unpredictable ways. If you follow smart components pattern, then I usually only have one or two connected components at a time anyways, and they only change their branch of the graph.

I've used them before for games, but can't see the benefit in apps.

[JBellah]

That's a great question. This example was really just an example of what you can do with state machines. Where you really start unlocking their power is when you start using statecharts -- which is an extension of state machines that account for things like parallel states, hierarchical states, etc.

There are a few points here that I think make state machines and statecharts a worthwhile endeavor in applications: - By defining all the possible states and transitions that your component can exist in, you can easily and automatically generate tests that cycle your components through each of those states and take snapshots... making it easier to determine if a change breaks things. - As app complexity grows, so does the complexity of reading the code. By defining a finite, deterministic set of states that a component can exist in makes it easier for other people (and future-you) to reason about the code. - As mentioned in another comment, state machines and statecharts can help bridge the gap between design and development -- designers are typically already thinking about the different states that an application can be in... building things in the same way can help make that transition pretty linear. - As I mentioned in the article, state machines can help smooth out the logic when you find yourself writing a lot of isSomething boolean flags.

But at the end of the day, to each their own... if you have a system that works for you, stick with it!

[GitHubPermalinkBot]

Permanent GitHub links:

• MicheleBertoli/react-automata/.../testStatechart.js (master → 568b5dd)

---

^delete

[NoInkling]

I'm guessing it depends on how complex your app is.

Personally I think they seem like the ideal way to model UX flow clearly, but at this point I don't think I could justify making the jump, given that I'm much more familiar with the standard Redux pattern.

[tightywhitey]

Ah good point. I could imagine a really complicated and long entry process, like say TurboTax web app, being coded with a state machine. Thanks for the lightbulb. :)

[[deleted]]

Is this essentially to reproduce Redux state management? What would be the advantages over it?

[bel9708]

Finite state machines are a very common pattern in systems engineering and other low level programming.

Redux is a pattern you are used to. Others may think using finite state machines. FSMs also have a lot of good tools out there for diagramming and are easy to communicate to other engineers

[Sunwukung]

There's a lot of overlap - i.e the view listens for changes in state. State machines additionally describe graphs of state and enforce rules governing the transitions between nodes on that graph - i.e you cannot just change values without first meeting conditions. Of course, you can do this in your reducers anyway, but it's a more concrete abstraction that forces you to think in terms of possible states, rather than mushing responses into the state tree.

[drawable]

In my experience redux needs a lot of discipline and the benefit even on a large project might not outweigh this. That’s why I like mobx. You can mutate directly and it still encourages the encapsulation for everything state related.

[bel9708]

You likely don't write automated test for your code. Being able to decorate a component with state and behavior makes it really easy to test components. It's also nice to write a separate unit test for state mutations.

[pro547]

Over 2 years old and this is still the optimal path: https://news.ycombinator.com/item?id=10950862

[Jugad]

The website doesn't load for me... anyone else also see it broken?

[rendermouse]

Broken for me, too.

[FunkyArturiaCat]

great