You might have heard of “state machine” or “finite-state machine” before. If you look up state machine on Wikipedia, you’ll read that a state machine is described as a “mathematical model of computation,” followed by a bunch of symbols and computer science jargon that doesn’t immediately seem to apply to your team’s work.
However, state machines are really useful for describing almost any kind of logic, feature, user story, sequence, process, workflow, specification, and more.
State machines are great for modeling state in applications. However, we often need to persist and restore state across sessions - for example, when a user closes and reopens their browser. In this article, we’ll explore how to persist and restore state in XState so your frontend applications or backend workflows can pick up where it left off.
At Stately, the Actor Model is one of our favorite programming paradigms, and we think it’s for good reason! The actor model allows developers to build reliable message-based systems by using actors to communicate. This works extremely well with state machines and statecharts, which can also be modeled as actors and can communicate much in the same ways. Read on to learn what the actor model is, the problems it seeks to solve, and how you can use it in your projects to communicate reliably across different entities.
Are you a React developer using XState to model your application logic? Perhaps you’ve heard of XState but have been looking for an easy way to try it out in one of your projects. If so, then I’d like to share with you a pattern I was introduced to when first diving into codebase at Stately, that of using custom machine hooks. This lightweight, reusable way to integrate XState into React components is a delight to work with and I think you might like it as much as I do!
Last week we asked our community, “What are the biggest benefits you’ve had from using state machines?”
At Stately, we’re obviously fans of state machines. Still, we wanted to ask our community the benefits they’ve experienced, whether they were working on a specific project or incorporating state machines into their everyday workflow.
Statecharts are a visual language used to describe the states in a process.
You may have used similar diagrams in the past to design user flows, plan databases or map app architecture. Statecharts are another way of using boxes and arrows to represent flows, but with XState these flows are also executable code that can be used to control the logic in your applications.
XState offers several primitives for representing long-running application processes. These are usually expressed as services. I’ve written a bit about services here - but today I wanted to talk about my favourite way of expressing services: the Invoked Callback.
XState offers several ways of orchestrating side effects. Since it’s a statechart tool, with significantly more power than a reducer, side effects are treated as a first-class concept.
State machines offer several API’s for expressing state. Like other tools, you can keep arbitrary values in a store (usually expressed as an object) called context.
XState offers two options for declaring machine definitions:
import { Machine } from 'xstate';
const machine = Machine({ ...config });
…or…
import { createMachine } from 'xstate';
const machine = createMachine({ ...config });
This can be confusing for beginners. Why are there two very similar-looking methods? What’s the difference?