You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered: