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

11–20 of 81 posts

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

#11

Post by sonicrocketman »

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?

The real benefit for our project was being able to statically define, and therefore export the business process the app would follow. Once it's exportable, it's validatable and configurable.

IMO the JSON was hard to read, but we had a plan to build a GUI config builder that exported the state flows.

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

#12

Post by baq »

a4isms wrote: post #4
swyx wrote: post #2

love how xstate makes implicit state machines explicit with a time tested (one might say Lindy) format. badly/ad hoc defined state machines are the source of so many bugs - David has been banging this particular drum the entire time i've known him ( https://www.youtube.com/watch?v=HPoC-k7Rxwo&list=PLRvKvw42Rc... )

“ 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

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

#13

Post by jrvarela56 »

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…

Sounds awesome, given it died could you publish the source? Would be great to see how something like this is structured.

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

#14

Post by davidkpiano »

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.

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

#16

Post by sonicrocketman »

jrvarela56 wrote: post #13
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…

Sounds awesome, given it died could you publish the source? Would be great to see how something like this is structured.

Unfortunately no. It was proprietary.

(we pushed to open source the guts, but to no avail)

Both of us reminisce about it though. We literally retooled the fleet of devices in a weekend to adapt to COVID and it worked. We interfaced with tons of hardware and even ran a customized debian image, all powered by RPis. Truly a nerd's dream project.

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

#17

Post by davnicwil »

andy_ppp wrote: post #10
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?

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?

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

#18

Post by dakom »

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?

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 preventing this at compiletime, it also means the UI can't ever show bogus data (i.e. it's impossible to have a success screen with the error message dangling at the bottom because somebody forgot to clear it)

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

#19

Post by davnicwil »

sonicrocketman wrote: post #11
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?

The real benefit for our project was being able to statically define, and therefore export the business process the app would follow. Once it's exportable, it's validatable and configurable. IMO the JSON was hard to read, but we had a plan to build a GUI config builder that exported the state flows.

Ah yes, I can see this. I've also seen this kind of 'universally understandable spec of behaviour' attempted from the other direction with things like plain-language cucumber test definitions.

Emphasis on attempted, not sure I've ever seen it actually work as envisioned. Can see how bringing this directly into the code could remove some hurdles though.

Must say though I am a little skeptical on the readability / comprehensibility of the JSON format as you point out, but it's certainly a cool idea.

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

#20

Post by fallingmeat »

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