🔎 In the wild! Where are you using XState?

[davidkpiano]

If you are using XState in a project/at your company, please post it here!

I'm working on a new "In the wild" docs section (related: #172) and I would absolutely ❤️ to highlight projects that are using XState (version 3 or 4).

If you have:

• a (personal?) project in production that is using XState (front-end or back-end)
• OR are at a company that is using XState internally
• AND you would be happy and willing to share that you're using it

Please post it here. 😄🙏

Thanks in advance! 💙

[famulus]

At https://bridge21.com/ we are re-writing our site using XState 3 and react-automata. It's a game changer.

Our onboarding is complex with many loops in the process. The stateMachine pattern reduces fragility, making it way easier to add features without breaking past work. I love being able to see the entire app in the visualizer.

Our stateMachine has about 90 states so far! All of them quiet necessary.

react-automata makes building state dependent interfaces easy <State is={['*.onboarding.*', '*.returnCustomer.*']}> ... </State>

[paul-f-maxson]

It's not much but I made a Pomodoro Clock emulator using React and XState with no other intermediary library. I'm using Hooks to subscribe individual components to an XState service.

[adamkl]

Sorry I can't say anything "official" one way or the other, but I thought you'd like to know that we're starting up an internal proof-of-concept at my company to explore the use of XState.

We're really interested in the potential of pairing up designers and developers (leveraging something like Sketch) to work together on application flows and behaviours. We can see a lot of use-cases for this approach.

Depending on how things turn out, I hope to circle back with more details in the future.

[davidkpiano]

@adamkl That's awesome, please keep me in the loop! One of the major goals for XState is to be integrated into design environments, similar to https://overflow.io.

[davidkpiano]

Bumping this 😄

[dhmacs]

We'll release soon a Shopify app, and we started experimenting with Xstate.. I'll let you know as soon as we ship it and I have an url

[a-y-u-s-h]

Any update on this? Is the code going to be open sourced?

[a-y-u-s-h]

Nevermind, saw your comment below.

[jonlaing]

Working on a POS system with my clients currently. I'll ask them if they'd be cool with me putting it up as an "in the wild" example. I'm sure they'll be fine with it, but I don't want to jump the gun if they have objections.

[darrenjennings]

Deployed to production in Kong to handle form states (error, loading, modal, fetch machines etc.) in our Vue app: https://konghq.com/products/kong-manager/

[hnordt]

Using XState 4 extensively in 4D Healthware's frontend app.

[alizbazar]

We are using XState at Meru Health in our React Native app for managing many interactions. I just gave a presentation of using XState at React Helsinki - check it out! 😊

[carloslfu]

I used XState in a touchable app for the Royal Tyrrell Museum (Alberta - Canada) and documented its use in this article: "Modeling a Screensaver with a Statechart, a real use case".

[bradwoods]

Used XState for the navigation of a keg analytics web-app BinaryBeer.

[dhmacs]

Used XState to model data fetching and filtering of a collection of products 👉 stimm.com

Note: Filtering is done client side for platform limitations

[geddski]

Using xstate like crazy in https://serviceworkies.com and all my future games.

[sigfriedCub1990]

I've seen couple of games you made, they're really good and I'm sure you learned a whole lot by playing them. I'll give Service Workies a try since I have some interest in Service Workers. Thank you!

[ZempTime]

We're now using xstate to power a couple of the more complicated interactions at my place in our Behavior Insights Engine at Maritz.

[carloslfu]

We are using XState for coordinating very complex flows on a video-call cross-platform application at @withyourtribe. https://www.withyourtribe.com.

[ratacat]

I've been using xstate for some of the components of a bot I'm writing that lives on the ethereum network. I love it! It's been a total game changer for me, and is extremely reliable. I think that as it's closer to completion, it will be substantially more advanced than other similar bots on the network are. Also it's behaviors will be easier to extend and improve upon I think. Thankyou so much @davidkpiano !!

[JayNaire]

I retired from electronics & s/w engineering last century.
I am trialling Xstate for its visualisation capabilities and the remorseless burden it puts on me upfront to be very clear in my mind what I want my DIY embedded boiler control system to do at every stage without having to write too much code.
(I used Node Red for prototyping a lot of Home Automation stuff. It's terrific but suffers when developing / debugging systems with many control and failure modes, events and states.)
I hope that Xstate will help me particularly with:

1. Replaying events that drive my system into "weird" modes.
2. Getting the system hardened against brownouts, sensor failures etc.
3. Answering questions like "why are you doing what you're doing right now?" at a glance.
4. Making it easier to change control algorithms if necessary.

Using FSAs in the '80s these kind aspirations were seriously hard work; costlier than the projects I worked on would bear.
With Xstate they look eminently achievable - and fun too!

Thanks and good luck @davidkpiano

[tomByrer]

Ironically enough, if I ever teach XState, it will be using 'hardware' examples.

[moh12594]

Hello !

At https://www.frichti.co/ we also use xstate in order to handle all our different states !
A really good move from Redux for a better readability, a fully declarative approach and a really cleanest code !

Thanks for the big work @davidkpiano and all contributors 👏

[mrsln]

At Fugo.ai, we are building a modern Digital Signage CMS. We are using XState in our players (web version) and in our Design Studio.

[DanCouper]

At ThingCo, I've been using it for the past year and a half to manage authentication flows on mobile and web applications (React and React Native). Built a library to wrap the functionality. Sorry for this brain dump but:

It's quite a complex machine, one that has to be configurable per client (OTP or username and password, PIN or biometrics, with various other options that relate to authentication flow/device security). The flows are a sequence of async calls, and I've gone back and forth over the best ways to handle this. Also using Typescript, which I've found to be a double-edged sword w/r/t to XState configuration.

The library has been through four major iterations now, and I'm tended to agree with most of the observations made in this critical analysis of statecharts (PDF link). I think XState is the gold standard for state machines/statecharts in JS/TS, and I can't see myself using anything else in similar situations to the complex sequential flows I've built, but there's been quite a bit of pain.

So the library is structured with a core machine that controls the auth state. That is created via a factory function that allows me to inject config at build time (or in test apps, from a parent React context that does the same thing). That machine is interpreted in a context provider, accessed via hooks in-app. States essentially represent "screens" in the apps.

Initially, I wrote a single machine that made use of invoked promises. This rapidly became unmanageable. Context grew, states exploded.

So second, third iterations split out functionality. The second iteration used nested machines. This caused severe TS typing issues unless I inlined everything (which defeats the point somewhat).

The third iteration used actors, which enabled some nice properties. The context had become pretty populous, and I could reduce that to almost nothing, keeping values within actors. The parent machine could just have an overall state, and that would be what the app used for the app screens, and things like loading/error states remained within the actors. So for example, when making the initial sign in, the actor for the username service starts, it has an idle state for awaiting input, then on input, switch to a loading state, then on success store the response object, tell the parent that was complete, etc etc.

This worked, but instead of a state explosion, I got an event explosion. Events had to be defined for both parent and child machines. The number of actions also exploded, because I had lots of small contexts to manage + the parent context. Loading was a problem: there are about 20 different possible async calls, and each time one was invoked, the parent had to be notified. When it was resolved, the parent had to be notified. When there was an error, the parent had to be notified. Then I had to manage starting and stopping of actors. Started using enums extensively to define state ids, action names, guard names, event types, which was horrible but prevented mistakes. Responses from invoked promises have their own internal event types, so all those had to be typed. It all worked and worked well, but it was a nightmare from a developer PoV.

About this point, the model API came in, which has been really useful from a TS point of view. However, there are three main issues I've had with it:

• the state IDs are no longer defined up-front and so I get no type inference. With complex machines, this is a major annoyance. Due to this, state IDs are the only thing I've retained enums in the codebase for.
• the event creators I liked at first but dropped them in favour of just defining a union type and passing it into the model's generic parameters. The issue is that the type often (depending on where in the codebase I'm using it) isn't just a simple { type: "MAI_EVENT" }, it's a nasty FinalEventCreators<> thing that's difficult to work with. Just using plain objects ended up being far easier.
• was still getting loads of type issues, so reverted to using createMachine<typeof Model -- I realise this option has been removed in the latest release so I'll need to do some tweaking when I upgrade (hopefully most of the issues I've had re typings have been nixed by now).

So final iteration.

• Dumped actors and just have a single state machine. This means no need to manage multiple machines and the message passing required to herd them, much easier to handle from a cognitive perspective.
• Dumped invocations. This means there is no need to carefully handle the responses within the machine. It also fixed a huge issue we had, which is that putting the async calls within the machine meant a. that I had to build a facade for the APIs we use and pass that into the machine factory, and b. that making the calls within the machine logic effectively hid everything and made it incredibly hard to debug -- things would just silently fail, and it was often almost impossible to figure out why as all the logic was hidden.
• Dumping invocations means no loading states, which is great

So one machine, almost standard-traffic-light-example simple. Then each state has a corresponding hook (because the state IDs are string enums, I can then use string templating in TS to ensure all states are covered and all states have corresponding selector functions). The hooks accept a callback, which is the API call relevant to that state. This makes debugging them very easy, allows for mock test versions to be injected, and dispenses with having to make API facades. The hooks all return a primary method, which is a function that takes the callback passed to the hook fires it, sending the correct events into the machine at the correct times. This also moves loading/validation errors etc out of the machine context.

Overall, model testing is very good if a bit slow -- @xstate/test works excellently, I've got it set up with Jest/React testing library to thoroughly exercise the machine and the hooks that trigger all the machine events, and it's great.

The new visualiser stuff is very nice (although running in watch mode when developing and it switching the tab to the visualisation on every code change has been driving me slowly insane for the past three months).

Library is great, anyway, apologies for the wall of text. Work I've done is internal, but I may be able to share the structure we have as it doesn't contain any business-specific logic (it's mainly all AWS Cognito-related stuff), I'll have a check

[mattpocock]

@DanCouper You might get use out of the VSCode extension! This means you don't need to swap tabs, and can also validate state names for you (no more enums!)

https://marketplace.visualstudio.com/items?itemName=mattpocock.xstate-vscode

[mattpocock]

Also, would this assist with the event explosion? It means that updates down the tree between spawned machines can be more declarative:

https://twitter.com/mpocock1/status/1440356513332162575

[DanCouper]

@mattpocock sorry for late reply, but the VSCode extension looks good so far. Wee bit of an issue that I've just switched to vim as my primary driver but hey ho. I think my main issue (bar annoyance) with the inspector's current behaviour is that from a DX PoV I'd like to simply turn it on or off, which turns out to be quite difficult (and I don't really want to spend time writing a version of the inspector just for my project). This should be useful as a sticking plaster for that though!

Re that useQuery proposal, that does look really interesting, it may well salve some of my misgivings. I want to revisit spawning machines, dig into it a bit further, but it's still clunky atm and I'm not sure the extra complexity is worth it. I use Erlang (well, Elixir) a bit, which coincidentally uses something similar to the actor model (as mentioned in the XState docs). But with that, there's a toolbox of stuff to handle processes if needed (and generally explicit FSMs aren't needed due to the pattern matching capabilities of the language). For example, everything is set up and supervised in the same way, there is a Registry module that acts as a process ID library. Whereas XState doesn't have these tools or conventions; I mean, it's just a library not an ecosystem, but at the same time I feel like it needs some tools in place to help if an actor-like model is being used -- useQuery, though obviously React-specific looks like one of those things

[zacharyweidenbach]

I appreciate this post, as I'm on the lookout for cautionary tales with xstate, because it seems like a good way of standardizing UI architecture on a team, though it can feel "boiler plate-y" for simple UIs.

In your case, I wonder if the primary source of your woes was that network response caching responsibilities were entangled with application and business logic. From what I could understand, you have a machine that controls the overall state that your UI should be in. But on top of that, you added the responsibility of managing api response data and errors (by storing it in the context of the machine). I wonder if you delegated that responsibility to something else, you could have avoided the spiraling complexity that you encountered. In a way, it sounds like that's ultimately what you did with the hooks. The hooks took on the responsibility of both choreographing the network requests, and sending an event back to the machine to move on. Conceptually this feels odd, because now your business logic for the network requests live in your view layer (react) and the machine is simple to the point that it could be replaced with react's useReducer instead (although you don't get model based testing or state charts).

I hit a similar stumbling block when trying to build a network layer with xstate. My problem was, if a machine's primary responsibility is to manage the UI of a screen, and its lifecycle is tied to that of the UI, it needs to access an api cache that predates it, and lives on after it stops (when the user leaves that screen, the component unmounts, and the machine stops). When I tried to delegate network fetch and caching responsibilities to another child machine, the parent machine invokes or spawns this child network machine, but the fetch response/error data maintained in the context of this child machine lives and dies with this child machine, as you probably found. I could send the api response data or error upward to the parent machine to manage itself. But if I have many requests happening on a given screen, then that becomes unwieldy (as you found). Worse still, if I have api response data that needs to be displayed on my UI in a more global component (like a user's first/last name in the nav bar) and it is edited by a fetch request in a deeply nested machine, I now have a really difficult problem of propagating that data out to another machine higher in the component tree.

Instead, if I delegated the storing of api responses and errors to something else that wasn't tied to my UI machine's lifecycle I could strike the right balance, where the machine controlling my UI's state could invoke the fetch promises as services (through a constrained interface exposed to it from my network layer). But the actual storing of the response or error lived in the network layer, and could be accessed directly in the UI machine via the interface exposed by the network layer. On the react side, the component could subscribe to the same api data/error via a hook (also exposed by the network layer), so that it could rerender when the data changed, just like you would if it were coming from context or redux or any other reactive source. The network layer functions as the single source of truth and provides a means for machines and react components to access the api response cache.

In your situation, you'd still need to configure what to do if an error occurs, but the onError as a result of the invoke service feels like a pretty natural way to deal with errors, now that the overhead of storing those errors is managed elsewhere.

Apologies ahead of time if I misdiagnosed the true root of the problems you faced.

[dvanderweele]

Realize I'm necroposting, but there are a few VIM extensions for VS Code that work okay. Nothing beats the real neovim of course, but even so.

[GuillaumeAmat]

We also use XState at Back Market 💚

The library itself, that lovely editor of yours and probably soon, the visualizer embedded in back-office pages, to better share the implemented logic with the stakeholders.

Looking forward to the awesome v5 in the making 🙌

[zacharyweidenbach]

I've recently refactored the bootstrap and authentication phases of a react-native app with great success. I've worked on this app on and off for the last 3 years, and this is the first time this area of the app feels organized and manageable.

To give more background, the bootstrap phase of the app has some unfortunate complexity due to design decisions made by the backend team. The api requires a session cookie in order to recover cached details about an authenticated user. The unfortunate thing about session cookies between iOS and Android, is that iOS will forget them after the app is force closed or garbage collected, whereas Android won't. This is because of the underlying implementation of session cookies between platforms. iOS uses Safari's implementation while Android uses Chrome's. So, the problem on iOS was that the app would open fresh with an access token in it's cold store, and try to use this token to make authenticated requests, but would not have a session cookie. The api would see the request as authenticated, but assign a new session cookie to the client, and subsequent requests to other authenticated endpoints would fail because the api could not recover the necessary cached data on this newly assigned session cookie that wasn't properly associated with an authenticated session. Phew.

So now the app needed to open, check if it had a session cookie in its cold storage, if it did it would rehydrate this into the device's cookies.

Next, the app needed to make a call to a configuration endpoint to get instructions from the api for how to authenticate (which IDP host to call, what client id to use, etc). If the app didn't have a session cookie, this is when it would be assigned one. After this call, the app needed to persist this cookie into cold storage for safe keeping. On top of this, there were various other setup events that needed to occur, such as configuring a background geolocation plugin, etc.

With xstate, this sequence of events could be very explicitly modeled as a state machine that does each async step one after the other in a BootstrapMachine. It now reads like a recipe of stepwise events that are all colocated, and a failure at any point along the way can have very clear error logging, and failing forward to the next step.

We have also just introduced codepush, and we need to polish the user experience to show them some UI feedback while codepush installs a new OTA update and restarts the app. It is super easy to visualize how this can live in the BootstrapMachine, where the app can be made to show this codepush OTA download/install UI feedback before restarting, checking that it has the most up-to-date codepush version, and continuing on to mount the rest of the normal app.

Then there's the authentication sequence in the app, which requires 3 different endpoint calls before we can consider the user authenticated. Previously, this was managed by a series of react component containers that would conditionally mount their children after a given request was completed. This led to the request logic being spread across several components, and made working on anything to do with authentication a painful experience. With xstate, the complexity of this sequence of calls was drastically simplified. The retry logic, and logout on failure of any of the necessary requests because super simple to visualize, handle, extend, add additional analytics, you name it!

XState really did wrestle the complexity of these various stages of the app into a very manageable, extendable, readable list of steps. I really can't emphasize how long I've struggled to find a better solution to this complexity. I started with redux and sagas, then react-query, and finally this. It finally feels manageable.

[bmadone]

I use this in my pet-project (aka clone of Toggl, Clockify) for Timer feature, code is open sourced and can be found here https://github.com/bmarvinb/moggl/blob/main/src/features/timer/machines/TimerMachine.ts

And this is how machine looks like

[hsndmr]

https://github.com/hsndmr/xstate-quiz-app
This is a quiz app built with xstate and react. It is a simple quiz app that has 10 questions and the user can choose one of the 4 options for each question. The user can also go back to the previous question and change their answer. End of the quiz, the user can see their score and can restart the quiz.

[UberMouse]

The newly launched koordinates v10 UI is almost entirely built with xstate and xstate-tree

[hsndmr]

https://github.com/hsndmr/nestjs-auth-starter
The NestJS Auth Starter project is a starter project for NestJS that provides authentication and authorization functionality out of the box. It is built on top of the popular NestJS framework and uses the mongoose library to access the database. For authentication and authorization, it relies on the powerful jsonwebtoken library, while password hashing is performed using bcrypt. Additionally, the project utilizes the xstate library for state management in authentication cases, and includes tests for all cases. With this starter project, developers can quickly set up a secure and robust authentication system in their NestJS applications.

[radiodario]

Hey, i thought i'd contribute to this - we are using xstate on Anyone (closed source) - a voice networking app with 5 minute calls written in react native. We use it for the whole phone call flow, signup process, matchmaking for in-app events, post-call reviewing of users, etc. We're so grateful for all the hard work on this awesome library - and the efforts of the community!

some of the machines we have:

[davidkpiano]

This is awesome, thanks for sharing!

[gavination]

These projects are all brilliant to see! Bumping this thread to breathe some life back into it!

[oscarmarina]

Hi !

The XstateReactiveController is a Lit Reactive Controller specifically designed for straightforward integration with XState.

• https://github.com/oscarmarina/XstateController

• https://stackblitz.com/github/oscarmarina/XstateController?file=README.md

[christophe-g]

@oscarmarina - thanks a lot for posting this - was just about to create the same reactive controller !

[oscarmarina]

Hi @christophe-g, I'm pleased to hear that the code is helpful for you! 🚀 I wanted to let you know that I've just uploaded a new version. Now, the Lit controller is consumed as an independent package on NPM. Feel free to check it out and let me know if you have any feedback! (stable version ^5.2.1)

• https://github.com/oscarmarina/XstateController

• https://github.com/oscarmarina/blockquote-web-components/tree/main/packages/controllers/blockquote-controller-xstate