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

41–50 of 81 posts

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

#41

Post by capableweb »

davnicwil wrote: post #21
dakom wrote: post #18

Earlier 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 a switch or an if/else expresses this really clearly though and also prevents impossible states.

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.

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

#42

Post by davidkpiano »

fallingmeat wrote: post #20
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.

do you foresee sysml like diagrams in your roadmap? if you could do activity diagrams with swimlanes…dude. that'd be huge.

Yes! Visualizing how different actors communicate with each other in general is a big goal for us this year. We're going to start with sequence diagrams.

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

#43

Post by [deleted] »

andy_ppp wrote: post #32
davnicwil wrote: post #17

Earlier quoted context omitted.

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

[deleted]

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

#44

Post by davidkpiano »

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…

Would love to know more about an example "simple embedding use-case" that you may have in mind.

We're not trying to force state machines as the solution for any state-related problem; they're not a panacea, but instead a useful tool for the appropriate use-cases.

And we're definitely making a huge effort to improve the types.

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

#45

Post by lenkite »

I always found it strange how state machines work so nicely in the small but tend to be difficult to scale up to large-scale, distributed systems.

Orchestrators like Kubernetes discourage designing state machines and transitions inside resource controllers. Instead a list of conditions associated with the object's status define a "phase" (state in k8s term). But there are no formal event-based transitions between states. Depending on the conditions and their tri-boolean values: True/False/Unknown, the object is effectively in a different phase.

Effectively, kubernetes recommends treating Resources like a game ECS - the controller is the system, the resource is the entity and the conditions are the state components.

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

#46

Post by lioeters »

davnicwil wrote: post #17
andy_ppp wrote: post #10

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

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 environment.

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

#47

Post by davnicwil »

simplotek wrote: post #39
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?

> 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.…

I hope you take this in good faith, but one often encounters claims in programming that a particular solution approach is universally better than alternatives for all usecases, often without accompanying concrete usecase examples, and the latter is exactly what I'm trying to dig out.

I am not saying you're wrong, but if you're right this would be the first case I've seen of it in my career so far :-)

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

#48

Post by davnicwil »

lioeters wrote: post #46
davnicwil wrote: post #17

Earlier quoted context omitted.

> Keeping the state changes separate from the UI is a good thing Why? Can you give an example?

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 JS, for something 'everyday'.

State machines make sense to me in a theoretical sense for something with a pretty complex tree of state transitions like a game but for the 99% run of the mill UI work you get in building web products I am not sure I see anything that brings value worth the tradeoff of having to learn yet another library.

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

#49

Post by davnicwil »

capableweb wrote: post #36
joshribakoff wrote: post #30

Earlier quoted context omitted.

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.

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.

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

#50

Post by davnicwil »

capableweb wrote: post #41
davnicwil wrote: post #21

Earlier quoted context omitted.

I think a switch or an if/else expresses this really clearly though and also prevents impossible states.

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?
Post reply on HN