XState can be used wherever JavaScript runs, whether on the backend or frontend. Because the code it creates can be visualized, it’s great at handling complex use cases - being able to see what a complex piece of code does can be extremely useful.
Let’s look at each use case one-by-one.
Many React applications follow the Flux architecture popularised by Redux. This setup can be characterised by a few key ideas:
dispatch function which can be used to send messages up to the store. Redux calls these actions, but I'll be calling them events - as they're known in XState.This article won't go into depth on whether the Flux architecture is a good idea. David Khourshid's article Redux is half a pattern goes into great detail here. For the purposes of this article, we're going to assume that you like having a global store, and you want to replicate it in XState.
I wrote a form library once.
Once.
It was called React Redux Form, and using Redux for forms was a good idea, at the time (don't use it). In fact, my library was written as a response to Redux Form, and both libraries soon discovered that the idea of using a single global store to store all of your application state is a really, really bad idea.
When all of your forms live in one single store, state is easy to manage at first. And then, every single keypress starts to lag. It's a terrible user experience.
Redux is fantastic.
Some of you might disagree, so let me tell you why.
Over the last few years, Redux has popularized the idea of using message-passing (also known as event-driven programming) to manage application state. Instead of making arbitrary method calls to various class instances or mutating data structures, we now can think of state as being in a "predictable container" that only changes as a reaction to these "events".
