XState Docs
JavaScript and TypeScript finite state machines (opens new window) and statecharts (opens new window) for the fashionable internet.
???? Read the documentation (opens new window)
???? Explore our catalogue of examples (opens new window)
➡️ Create state machines with the Stately Editor (opens new window)
???? Download our VS Code extension (opens new window)
???? Adheres to the SCXML specification (opens new window)
???? Chat on the Stately Discord Community (opens new window)
Packages
Templates
Get began by forking certainly one of these templates on CodeSandbox:
Tremendous fast begin
Promise instance
???? See the visualization on stately.ai/viz (opens new window)
See the code
Visualizer
Visualize, simulate, inspect, and share your statecharts in XState Viz (opens new window)
stately.ai/viz (opens new window)
Why?
Statecharts are a formalism for modeling stateful, reactive programs. That is helpful for declaratively describing the habits of your utility, from the person parts to the general utility logic.
Learn ???? the slides (opens new window) (???? video (opens new window)) or take a look at these sources for studying concerning the significance of finite state machines and statecharts in consumer interfaces:
Finite State Machines
Hierarchical (Nested) State Machines
Object notation for hierarchical states:
Parallel State Machines
Historical past States
Particular due to the sponsors who help this open-source challenge:
SemVer Coverage
We perceive the significance of the general public contract and don’t intend to launch any breaking modifications to the runtime API in a minor or patch launch. We think about this with any modifications we make to the XState libraries and goal to reduce their results on present customers.
Breaking modifications
XState executes a lot of the consumer logic itself. Due to this fact, virtually any change to its habits is perhaps thought of a breaking change. We acknowledge this as a possible downside however consider that treating each change as a breaking change is just not sensible. We do our greatest to implement new options thoughtfully to allow our customers to implement their logic in a greater, safer manner.
Any change may have an effect on how present XState machines behave if these machines are utilizing explicit configurations. We don’t introduce habits modifications on a whim and goal to keep away from making modifications that have an effect on most present machines. However we reserve the precise to make some habits modifications in minor releases. Our greatest judgment of the scenario will all the time dictate such modifications. Please all the time learn our launch notes earlier than deciding to improve.
TypeScript modifications
We additionally reserve an identical proper to regulate declared TypeScript definitions or drop help for older variations of TypeScript in a minor launch. The TypeScript language itself evolves rapidly and sometimes introduces breaking modifications in its minor releases. Our staff can also be constantly studying learn how to leverage TypeScript extra successfully – and the categories enhance because of this.
For these causes, it’s impractical for our staff to be certain by choices taken when an older model of TypeScript was its newest model or once we didn’t know learn how to declare our sorts in a greater manner. We gained’t introduce declaration modifications usually – however we’re extra doubtless to take action than with runtime modifications.
Packages
A lot of the packages within the XState household declare a peer dependency on XState itself. We’ll be cautious about sustaining compatibility with already-released packages when releasing a brand new model of XState, however every launch of packages relying on XState will all the time modify the declared peer dependency vary to incorporate the newest model of XState. For instance, you must all the time be capable of replace xstate with out @xstate/react. However while you replace @xstate/react, we extremely suggest updating xstate too.
Final Up to date: 5/3/2023, 9:24:28 AM