Skip to content
Version: XState v5

The Actor model

The Actor model in computer science is a mathematical model of concurrent computation in which an “actor” is the basic building block.

The actor model allows developers to build reliable message-based systems by using actors to communicate. State machines and statecharts can model the logic of actors. These actors can communicate with each other, and with other actors, in the same way.

What defines an “actor”?​

Actors are independent “live” objects that can communicate with each other via asynchronous message passing. In XState, we refer to these messages as events.

  • An actor has its own internal, encapsulated state that can only be updated by the actor itself. An actor may choose to update its internal state in response to a message it receives, but it cannot be updated by any other entity.
  • Actors communicate with other actors by sending and receiving events asynchronously.
  • Actors process one message at a time. They have an internal “mailbox” that acts like an event queue, processing events sequentially.
  • Internal actor state is not shared between actors. The only way for an actor to share any part of its internal state is by:
    • Sending events to other actors
    • Or emitting snapshots, which can be considered implicit events sent to subscribers.
  • Actors can create (spawn/invoke) new actors.

You’ll find strong similarities to the actor model in software you may already be familiar with. The concept of objects encapsulating state and passing messages to each other may be familiar from Object-Oriented Programming. And actors are analagous to real-world physical concepts like cell biology, and communication in human relationships.

State​

An actor has its own internal, encapsulated state that only the actor itself can update. An actor may update its internal state in response to a message it receives, but it cannot be updated by any other entity. Actors do not share state. The only way for an actor to share data is by sending events.

Read more about XState actors and state.

Communication with events​

Actors communicate with other actors by sending and receiving events asynchronously. Actors use an internal “mailbox” that acts like an event queue, processing events one at a time.

Read more about XState events and transitions.

Spawning​

Actors can spawn new actors, which is useful in situations where an actor needs to delegate work to another actor. Spawning allows for a flexible and dynamic system where actors can be created and destroyed as needed to handle the workload efficiently.

The actor model in backend development​

The actor model is often used to coordinate backend systems. There are direct implementations of the Actor model, like Akka for the JVM. In Erlang, processes can be seen as actors, which can send and receive messages and spawn new processes. Erlang is used by massive distributed systems, like Discord and WhatsApp.

In Stately Sky, a state machine actor can be used to manage long-running backend processes like medical patient onboarding flows, inventory management, or multi-player collaborative experiences like whiteboard canvases or games.

The actor model in frontend development​

The actor model is especially useful for coordinating the many moving parts of a front-end web application.

Your front-end app is always a distributed system, and managing distributed systems is where the actor model shines. This is because in a browser environment you never really have a “global source of truth”, you instead have many independent sources of state and events: 3rd-party components, local component state, local storage, query parameters, routers, network I/O, DOM events and their listeners, etc.

[…] there is no such thing as a single source of truth in any non-trivial application. All applications, even front-end apps, are distributed at some level. – via: Redux is Half of a Pattern (2/2)

So even for simple web apps, with small app-specific state and a few known app-specific events, the actor model can be helpful.

XState​

Actors in XState can:

  • Accept messages as events passed to their own internal logic, or for state machines as received by transitions.
  • Create more actors within a state machine using spawn in an assign, or using the spawnChild action creator. For details, see Spawn.
  • Send more messages as events using self.send in their own logic, or action creators like sendTo or raise in a state machine.

Actors in XState have their own actor logic which they use to:

  • Make local decisions
  • Determine how to respond to the next message received
  • Modify their own private state (but only affect each other via messaging)

Actors in XState exist in systems and can communicate with each other within and across those systems.

Reference​