Hacker News new | ask | show | jobs
by hobofan 918 days ago
Almost every modern framework is implicitly modeled as a DAG? It just rarely used that nomenclature. Heck with Elm a whole language exists for that principle.

I'm really not sure what's supposed to be different here. As is evident from the repository you obviously know about React and Vue, so maybe try to contrast it to them, or how it fits in in relation to them? To me it looks like you are building a system-in-a-system, where you are rebuilding the primitives that already come with React (or any of its peers).

1 comments

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.

> React components form a tree that mirrors the DOM. A graph is a much better fit.

Not all acyclic graphs are trees, but all trees are acyclic graphs. As such this part of your description is confusing.

Your last paragraph does a much better job at explaining how it differs.

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.
I'd suggest you emphasize that near the top of your README, maybe with a cleaned-up version of the generated graph and some annotation of the data flow. To put it a bit pointedly, "nobody" will care about the data structure until they see that it means they don't have to manually thread data down through the right branches of a tree. That's your big selling point.
Good suggestion.