I've seen Observables only proposed as event sources, but why not support them as data sinks, as well?
element
.observe('keypress')
.map(e => e.keyCode)
.sink(otherElement.innerHTML)
.sink(yetAnotherElement.appendChild)
Using a hypothetical .sink() here as it sounds more digestible for the sake of presentation, but it'd be just an optional alias for .subscribe(), which would work just as well, I guess.
Finally, if the above doesn't taste FRP enough, you might want to consider setting up the whole pipeline starting from the target, backwards, as in a pull model, as follows:
I've seen Observables only proposed as event sources, but why not support them as data sinks, as well?
Using a hypothetical
.sink()
here as it sounds more digestible for the sake of presentation, but it'd be just an optional alias for.subscribe()
, which would work just as well, I guess.also:
Essentially, any value in the DOM that can be set imperatively, could become an observer.
Even entire elements could become observers, by sinking an Object or a Map into them, so that onclick, onmouseover and style can be set in one go:
Similarly, for complex attributes such as style or dataset:
Using higher-order observables each attribute would be set individually when the various inner observables emit:
Finally, if the above doesn't taste FRP enough, you might want to consider setting up the whole pipeline starting from the target, backwards, as in a pull model, as follows:
Could something like this fit into this spec?