[archibaldJ]

I don’t really understand what values such design pattern can bring worth (that will outweigh its own complexities)

my experience working with DAGs programmatically (ie not as an abstraction (like in React) but actually handling the edges&nodes of a graph-based abstraction in code) is that it looks nice theoretically but in practice top-down (conceptual) approach like this often tends to over-complicate things

would love to see some real-world examples where an actual dev team, etc, find values in graph-theortical-based abstractions like this

[bbsimonbb]

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.

[zem]

state machines are a common example of an explicit graph-based abstraction that people build their code around.

[bbsimonbb]

I looked at and rejected state machines, because I didn't like/understand the need for the formalism of defining every possible state.

[davidkpiano]

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".

[archibaldJ]

yeah I heard about lib like XState; just not sure what values it actually provides for a team to decide to use it in a real-world app

[bbsimonbb]

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.