bbsimonbb

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.

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.

Good suggestion.

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 looked at and rejected state machines, because I didn't like/understand the need for the formalism of defining every possible state.

That looks really remarkable.

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.

That sounds very cool indeed.

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.

That looks interesting, and totally new to me. Thanks.

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.