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

51–60 of 81 posts

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

#51

Post by tobr »

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?

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

#52

Post by henrydark »

davnicwil wrote: post #50
capableweb wrote: post #41

Earlier quoted context omitted.

As a huge proponent of Statecharts, I agree. If what you're doing is really simple and only have a few amount of states (as conditionals introduce those states no matter if you use state machines, statecharts or conditions), it makes sense to keep things simple. But once you start having much more than that, or nested states, Statecharts makes it really easy to build reliable, performant and easy to change flows.

I can see that. Do you have some examples of common UI usecases which are the other side of the line here and for which statechart based code is better?

the original paper by David Harel has a marvelous long example of his own digital watch, highly recommended

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

#53

Post by the_gipsy »

davnicwil wrote: post #48
lioeters wrote: post #46

Earlier quoted context omitted.

For example, the browser extension Redux DevTools implements "time travelling" by taking snapshots of the entire state on every state change. This is enabled by the fact that in Redux, state changes are separate from the UI. This same principle can be used for undo/redo history. Another example is sending and receiving state changes from anywhere other than the UI, such as via WebSockets in a collaborative editing en…

Got it, makes sense. At least in React this has been the long-understood default expected pattern though right? Like, you pass down props from something higher up. Is this a property of state machines or a library like this one? Not trying to be pedantic I promise, I really want to see the value of this, but not sure I can without an example clearly comparing this against just a few if statements or something in pure…

React expects and recommends you to use side-effects.

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

#54

Post by joemckenney »

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?

User onboarding, setup wizards, feature announcements, or, more generally, the modeling (and maybe implementation) of incremental, progressive user flows. The only caveat is that they tend to require the machine's state to be persisted so that the user doesn’t experience the same state(s) again.

Truthfully, using state machines at runtime for the use cases above is sometimes too heavy. That distinction is actually a big input to what I’ve been building at Dopt.

Our platform lets you build state machines that are initialized per user in your application via our SDKs—you design the machines in the platform, and we provide APIs to let you transition them based on user interaction/input. We’ve taken a bunch of inspiration from Xstate and statecharts. I actually wrote up a blog about how we took inspiration from the latter https://blog.dopt.com/state-machines-and-their-influence-on-...

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

#55

Post by capableweb »

davnicwil wrote: post #49
capableweb wrote: post #36

Earlier quoted context omitted.

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.

general is not always better though. There's a tradeoff to other things like readability. If a TS typed switch statement, say, offers the same guarantees of covering all options yet is just run of the mill JS that anyone can read and instantly grok, and covers 99% of usecases in run of the mill web dev product work, then to me that's an argument that it's the better solution.

I agree with you, as mention in another comment (https://news.ycombinator.com/item?id=35331199), that if you can cover all the cases with conditionals and you don't have nested states, don't use Statecharts. Just like distributed architectures are not for everything but more advanced use cases, so is Statecharts. It's a tool to help you manage great number of states, not just a couple.

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

#56

Post by lerchmo »

a-dub wrote: post #24

any thoughts on a custom DSL for defining and verifying abstract state machines and then machinery for generators for different languages/libraries/environments/visualizations?

I have been using this XState alternative https://github.com/StoneCypher/jssm

I find the DSL much easier to wrap my head around than the json format of Xstate.

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

#57

Post by mananaysiempre »

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?

This is only incidental to your actual question (unless you’re into making widget toolkits), but have you seen the state diagram for a button widget[1]?

[1] https://web.stanford.edu/class/archive/cs/cs103/cs103.1142/b... (requires pointer and not touch input)

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

#58

Post by davnicwil »

the_gipsy wrote: post #53
davnicwil wrote: post #48

Earlier quoted context omitted.

Got it, makes sense. At least in React this has been the long-understood default expected pattern though right? Like, you pass down props from something higher up. Is this a property of state machines or a library like this one? Not trying to be pedantic I promise, I really want to see the value of this, but not sure I can without an example clearly comparing this against just a few if statements or something in pure…

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.

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

#59

Post by davnicwil »

henrydark wrote: post #52
davnicwil wrote: post #50

Earlier quoted context omitted.

I can see that. Do you have some examples of common UI usecases which are the other side of the line here and for which statechart based code is better?

the original paper by David Harel has a marvelous long example of his own digital watch, highly recommended

thanks, I'll check this out!

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

#60

Post by lioeters »

davnicwil wrote: post #48
lioeters wrote: post #46

Earlier quoted context omitted.

For example, the browser extension Redux DevTools implements "time travelling" by taking snapshots of the entire state on every state change. This is enabled by the fact that in Redux, state changes are separate from the UI. This same principle can be used for undo/redo history. Another example is sending and receiving state changes from anywhere other than the UI, such as via WebSockets in a collaborative editing en…

Got it, makes sense. At least in React this has been the long-understood default expected pattern though right? Like, you pass down props from something higher up. Is this a property of state machines or a library like this one? Not trying to be pedantic I promise, I really want to see the value of this, but not sure I can without an example clearly comparing this against just a few if statements or something in pure…

That's true, keeping state and state changes separate from the UI is the default expected pattern in React, particularly with Redux. Or at least it was before hooks, which obfuscated the whole situation in my opinion.

And it's true that this separation of state and UI is just a general design pattern, which can be implemented with a plain object and switch statement, or a small class with a few methods - it doesn't have to be state machines.

So I'm with you in your conclusion, or skepticism perhaps - I prefer to apply the minimal pattern that achieves the same thing, rather than having to learn another state management library like Xstate or even Redux. But then again, I can see the value of such a library in a group/company environment, where you want everyone to learn and follow certain ways of organizing things, where new members can read the documentation, and understand how to add and change existing code in a predictable pattern.

Post reply on HN