What has learning XState been like for you?

[mattpocock]

I'm currently in the process of adopting XState across our team as the way to manage state in our Typescript/React apps. We've hit some stumbling blocks, but also had some big wins that have convinced us to make a big bet on XState going forward.

How about you?

What confused you?
What did you notice was cool/different from approaches you'd used before?
What helped things 'click'?

[alavkx]

Forgive me for this low effort post but
I’m really struggling with actors. At a conceptual level they are simple but actually implementing them and understanding the hierarchies you’ve created and best practices are lost on me.

I found elixir’s visualization of the supervisor tree very helpful.

[davidkpiano]

They are confusing; it's another learning curve, but it's well worth learning because of how useful and prevalent (microservices, anyone?) actors are!

The updated visualizer will include a way to visualize an actor system.

[mattpocock]

Yes, I often get confused here too. It feels like there are many ways to do this well. For me personally, the hierarchical system of frameworks like React feels like it's fighting against the actor model, which seems more like a graph. An opinionated approach to this in the future docs would be helpful.

[Andarist]

Im not an expert but I think actor systems are hierarchical by nature as well. It’s just usually not the same hierarchy for your app as the one created by your components.

[dielduarte]

still learning, but I've used it once in production, here are my 2 cents.

What confused you?
coming from approaches like Redux, the first confusion I had was how to manage a global state, the actor model still something obscure for me. Would love to see more real examples about that.

What did you notice was cool/different from the approaches you'd used before?

• visualizing my actual code its a killer feature for me.
• I noticed I was spending more time modeling which ended up in a better solution + error-proof with less code as well (at least the features I managed to convert to Xstate)

What helped things 'click'?

• visualizing the code
• comparing solutions, I know it might not be a better way to learn things but works pretty well for me.

[DreaminDani]

I'm interested in using XState for a game but have no clear where to start. What belongs in a state chart vs properties on a class? I have a class for each character, item and action type... but what do I hoist to the top level? Should I persist states across scenes or re-run through the state chart every render?

For now, I'm just using an array of "commands to call to next" and I'm hoping a migration to XState will help with that.

[mattpocock]

What do you think would help you get started? Although you may not know if you're in the throes of the problem.

[DreaminDani]

I'm also using Phaser and can echo what @frehner stated below. Basically I'm not sure where to start when it comes to a top-level store. It was easy for me to wrap my head around a small state machine for something like a form field VS the outer state machine for an entire form, or even an entire web page.

Shifting to a game mindset, I guess I was looking for some examples on where the right layer to introduce XState would be, versus using more traditional OOP patterns.

[mattpocock]

Agree that where to place XState in the hierarchy of your app is not easy to answer, which is similar to what I described above in relation to the actor model. Well said

[frehner]

it was (and still is) unclear how to work with a single source of events + hierarchical state machines. For example, I'm using a video game library (Phaser.js) and have a machine that generally goes top level -> menu machine / playing machine with playing machine having more nested state machines (e.g. rotation machine, thrust machine, weapon machine, etc)

The phaser library provides a way to get which directions are pressed, but the actions that happen should depend on if I'm in the menu state or in the playing state (and deeper) -- up in menu means I'm just navigating the menu, but up in playing means thrust.

The issue is that I don't want to have the playing machine need to translate and then send the events for each submachine. So should I just pass down the phaser.js input controls as context to each submachine? Or is there a better way?

Anyway, just something that I wasn't clear about how it should work, and there weren't a ton of examples/explanations around it.

Still enjoyed using xstate though. The chat was generally helpful. The docs were helpful at a surface level but then digging into advanced cases there didn't seem like there was much guidance/examples

[DreaminDani]

Hey there :) Does your game happen to be open source? I've been scouring the web for examples of using state machines for Phaser and haven't found a good reference. If you happen to be using a testing framework with it, I'd love to pick your brain as well. I've been having difficulty choosing the right layer of abstraction for unit tests and ran into mocking hell before giving up xD

Edit: I found a code base. Thanks for making your experiments open source!

[frehner]

sounds like you found it, but just in case - it's here https://github.com/frehner/phaser-subspace (note: it's bad code ;) )

I didn't ever get around to testing, since it was my first time using both phaser and xstate (too big of a pill to swallow probably haha) but would love to see if you find anything. Thanks!

[Perlkonig]

It has actually been not too bad for me. I think the documentation is very well written and easy to follow. The visualization engine is epic.

What has challenged me (unsurprisingly) is mapping the new-to-me idioms of FSMs to the more-familiar-to-me idioms of good ol' declarative programming. I, too, am implementing a simple game engine (I'm sensing a theme here), and my first instinct for issuing commands to the machine was to use events. I thought I'd issue the event with a payload, the payload would be processed and then transitions checked, but I quickly realized you don't put actions on events, only on states and transitions. Instead I needed to create intermediate transient states that act on the event payload and then transition to the result state.

It took an hour of grappling with the concepts before I figured things out, but some examples may have been helpful. Once I do get my code working, I plan on circling back and seeing if there are any concrete suggestions I can make for the docs, which, again, I find to be quite excellent already.

[Andarist]

I thought I'd issue the event with a payload, the payload would be processed and then transitions checked, but I quickly realized you don't put actions on events, only on states and transitions. Instead I needed to create intermediate transient states that act on the event payload and then transition to the result state.

Could you give a more concrete example of what you were trying to achieve? We might have some hints on how you could avoid intermediate states, but we would have to learn more about what you are trying to do.

[Perlkonig]

Well in this case, an ASSIGN command with a payload telling the game what to assign where. My first instinct was to have some action trigger when the event was received. Instead I transfer to a processing state that takes care of the payload on entry and then transiently moves to a new state based on the new board situation. The code looks like this (not yet working for other reasons):

assigning: {
    initial: "rolling",
    states: {
        rolling: {
            entry: [rollDice],
            always: ["waiting"],
        },
        waiting: {
            on: {
                ASSIGN: "processing"
            }
        },
        processing: {
            entry: [assignDie],
            always: [
                {
                    target: "..resolving",
                    cond: "searchFull"
                },
                {
                    target: "waiting",
                    cond: "stillDice",
                },
                {
                    target: "rolling",
                }
            ]
        }
    }
},

[CodingDive]

It feels to me like you're better off to simplify your state structure and just have an idle and processing state (unless the rolling of a dice is async which it is not since it's being done in the entry action).

Instead of the transient station, you can simply have multiple possible transitions arise from a single event.

idle: {
  on: {
    // event sent from the client or your game engine machine
    ROLL: {
      actions: ['rollAndAssignDice', send('DECISIVE_ROLL')]
    },
    // I treat this as an "internal event" 
    DECISIVE_ROLL: [
                {
                    target: "processing.resolving",
                    cond: "searchFull"
                },
                {
                    target: "processing.waiting",
                    cond: "stillDice",
                },
                {
                    actions: send('ROLL')
                }
    ]
  }
},
processing: { /*...*/}

So, that seems like a weird trade off to introduce another event, increasing the api surface area of your machine just to remove some transient nodes but this pattern brings about even more benefits as sometimes you'll realize that the value is not even needed in context. All you want to do is to roll once, then run all the guards against the same value to decide the state you'll end up with. Therefore, you could also pass the value of that execution as the payload of the event and (sometimes) don't need to assign the value to context.

ROLL: {
  actions: send({ type: 'DECISIVE_ROLL', rolledDice: rng(1, 6)})
}

Your guards would check event.rolledDice instead of the context. That's something you can't yet do with transient transitions, because you always lose the payload (event.rolledDice === undefined) similar to delayed transitions of #1155. As a result, you could bloak up your context with temporary, internal values.

[Perlkonig]

Thank you for these insights. Your solution doesn't really work in my particular case because of the game rules. The engine rolls two dice, and then the player assigns them to various places on the board, one at a time or both together. Only if both dice have been assigned should two new dice be rolled, and that process continues until the board is full. So the actions of rolling and assigning dice can't be combined.

[Andarist]

Note: in v5 transient transitions wont 'lose' the data of the original event. Right now the problem is that event is bound to a NULL event generated internally, but according to the SCXML this is just a pseudoevent. It doesn't really ever appear publicly and event should stay bound to the last processed event.

[skywinston]

I refactored our subscription process from Redux to XState. The state & business logic contained in this problem set is highly complex due to our product mix and industry.

Long story short: I eliminated all outstanding Airbrake errors reported and haven’t seen any new ones come in since the refactor shipped.

The largest benefits to me were as follows:

• Much easier to trace code execution (its all in the state chart) vs Redux where you have to read through 3-5 files per action.
• The effects lifecycle (enter, exit, transition) helped me mentally connect state changes and their side effects much more easily than Redux.
• Expressing our business logic in a view-agnostic way (the state-chart) actually forced me to build a better system than I would have otherwise.

The opportunities I see for XState are:

• Making it easier to work with extended state. The assign action feels clunky as each key in the object holds the same function signature. I’m a big fan of the xstate/immer approach and kind of wish this was the default way for working with extended state. It’s far more terse and easy to reason about.
• On a related note, “Context” is a suboptimal name, especially as it has so many other connotations in modern Frontend code bases (React Context, GraphQL resolver context, etc). I think “data” would be more to-the-point.
• I like the idea of patterns like Async services having a distinct shape within the state object (onDone, onError, src) and would love to see this approach extend to other prevalent patterns like form validation.
• Side effects that affect the DOM tree are difficult to set up and reason about. Should I put a react ref in context or should I send an event to the machine in a useEffect hook? They both work, but I would love to see the library have a first-class, sanctioned approach to DOM side-effects.

Overall, my experience with XState has been tremendous and I believe the docs are already really damn good. Most of the improvements I’d like to see at this point are around developer ergonomics and more concise syntax. It’s one of my favorite libs and has been very influential for me in building better software.

[davidkpiano]

Thanks for calling it "opportunities" 😄

Making it easier to work with extended state.

Yeah, that's part of the reason for @xstate/immer as directly mutating context was infeasible (for obvious reasons). I'll have to explore what it would look like to "build in" an Immer-like API for assign (opt-in, of course).

On a related note, “Context” is a suboptimal name, especially as it has so many other connotations in modern Frontend code bases (React Context, GraphQL resolver context, etc). I think “data” would be more to-the-point.

That's understandable. The naming came about here: #149 - I think we decided (in various discussions) that data shouldn't be used as it has a specific meaning in SCXML (<data> refers to a single value, and there's <donedata> to add to the confusion), and context is used in other statechart implementations:

1. https://states-language.net/#context-object
2. https://sismic.readthedocs.io/en/latest/code.html#code-evaluation

I like the idea of patterns like Async services having a distinct shape within the state object (onDone, onError, src) and would love to see this approach extend to other prevalent patterns like form validation.

What would an ideal API look like for this?

Side effects that affect the DOM tree are difficult to set up and reason about. Should I put a react ref in context or should I send an event to the machine in a useEffect hook? They both work, but I would love to see the library have a first-class, sanctioned approach to DOM side-effects.

None of the above - effects of any kind should be actions. The upcoming @xstate/react v1 (right now in rc) will provide asEffect and asLayoutEffect to make it easier to define effects that need to keep in sync with React component updates:

const inputRef = useRef(null);
const [state, send] = useMachine(someMachine, {
  actions: {
    focusInput: asEffect((ctx, e) => {
      inputRef.current?.focus();
    })
  }
});

// ...

I really appreciate your comments!

[DirkWolthuis]

For the most part good, lots of helpful people in the community! I’ve had some questions and you guys always answer them. Thanks y’all! I think the docs are good, the provide a lot of info about statecharts in general. I’ve not yet sunk my teeth into actors. The part I’m struggling the most with is implementation and structuring the logic of statemachines. Other state management tools have a of opinionated content about how to use their tools. Redux has a style guide about how to tackle problems with Redux. That is what I’m missing in Xstate, examples on how and why to tackle problems in a specific way. And in my case, how to write good React code around my state machines.

Having said that, I love the tool and community. And state machines off course. Going to give my colleagues a trying about xstate and state machines. <3

[davidkpiano]

Thanks, @DirkWolthuis!

I would say that the way that state machines and statecharts are structured is already heavily "opinionated", much more so than Redux, etc. But it forces you to think of problems in a different way - by modeling them as states, transitions, and actions - which is definitely the hard part, because there's no "right" answer, and (mathematically provable) there are many ways to create different state machines that do the same thing.

in Redux and other libraries, there is no structure for this. E.g., it's just a reducer (or a collection of reducers) where state can change in some arbitrary way. There's no sense of orchestration or flow, as that's left as an exercise to the developer to implement (usually in a haphazard way).

[DirkWolthuis]

@davidkpiano i hear you, I think it’s more my insecurities than anything else. Through the vast exposure of other state management techniques I get a feeling if I’m doing it in a good way. It’s hard for me to say the same about my Xstate implementations. Simple questions like when to break up a machine. How to pass a machine around as global. I know there is no right way, but I would love to see some examples of community members how they tackle those problems.

[davidkpiano]

I'll definitely be making more examples, and even providing a centralized way for the community to share examples.

[dustinknopoff]

I'd say 4 main things I've run in to:

1. Getting Typescript to work with React Context, I've referenced this issue a bunch in attempting to get it to work. (Eventually got it)
2. I wish strict: true was emphasized a bit more in the documentation. A couple times I've spent a solid 30 minutes sending an event to the wrong state and not realized.
3. sending events or actions that need to run in order. I've figured it out eventually every time but it took a couple days to shift my thinking to how state sees ordering.
4. Learning the rules of what can be sent within another xstate action. (i.e. send inside action, vice versa, when to use pure etc.)

But, it's otherwise been fantastic to use. I've refactored been refactoring a homegrown React Context and every feature I refactor to use xstate is either more elegant, simpler, or as easy to understand as the way it was done previously.

[davidkpiano]

Thanks so much for the feedback!

sending events or actions that need to run in order. I've figured it out eventually every time but it took a couple days to shift my thinking to how state sees ordering.

Can you provide an example of this?

[dustinknopoff]

The simplest example I can think of is a problem I'm currently working on. The project's main data source has screens with descriptions of different data types to display on each screen. Only one screen is displayed at a time, so the context also holds on to a current index. One of the functionalities I need to implement is deleting a screen. If the current index is the last screen, then I need to change the index beforehand. I've been attempting to solve this bounds check before sending events to the machine. The ordering of these events as not been reliable. (i.e. send(SET_INDEX...); send(REORDER_SCREENS), send(SET_INDEX...) && send(REORDER_SCREENS...), send([{ type: SET_INDEX,...},{type: REORDER_SCREENS, ...}). But, while writing this example I've realized that if I make another event DELETE_SCREEN and handle the index change within an action, it should work.

tl;dr This might just be another example of not fully embracing/understanding/leveraging xstate and basically butting heads with the learning process and not xstate or it's documentation