Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xstate: State machines and statecharts for the modern web

github.com

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Xstate: State machines and statecharts for the modern web

#61

Post by julenx »

tobr wrote: post #51
davidkpiano wrote: post #14

Hey, 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.

Hello! I’ve looked at XState a bunch of times but always felt it seemed very involved for what it does. A simple “vanilla” state machine isn’t particularly complicated. Are you sure you need to bring “even more features”, or rather, what are your thoughts on how feature-rich a state machine library needs to be?

For vanilla state machines there's also @xstate/fsm. In their docs[1] you have a feature comparison.

[1] https://xstate.js.org/docs/packages/xstate-fsm/

Re: Xstate: State machines and statecharts for the modern web

#62

Post by xavdid »

baq wrote: post #12
a4isms wrote: post #4

Earlier quoted context omitted.

“ Any sufficiently complicated model class contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a state machine. ” –a former colleague

“I don’t need a state machine library” - everyone when starting a new project

I came across this code from 2-years-ago-me today:

      {/* the fact that i'm doing this means I probably should have used x-state or something */}
      {stages.filter(Boolean).length > 1 && (
        
          WARNING! More than one assumption is true! {JSON.stringify(stages)}
        
      )}
One day I'll learn...

Re: Xstate: State machines and statecharts for the modern web

#63

Post by ar-nelson »

davidkpiano wrote: post #14

Hey, 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.

Would you consider supporting Deno? (The npm module can probably be imported as-is in newer Deno versions, but a dedicated module is always nice and likely wouldn't be much work)

Re: Xstate: State machines and statecharts for the modern web

#64

Post by sanitycheck »

Rapzid wrote: post #38

I'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…

I had a similar reaction after trying it a couple of years ago. I only needed a fairly straightforward FSM for a video player UI, and I like to properly understand any libraries I use. Xstate seemed to have waay too much going on.

I ended up writing my own in about 80 lines of typescript in less time than it would have taken to finish going through the Xstate docs. Doubtless Xstate is exactly what's needed for some projects, but I suspect it's unnecessarily adding to the complexity of many more.

Re: Xstate: State machines and statecharts for the modern web

#65

Post by joshribakoff »

phpnode wrote: post #33
joshribakoff wrote: post #31

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

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

Yes it allows strings or references to the function. My issue is that since the former is allowed, either people start using that method, or you have to start a “debate” within your team about patterns to avoid.

The serializability of your state itself has nothing to do with how events are bound to callback functions. If you serialize a string name of a function and not the source code of that function this buys you nothing. The source code itself is all text, so its serializable no matter whether the code is suitable for being statically analyzed

Re: Xstate: State machines and statecharts for the modern web

#66

Post by instagary »

I tried XState for a mobile app.

Pros:

- The concept of states, events, and actions are an intuitive way to model state and the learning curve for me wasn't too bad.

- I enjoyed using the visual editor inside VSCode and after setting up TS, the codegen was pretty cool.

- The library supports parallel states.

Cons:

- The codegen was sometimes pretty bad for TS. There was some jank between the editor and the codegen, leading to frustrating DX.

Re: Xstate: State machines and statecharts for the modern web

#67

Post by illiarian »

davnicwil wrote: post #8

The 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?

Ultimately every UI is a collection of various (often contradictory) states.

Example: Even typing into a text box on Hacker News is a new UI state: you have a different set of shortcuts, the keyboard works slightly differently, the browser has to keep track of the input if you suddenly press back and then forward again (some browsers maintain input in these cases), undo has to work within the scope of the textbox etc.

The more complex your UI becomes, the more contradictory states become, and need to be tracked. We're posting something over XHR/WebSockets? X amount of elements on the page have to be disabled, some state has to updated with save progress etc. We are logged in/logged out? We need to show a different state. There's an error in some part of the app? We need to block user from doing something and show errors etc.

If you can split those into actual states and allow interface and actions based on the current state, it becomes easier to reason about what is going on ini your app

Re: Xstate: State machines and statecharts for the modern web

#68

Post by paultarvydas »

There is a HUGE difference between StateCharts and State Machines, yet, the difference is subtle.

StateCharts are the "Strucured Programming" version of State Machines.

StateCharts use parental authority instead of inheritance (my words).

A child state machine cannot override the operation of a parent. A parent can yank children out of their current states back to some known state.

OOP and FP don't encourage this kind of thinking.

The Big Deal concerning state machines is the "state explosion problem". Harel's StateChart notation conquers this problem.

My reading of the original paper is here: https://guitarvydas.github.io/2020/12/09/StateCharts.html

Re: Xstate: State machines and statecharts for the modern web

#69

Post by the_gipsy »

davnicwil wrote: post #58
the_gipsy wrote: post #53

Earlier quoted context omitted.

React expects and recommends you to use side-effects.

This is not my understanding of React - can you elaborate? Its original value prop was one way data flow and pure functional UI based on passed in props. It allows for side effects, to get certain things done pragmatically, but in my view does not encourage them in any way.

https://react.dev/reference/react/useEffect#what-are-good-al...

Re: Xstate: State machines and statecharts for the modern web

#70

Post by strangeattractr »

davnicwil wrote: post #8

The 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?

I use it for in component logic in vue. Used to have a collection of boolean or enum variables that represent the state of the component and change according to actions e.g. const isLoadingUser = ref(true). This works but often leads to unforeseen states being possible and just isn't very clear. In contrast, with xstate you define all states and legal transitions and wire everything up to send events, you can write guards that prevent transitions. I transitioned all my complicated multi stage forms to xstate and since doing so they've become substantially more robust. I highly recommend trying to out.
Post reply on HN