omar-azmi / tsignal_ts Goto Github PK

add support for more signals and more types of contexts (or perhapse add support for context plugins).
some of the first ones that come to mind:

singal classes

• async signals: computed variants of these signals should return SignalUpdate.ABORTED in its run method if their promise has not been resolved, which should cascade into aborting all observing signals. as for async state signals, they should hold back their id firing until their set value's promise has been resolved
• deep diffable object signal: an object that signals the difference in its deep entries to its observers. deleted entries should either use undefined or some unique symbol. the diff must be described as a tree graph of non-leaf nodes containing keys, and leaf nodes containing new/updated values

context plugins

• async context: should be capable of handling multiple parallel id firing
• debounce plugin: should debounce when the same id is fired too quickly with not enough delay
• throttle plugin: should throttle when the same id is fired
• debouncedThrottle plugin: should throttle fired id, and behave as a debouncer for the final collection of throttled id firings. this would insure that the very final id firing always goes through

problem:

I just realized that the Context's update cycle mechanism is not actually topologically ordered.
the 3eff039 commit adds the test file /test/simple_signal2.test.ts, in which the traversal of ids is:

• expected traversal: A, B, D, G, C, E, H, F, I, J
• actual traversal by the update cycle: A, B, D, G, C, E, H,I, J, F

as you can see, signal F was supposed to be executed before I and J, but instead, it is pushed to the very end.

the directed acyclic graph looks as the following:

A->[B,C] ; B->[D, F] ; C->[E, F] ; D->[F, G] ; E->[F, H] ; F->[I] ; G->[I] ; H->[I] ; I->[J] ;

---
title: "graph"
---
flowchart LR
	332796(("A")) --> 590207(("B"))
	332796 --> 763885(("C"))
	590207 --> 562158(("D"))
	763885 --> 932932(("E"))
	562158 --> 831043(("G"))
	831043 --> 450102(("I"))
	932932 --> 940461(("H"))
	940461 --> 450102
	590207 --> 270457(("F"))
	562158 --> 270457
	763885 --> 270457
	932932 --> 270457
	450102 --> 770803(("J"))

reason:

F gets skipped in the middle because it is already visited once from either B or D, but its resolution is delayed because of its unvisited dependencies C and E.
however, when C and E are visited, they propagate forward to H and then I.
in I's perspective, F has been resolved, since it has been visited. however, the reality is that while it has been visited, it was awaiting dependency resolution of C and E, and it hasn't been resolved yet.
the forward propagation model is indeed problematic. you should either stick backward resolution or forward propagation, but not both at the same time.

---
title: "the current incorrect traversal mechanism"
---
flowchart LR
	332796(("A")) --> 590207(("B"))
	590207 --> 562158(("D"))
	932932(("E")) --> 940461(("H"))
	940461 --> 450102(("I"))
	562158 --> 270457(("F"))
	270457 -.->|"backward"| 763885(("C"))
	763885 --> 932932
	450102 -.->|"backward"| 831043(("G"))
	450102 --> 770803(("J"))
	270457 -.-o|"get"| 450102
	562158 -.-o|"get"| 831043