[pcthrowaway]

Yeah, I was thinking of xstate too. I think you do a better job than xstate does in describing how a DAG model is a better fit for organizing the frontend state than the current more common spaghetti paradigm. And xstate isn't solely for representing the frontend as a DAG, but my understanding is that it can do that too.

So while I think the description of your solution is better than I've seen in xstate's docs, I'd be inclined to go with the xstate's more mature software that gives me the ability to represent front-end state in a DAG, since it has a thriving ecosystem and (I assume) better tooling.

But I might give Octopus a spin anyway to see what the DX is like

[bbsimonbb]

So xstate implements state machines. This is quite a different concept from DAGs, though there may be a DAG underneath. This isn't mentionned anywhere though. The concepts you work with are state machine concepts.

[pcthrowaway]

Yes but a state machine is reducible to a directed graph, and a DAG is a specialization of a directed graph, which xstate can be used for

edit: to be clear, I think the additional constraints on the directed graph model introduced by Octopus may be useful by requiring developers to derive state transitions from updates which can only occur upstream, because that state can't flow back in the other direction. Whereas the dependencies can have cycles with xstate.

So I'm positing you can do everything with xstate that you can with octopus (and more). I'm not necessarily arguing that the ability to do the "and more" part with xstate is not a footgun, just that xstate lets you work with state in a similar way while also having a mature ecosystem of tooling around it. Perhaps the constraints introduced by octopus would result in more robust software in practice; I'm definitely interested to try it for myself and find out