Comment by awkii
2 days ago
What the author touches on with before and after "declarative thinking" is largely applicable to all Directed Acyclic Graph (DAG) workflows, and not just signals. They are 100% correct that there is a mental shift. Yes, you can use magic to implicitly declare your DAGs with signals. You can also be really explicit with dependencies.
DAG-based workflows incur a cost in terms of complexity, but there are a few advantages to using DAGs instead of sequential.
1. Parallelism becomes inherently built-in
2. It's easier for a new developer to understand the direct dependencies of a node on other nodes (compared to sequential). Sometime in the future, a developer may want to split off a task or move it up/downstream of other tasks.
3. Fault tolerance & recovery becomes easier. Just because 1 step fails, doesn't mean that the whole workflow must come to a halt.
What makes signals DAG?
User caution or does e.g. this lib prevents cycles?
The Signals libraries I know of (including reaktiv) are throwing an exception if a dependency cycle is detected in the computation step. But that doesn‘t solve infinite executation loops completely because the user still can define an Effect that updates its (in)direct dependencies - that means User caution is still needed. Angular tried to prevent that in their older versions by not allowing to set other Signals in Effects. But they reverted that decision.