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.
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.
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.
You don't need to define every possible state. A state machine can serve as a higher-level structure of some of the states (statuses, modes) of parts of your app, for ease of structuring logic. But you can also create a single-state state machine and represent non-finite data as "external state".
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.
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.
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
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.
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
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.