xstate

Actor-based state management & orchestration for complex app logic. → Documentation

XState is a state management and orchestration solution for JavaScript and TypeScript apps. It has _zero_ dependencies, and is useful for frontend and backend application logic. It uses event-driven programming, state machines, statecharts, and the actor model to handle complex logic in predictable, robust, and visual ways. XState provides a powerful and flexible way to manage application and workflow state by allowing developers to model logic as actors and state machines. ### ✨ Create state machines visually in Stately Studio → [state.new](https://state.new) --- 📖 [Read the documentation](https://stately.ai/docs) ➡️ [Create state machines with the Stately Editor](https://stately.ai/editor) 🖥 [Download our VS Code extension](https://marketplace.visualstudio.com/items?itemName=statelyai.stately-vscode) 📑 Inspired by the [SCXML specification](https://www.w3.org/TR/scxml/) 💬 Chat on the [Stately Discord Community](https://discord.gg/xstate) ✍️ Browse through the many [XState examples](https://github.com/statelyai/xstate/tree/main/examples) ## Which package should I use? Pick based on what you need: - **[`@xstate/store`](#xstate-store)**: simple event-based state management. <1kb, great TypeScript inference, similar in spirit to Redux/Zustand. Start here if you just need a store. - **[`xstate`](#super-quick-start)**: state machines, statecharts, actors, effects, and orchestration for complex app logic. They work great together, but you don't need one to use the other. ## Sponsors Special thanks to the sponsors who support this open-source project: ## Templates Get started by forking one of these templates on CodeSandbox: Template [🤖 XState Template (CodeSandbox)](https://codesandbox.io/p/devbox/github/statelyai/xstate/tree/main/templates/vanilla-ts) - XState v5 - TypeScript - _No framework_ [⚛️ XState + React Template (CodeSandbox)](https://codesandbox.io/p/devbox/github/statelyai/xstate/tree/main/templates/react-ts) - [React](https://react.dev/) - XState v5 - TypeScript [💚 XState + Vue Template (CodeSandbox)](https://codesandbox.io/p/devbox/github/statelyai/xstate/tree/main/templates/vue-ts) - [Vue](https://vuejs.org/) - XState v5 - TypeScript [🧡 XState + Svelte Template (CodeSandbox)](https://codesandbox.io/p/devbox/github/statelyai/xstate/tree/main/templates/svelte-ts) - [Svelte](https://svelte.dev/) - XState v5 - TypeScript ## Super quick start ```bash npm install xstate ``` ``` … ``` --- ## `@xstate/store`: simple state management Not every app needs all the features of state machines and statecharts. **[`@xstate/store`](https://github.com/statelyai/xstate/tree/main/packages/xstate-store)** is a separate, extremely small event-based store with first-class TypeScript inference; similar to Redux or Zustand, but with less boilerplate. Use it on its own, or graduate to full XState machines when your logic gets more complex. ```bash npm install @xstate/store ``` ``` … ``` 📖 See the [`@xstate/store` README](https://github.com/statelyai/xstate/tree/main/packages/xstate-store) for React/Solid bindings, selectors, and more. --- ## [Stately Studio](https://stately.ai) - Visually create, edit, and collaborate on state machines - Export to many formats, including XState v5 - Test path & documentation autogeneration - Deploy to Stately Sky - Generate & modify machines with Stately AI **[state.new](https://stately.ai/registry/new?ref=github)** ## Why? Statecharts are a formalism for modeling stateful, reactive systems. This is useful for declaratively describing the _behavior_ of your application, from the individual components to the overall application logic. Read [📽 the slides](http://slides.com/davidkpiano/finite-state-machines) ([🎥 video](https://www.youtube.com/watch?v=VU1NKX6Qkxc)) or check out these resources for learning about the importance of finite state machines and statecharts in user interfaces: - [Statecharts - A Visual Formalism for Complex Systems](https://www.sciencedirect.com/science/article/pii/0167642387900359/pdf) by David Harel - [The World of Statecharts](https://statecharts.github.io/) by Erik Mogensen ## Packages | Package | Description | | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | 🤖 `xstate` | Core finite state machine and statecharts library + interpreter, including graph traversal and model-based testing utilities | | [🏪 `@xstate/store`](https://github.com/statelyai/xstate/tree/main/packages/xstate-store) | Simple event-based state management (<1kb) — standalone, works with or without `xstate` | | [⚛️ `@xstate/react`](https://github.com/statelyai/xstate/tree/main/packages/xstate-react) | React hooks and utilities for using XState in React applications | | [💚 `@xstate/vue`](https://github.com/statelyai/xstate/tree/main/packages/xstate-vue) | Vue composition functions and utilities for using XState in Vue applications | | [🎷 `@xstate/svelte`](https://github.com/statelyai/xstate/tree/main/packages/xstate-svelte) | Svelte utilities for using XState in Svelte applications | | [🥏 `@xstate/solid`](https://github.com/statelyai/xstate/tree/main/packages/xstate-solid) | Solid hooks and utilities for using XState in Solid applications | | [🔍 `@statelyai/inspect`](https://github.com/statelyai/inspect) | Inspection utilities for XState | ## Finite State Machines CodeStatechart ```js import { createMachine, createActor } from 'xstate'; const lightMachine = createMachine({ id: 'light', initial: 'green', states: { green: { on: { TIMER: 'yellow' } }, yellow: { on: { TIMER: 'red' } }, red: { on: { TIMER: 'green' } } } }); const actor = createActor(lightMachine); actor.subscribe((state) => { console.log(state.value); }); actor.start(); // logs 'green' actor.send({ type: 'TIMER' }); // logs 'yellow' ```
Open in Stately Studio
## Hierarchical (Nested) State Machines CodeStatechart ``` … ```
Open in Stately Studio
## Parallel State Machines CodeStatechart ``` … ```
Open in Stately Studio ## History States CodeStatechart ``` … ```
Open in Stately Studio ## SemVer Policy We understand the importance of the public contract and do not intend to release any breaking changes to the **runtime** API in a minor or patch release. We consider this with any changes we make to the XState libraries and aim to minimize their effects on existing users. ### Breaking changes XState executes much of the user logic itself. Therefore, almost any change to its behavior might be considered a breaking change. We recognize this as a potential problem but believe that treating every change as a breaking change is not practical. We do our best to implement new features thoughtfully to enable our users to implement their logic in a better, safer way. Any change _could_ affect how existing XState machines behave if those machines are using particular configurations. We do not introduce behavior changes on a whim and aim to avoid making changes that affect most existing machines. But we reserve the right to make _some_ behavior changes in minor releases. Our best judgment of the situation will always dictate such changes. Please always read our release notes before deciding to upgrade. ### TypeScript changes We also reserve a similar right to adjust declared TypeScript definitions or drop support for older versions of TypeScript in a minor release. The TypeScript language itself evolves quickly and often introduces breaking changes in its minor releases. Our team is also continuously learning how to leverage TypeScript more effectively - and the types improve as a result. For these reasons, it is impractical for our team to be bound by decisions taken when an older version of TypeScript was its latest version or when we didn’t know how to declare our types in a better way. We won’t introduce declaration changes often - but we are more likely to do so than with runtime changes. ### Packages Most of the packages in the XState family declare a peer dependency on XState itself. We’ll be cautious about maintaining compatibility with already-released packages when releasing a new version of XState, **but** each release of packages depending on XState will always adjust the declared peer dependency range to include the latest version of XState. For example, you should always be able to update `xstate` without `@xstate/react`. But when you update `@xstate/react`, we highly recommend updating `xstate` too.