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

71–80 of 81 posts

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

#71

Post by capableweb »

ar-nelson wrote: post #63
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)

If it (probably) already works as-is, why not just use it? Why is it nicer with a "dedicated module" if using it from npm is the same? More work is more work, reducing maintainer work is something we should strive towards, rather than adding "just a little bit of work".

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

#72

Post by nickpeterson »

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.

I know this probably isn’t on the radar, but process trees or pétri nets with token visualization feels doable, any interest in supporting those kinds of tools?

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

#73

Post by dabernathy89 »

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…

Ran into the same trouble re: TypeScript. Wanted to break up my definition into smaller chunks but it really did not like that.

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

#74

Post by dabernathy89 »

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'm using it to control which fields in a form are visible based on values of other fields.

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

#77

Post by Emanation »

Add a description please. I get it's a state machine. I get states have state-tags, transitions can be ran via these transition-tags. What is your philosophy behind this library. Why should I give a fuck that states and transitions are strings rather than enums?

All I see here is a switch statement, the input is an enum, and the action that's taken is also determined by an enum.

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

#78

Post by Tade0 »

We're using Xstate for state management instead of Redux and the like and it fits well for this purpose - chiefly I have an idiomatic way of defining which inputs are appropriate in different contexts.

The visualizer is a major selling point - especially if I need to explain something to non-dev people or someone new to the concept.

The one downside is that building state machines is an art in and of itself and I had to throw away my first implementation in favour of something simpler once I got the hang of it.

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

#79

Post by b0afc375b5 »

I wanted to learn about state machines so I searched for reading material here in hackernews. Found out about statecharts and used it immediately to rewrite a frontend app. What a fantastic development experience. It feels like I finally graduated from spaghetti coding to disciplined programming.

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

#80

Post by sonicrocketman »

yagodragon wrote: post #37
sonicrocketman wrote: post #9

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

Direct from the mouth of the other half of the team:

We used Xstate over react-router by using a parallel machine:

- One for application state - One for view state

We had to hack the innards of the events a bit to get the two machines to communicate. This allowed the view to re-render the jsonschema form at the exact right time, and not flicker on multiple state transitions.

In hindsight, graphql wasn’t as necessary as we initially thought. The important part was storing the mutation as a string as an xstate transition parameter. We used federation, so it did help us deal with multiple backends.

All database. Versions were handled by having a core machine that pulled the kiosk’s workflow from the server and ran it as a submachine. So the code on the device (core machine) could switch sub machine workflows on the fly between runs.

Post reply on HN