I can't overstate what a gamechanger state based development using XState + React with hooks has been for me versus a standard Redux/Flow architecture with class based components. It allows you to extract business logic from your components to the point that React becomes nothing more than a view rendering layer. This makes it way easier to understand the flow of your application and simply read through the statechart and look at the corresponding components for each state. No more parsing through giant component class files, dealing with lifecycles, or mixing logic with presentation. It allows you to build a fully deterministic UI where bugs become almost impossible to happen.
For those curious: XState is a JavaScript state machine/statechart library that doesn't invent any new concepts and instead adheres strictly to statechart principles and the SCXML spec.
Extremely same, but with Vue instead of React. In the last project I worked on, XState was a late addition, so it didn't control the whole application, but the part I wrote in it was bug free from the start.
My plan for any future JS/frontend project is to design the whole application's business logic around XState, and use Vue/React/Svelte/Whatever just for the rendering part.
That's ok. Anything publicly available you used as reference materials? I had a read through that site, but id love to see what's considered a good example in code.
From memory, one of the things we did was set up an event bus to communicate between xstate and Vuex. We only used the xstate.org.js and vuejs.org documentation, which are both very good.
How have you managed keeping your machine's state and context consistent? Although I can control transitions easily, I've found it's easy to miss updating parts of my machine's internal context when wiring up transitions. I wind up with my component thinking it's in a particular State, with a context that doesn't match up.
It is indeed. However, I've found the problem of writing assignment actions correctly is very similar to the problem of managing ordinary variables without xstate. I'm wondering if I'm doing this right, since I thought xstate was supposed to make that kind of bug much rarer.
Not quite the same thing, but the Blizzard game Overwatch is scripted in a state-machine based visual language called "Statescript" that has some similarities to this.
I thought that hierarchical state machine is a pretty standard programming pattern, but I've never seen the name "statechart" before. Is it the same thing, or are there any differences that I didn't notice?
I once used the Cartesian product of state machines to enumerate test-cases. Statecharts helped reduce the visual complexity. Wrote an article about it:
I was a web developer in college for an on campus organization that handled the web app for students applying for and selecting a roommate. After learning about state machines in one of my courses I decided to take the process and model it as a state machine, which made deciding what text to display and what options could be taken much easier than it had been before, with ad-hoc if statements about the various state involved.
That's cool. Could you elaborate? I'm the author of statecharts.github.io, and while I know state machines are widely used in embedded systems, I don't know much about how statecharts are (starting) to be used. I think it's a great fit.
