If anyone's tempted to visit, the home page is in French. Click on "Chiffrer un produit" and you're into the configurator which has English translation (top right). All the magic is on the third screen, after selecting a category and a product. The disposition of options and choices, plus prices for all choices, plus the 3d rendering, plus all the totals, all recalculate in the browser with zero latency, based on previous choices.
We're off and running, making the world's best configurators for complex products. Our first clients love us. Our configurators implement some very personal ideas about front-end state management, and it's really a thrill to see it all working with real products, 3d rendering and zero latency.
This is worth meditating! The American empire, like the British before it and the other european while we're at it, are flashes in the pan compared to the Romans, the Byzantines, the Ottomans. It could be that hypocrisy, racism and just wanting the oil/diamonds/gold/consumers is not a formula for lasting success.
I like and use MobX. I "come from" Vue, and I like mutability (though I concede its dangers). For my needs, the limitation was reactions. In mobx, reactions shouldn't update other observables. In Octopus, chaining is the whole point. Nodes can be stacked to n depth. There is no distinction between state and computed. Computed just generates more observable state.
Then, in Octopus you also get reporting nodes and visualisation, which, once tasted, no return.
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.
I'm not doing this for fun. Especially since I'm fundamentally lazy (and more of a practitioner than a comp-sci person). I'm looking at custom configurators for complex made-to-measure products with dozens of options, with many interdependencies between options.
I put a concrete example in the sample app. "pizza" depends on "size" and "base". So a DAG, as you point out, is less constraining than a tree. When you shoehorn your state and orchestration into react components, not only do you have to fit them into a tree, it's fundamentally the wrong tree.
No. Signals work with a weak map of references, not a graph. So in my Pizza example, when pizza changes, totalPrice would recalculate twice: once on a signal from pizza, once on a signal from tip. Explicitly constructing the graph dramatically reduces needless recalculation in bigger systems.
Have a look at the node code. It's biblically simple. I would say it's much simpler than any comparable solution. You can forget about reducers, thunks, computed, even useState, useContext, useEffect and props are rare. I've stuck with graph terminology: nodes, predecessors etc, but you don't need to grok that stuff to use this. Once you've understood that a node is a value, some methods and a reup() function, that's it.
The graph framing is essential. I use typescript graph libraries for the topological sort and for the visualization. I did much less work than either of those two libraries !
As I've just written above, React components form a tree that mirrors the DOM. A graph is a much better fit. Nodes in my DAG ressemble "computed" in Vue, where they watch a value and recalculate when it changes, but... in Vue the watched value needs to exist, ie you're responsible for constructing the graph and ensuring no cycles, and the computed value is only available locally, to be used in the template. In my DAG, you just name the thing you want to watch, octopus checks for cycles. Plus you get the visualization.
The closest thing I'm aware of is Jotai. Atoms in jotai can take dependencies on other atoms, so forming a graph.
Reporting nodes in Octopus are, I believe, completely new. You can create nodes that select their predecessors with a filter function. So the "totalPrice" node takes a dependency on any node with a price property, and recalculates when anything with a price changes.
It's very different. Your react components are organized in a tree that mirrors your DOM. If you're using React without an additional state management package, you need to hoist your shared state to a common ancestor, then prop drill it down to where it's needed. Nightmare. I'm advocating a graph that mirrors your subject domain, unconstricted by your DOM. Also, my graph is constructed from below, which feels very intuitive. Nodes specify who they want to read. You make no change to the node being read.