You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In not-so-small apps, it is easy to lose sight of the effects an event can have. In particular, all the signals that are tracking a given signal. I would like to know if there is a way to obtain a "dependency tree" for a given Signal showing all signals that are tracking a given Signal and how its changes are tracked. I was thinking of a tree of dependencies. Then, the order of execution would be given in the order of the tree.
Current solution
One thing I can think of is to attach an effect to every Signal in your app and log a message upon change. Then, changing a Signal would trigger all its listeners to log a message. This retrieves all dependent nodes, but not the order of execution as a tree, just a possible trace.
Use cases
Things I would do with such a dependency tree:
Detect cycles. Note that cycles may not be obvious if there is a control flow in the behaviour.
Debug reactivity. One could look at the effect of one event in a simpler way.
Disable UI. If reacting to a Signal's change takes too long, I would like to disable only the affected UI. This would also signal "we are working on your request" in all the relevant parts of the UI for the particular firing event.
The text was updated successfully, but these errors were encountered:
Feature request
In not-so-small apps, it is easy to lose sight of the effects an event can have. In particular, all the signals that are tracking a given signal. I would like to know if there is a way to obtain a "dependency tree" for a given
Signal
showing all signals that are tracking a givenSignal
and how its changes are tracked. I was thinking of a tree of dependencies. Then, the order of execution would be given in the order of the tree.Current solution
One thing I can think of is to attach an effect to every
Signal
in your app and log a message upon change. Then, changing aSignal
would trigger all its listeners to log a message. This retrieves all dependent nodes, but not the order of execution as a tree, just a possible trace.Use cases
Things I would do with such a dependency tree:
Signal
's change takes too long, I would like to disable only the affected UI. This would also signal "we are working on your request" in all the relevant parts of the UI for the particular firing event.The text was updated successfully, but these errors were encountered: