Global `evalContext` as a `Zone` value

[TekExplorer]

the evalContext being a global variable makes sense in some ways, but it feels like its possible fragile or buggy when used with async gaps - surely the context changed by then?

By my understanding, Zone straight up fixes this, as it provides a "scoped global" sort of value that works with async code - seeing as its from dart:async

It especially feels like thats what we'd want since we have effect, computed, etc, which can provide zone values with ease.

Other globals can probably gain similar benefit.

Is there any reason this wouldn't work better?

[rodydavis]

Signals is a sync library and that is why evalContext works. It cannot work across isolates, threads or async gaps.

This matches the upstream preact signals which the library implements 100% of the API.

For a really robust async signals solution you can use rxdart or stream_transform to work with streams and connect them to signals. This is how Angular connect RxJS to signals.

Also the variable evalContext is only for the time of calling .value and will just store the last signal/computed referenced in a signal block scope like in computed/effect. There is nothing stored there as it just adds the node to the graph.

There is a dependencies array for signals in the library that work with asynchronous blocks and that lets you add the signals you want to track regardless of the evalContext.

A zone would be an interesting approach to it! This does need to support pure dart, html, and flutter and JIT/AOT/WASM. I am unsure how well zones work across all the surfaces but have heard of issues with other libraries trying to use zones (like http package).