I used it in the past and really disliked how it encouraged things like defining which functions to call by specifying a string with the function name. I would have much rather had it be more opinionated and require passing a reference to the function so it forces you to write code that benefits from typescript
Xstate: State machines and statecharts for the modern web
31–40 of 81 posts
Re: Xstate: State machines and statecharts for the modern web
#32Earlier quoted context omitted.
Almost everything can be written as a state machine and arguably it’s very useful to do so, for example let’s take a note taking app, you can probably list a set of transitions that can happen to change the state of the app. Keeping the state changes separate from the UI is a good thing. In a way redux is a state machine too. Try it out on a project and see if it works for you!
> Keeping the state changes separate from the UI is a good thing Why? Can you give an example?
ChatGPT it, it’ll do a better job than I will and it’ll be relevant to your requirements.
It’s the same situation as redux though but with more formality and it’ll draw you a nice diagram too.
“Hey ChatGPT, can you show me an example of using XState typescript library to separate business logic from UI code in a computer program and discuss why XState might be useful for this purpose?”
The example it gives is really incredible… and obviously you can refine what it’s doing in context for your own understanding.
Re: Xstate: State machines and statecharts for the modern web
#33I used it in the past and really disliked how it encouraged things like defining which functions to call by specifying a string with the function name. I would have much rather had it be more opinionated and require passing a reference to the function so it forces you to write code that benefits from typescript
There's many benefits in having a state machine configuration that can be serialized, especially if you can store that config in a database and load it at runtime. And actually xstate does allow you to pass the functions directly if you want to
Re: Xstate: State machines and statecharts for the modern web
#34I've seen XState more and more, recently, what are the pros and cons versus other state management solutions? Anything that XState fails at particularly that potential users should be aware of?
Verbosity, complexity. It's probably overkill for 99.9% of the things you imagine. Learning curve is more similar to rx-js or fp-ts than a state manager.
when you do get over the learning curve it's really excellent though.
Re: Xstate: State machines and statecharts for the modern web
#35Hey, creator of XState here! Just want to mention that we're very close to releasing XState v5 beta, which brings even more features to the state machines & statecharts you can create, and greatly improves the developer experience, but also makes it more usable as a general-purpose state management library (or orchestration "framework" if you want to consider it that), whether on the frontend or backend.
[deleted]
Re: Xstate: State machines and statecharts for the modern web
#36Earlier quoted context omitted.
The ubiquitous waiting/loading/error(msg)/success(data) Lots of frameworks and state management libraries already lean towards helpful design, in languages with async and ADTs as first-class citizens you've got a real leg up, but at the end of the day it comes down to preventing impossible states. You can't have an error message when in the success state, you can't have success data while loading or waiting. By preve…
I think this is solved more generally with a discriminated union in typescript. A state machine is the wrong solution unless you also need to restrict transitions themselves in my opinion
Statecharts are language-agnostic, whereas your proposed solution appears to be tailored specifically for TypeScript or other strongly typed languages. In this context, Statecharts offer a more versatile and generalized solution compared to your suggestion.
Re: Xstate: State machines and statecharts for the modern web
#37I was one half of a team that heavily leveraged XState in 2020. We used it to build a general-purpose kiosk app (in Electron) that could be updated remotely using an Xstate configuration served by a graphene-django app. One of the most technically impressive pieces of software I've ever had the pleasure to work on. (I mostly did server/backend stuff). The entire kiosk device could be repurposed on the fly and Xstate…
I'm also exploring xstate for a similar use case and would love to know more about your experience with it. I'm particularly interested in understanding the level of customizability you allowed in your implementation.
My use case involves implementing various user flows in my app and I'm currently weighing the benefits of using xstate versus react-router.
Also, I'm curious about how you integrated graphql into this project. Could you share some details on that?
Lastly, I wanted to ask if you stored all the different configurations on a database or on git? If you used a database, how did you manage different schema versions?
Re: Xstate: State machines and statecharts for the modern web
#38I'm a simple man. I just want to embed a state machine in my objects. I want to let it know when an event occurs. I want it to let me know when an event occurs. Sigh..
Found xstates desire too control everything made a simple embedding use case really awkward. The hoops to jump through for good typescript support while breaking the config down into reusable components...
Really wanted to like xstates but it felt like it was trying to own the entire app and was sacrificing usability for some version of academic purity. Also, feels like a huge marketing effort is under way to over fit it as a solution to any problem containing the word "state"; ie as a React state management solution..
Re: Xstate: State machines and statecharts for the modern web
#39The readme gives the example of a traffic light to demo a state machine usecase. Fair enough, but what's a rudimentary usecase for 'the modern web'? What everyday UI thing is better done with this than other methods? Why is it better?
> What everyday UI thing is better done with this than other methods?
All of them.
> Why is it better?
Because it specifies a workflow that actually matches what you want to do instead of employing a pile of ad-hoc rules that quickly become an unmaintainable mess.
If you have animations and async calls and multiple screens/pages, you have an application with application states which transition in response to inputs. That's what state machines are designed to handle.
Storyboards are state machines. Navigation components are state machines. UI binding layers like redux are state machines.
Re: Xstate: State machines and statecharts for the modern web
#40I've gotten good results from asking ChatGPT to give me Xstate representations of machines that I describe, very cool to copy-paste* into the visualizer as a starting point.
* Only issue is that with so much active development since the training cut-off it usually outputs deprecated structure / patterns.