XState Docs

# Goals

These XState v4 docs are no longer maintained

XState v5 is out now! Read more about XState v5 (opens new window) and check out the XState v5 docs (opens new window).

# API Goals

# Choosing XState

If you're deciding if you should use XState, John Yanarella (opens new window) summed up his reasons really well (links and emphasis mine):

When I was making that same choice as to whether to use and advocate for the use of XState where I work, the things that stood out for me were:

  1. The commitment to understanding the relevant prior art and informing the implementation based on existing research papers (Harel's original paper on statecharts (opens new window)), books (Horrocks' "Constructing the User Interface with Statecharts" (opens new window)), and standards (W3C's SCXML (opens new window)).

Many of the other libraries I reviewed along the way are projects that stop at the point of implementing simple finite state machines. (If that's all you need - and it might be - David's been quick to point out how few lines it takes to just roll your own.) Their reach is shortened, since they don't address the subsequent limitations that can be overcome via a statechart.

XState stands on the shoulders of giants by embracing W3C's SCXML spec (opens new window) - it gets the benefit of that working group's research into edge cases.

  1. It's a refuge from the "shiny object syndrome" of embracing the latest flavor-of-the-month "state management library". It faithfully implements a 30+ year old formalism. You end up putting your most important logic into something you can take with you to any UI framework (and potentially to other statechart implementations in other languages). It's a zero-dependency library.

The front-end development world is the wild west, and it could stand to learn from what other engineering disciplines have known and employed for years.

  1. It has passed a critical threshold of maturity as of version 4, particularly given the introduction of the visualizer (opens new window). And that's just the tip of the iceberg of where it could go next, as it (and its community (opens new window)) introduces tooling that takes advantage of how a statechart can be visualized, analyzed, and tested.
  2. The community that is growing around it and the awareness it is bringing to finite state machines and statecharts. If you read back through this gitter history, there's a wealth of links to research papers, other FSM and Statechart implementations, etc. that have been collected by Erik Mogensen (opens new window) over at statecharts.github.io (opens new window).

← Showcase →