“Untriggered events” in Reactive Programming

Question

The premise is that you have a Stream - a source of events spread over time.

You can connect to Stream and create a logical chain that will fire when a new event is emitted:

var button = document.querySelector('#button');
var clickStream = Rx.Observable.fromEvent(button, 'click');

clickStream
    .map(...)
    .subscribe(...)

You define a potential change in your system and connect a reaction chain to it.

---

What I am trying to fit within this relatively straightforward paradigm is initial data loading (or any other "untriggered" logical chain) - where you want to load some initial data "upfront", upon creation of the corresponding component, perhaps.

It seems to me that, at least in Rx, the paradigm is to have something similar to:

var source = Rx.Observable.just(somePerhapsAsyncDataSource);    
var subscription = source.subscribe(...);

So, as far as I can tell, it's an "immediately invoked observable" (within event loop constraints, naturally), which feels a bit forced.

Is this the commonly accepted paradigm for "untriggered"/initial loading of data or any other activity?

Other solutions involve abominations like synthetic observables (where you have a shouldLoadData property on some EventEmitter or similar, with the load chain attached, and set it to true when the component is created). Awful.

Answer 1

Disclaimer: I'm an rx/FRP noob, and my answer comes from consuming rx knowledge much more than producing rx solutions. Since this question has considerably less than a flood of responses, then I'll chime in :)

Quick answer: yes, from what I understand, "kickstarting" a sequence by having the initial rx value be the result of a subscription is a pattern, and rx's "cold observables" support this usecase.

Longer ramblings:

I come from a java SE / server background, but I've been working with RxSwift on ios recently. I think I see what you mean by "forced" -- if you'll let me paraphrase, you're thinking "hey I want rx for pure streams and why should a pure stream be sullied by kickstarting a blocking op on initial subscription?"

In my iOS group's production code, I see network programming using Observable<T> to provide .Next(T) responses. More particularly, I see clients which bootstrap the 0th net-blocking call to get their first .Next(T), etc. Although this looks "forced" from the server (observable-emitter's) view, the flipside client-view makes sense to me, abstractly -- as a client, I want T's and I don't/shouldn't care about marshalling the resources to get my first T. As I client, I assume a ladder :)

This "reactive streams in Rx" YT helped me with concepts. Specific to your question:

• https://www.youtube.com/watch?v=g-ixzOcMDF4&t=210 [observable - multiple & async]
• https://www.youtube.com/watch?v=g-ixzOcMDF4&t=294 [cold, for blocking access eg filesystem]

pull quotes:

• "futures are a pretty effective way of handling single responses".
• "you can always handle a single value if you're capable of handling multiple values" (obvious yet true)

As for shouldLoadData hoop-jumping yeah, I just saw some production code yesterday that did this. It sure seems wrong, but hey -- here we are :)

Good luck.