proposal-signals
proposal-signals copied to clipboard
tc39
inherits EventTarget?
Would it make sense to inherit Signals from EventTarget?
I handle it like this in my signal implementation: https://github.com/nuxodin/item.js
Among other things, this would make it possible to influence the behavior of the setters and getters.
signal.addEventListener('set', event=>{
event.value = event.value.toUppserCase();
})
We also don't want signals to be used as a pub/sub mechanism
Q: What does it mean for Signals to be "lossy"?
A: This is the flipside of glitch-free execution: Signals represent a cell of data--just the immediate current value (which may change), not a stream of data over time. So, if you write to a state Signal twice in a row, without doing anything else, the first write is "lost" and never seen by any computed Signals or effects. This is understood to be a feature rather than a bug--other constructs (e.g., async iterables, observables) are more appropriate for streams.
The only thing which experiences a sort of event is the Watcher. But I don’t know what the practical benefit would be of making that an EventTarget, rather than just accepting a callback argument. Could you elaborate?
