search

tc39 / proposal-signals

A proposal to add signals to JavaScript.
MIT License
3.37k stars 58 forks source link

inherits EventTarget? #88

Open nuxodin opened 6 months ago

nuxodin commented 6 months ago

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();
})
nuxodin commented 6 months ago

Oh no, unfortunately EventTarget is a Dom-specific extension... :(

milomg commented 6 months ago

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.

littledan commented 6 months ago

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?