Track and show individual subscriptions to input streams

[bman654]

Hi.

This branch adds logic to keep track of the individual subscriptions to the input sequences and render them as marble diagrams beneath the output marble diagram.

Not very exciting for "simple" operations like filter. But can be very useful to understanding more complex operators like amb or takeUntil or pausable, etc.

The display of these subscriptions can be suppressed by setting showSubscriptions property to false on the sandbox component.

I think the model and view changes in this PR will also be useful when adding support for the nested observable operators (groupBy, flatMap, etc).

Here are some examples:

merge (not very exciting)

concat (a little more interesting)

some (helps to show its short-circuiting nature)

pausable (ever wonder what it does on a cold observable?)

amb

repeat (added this one)

[staltz]

👍 Smart refactor

[staltz]

Thank you for all the improvements, there are several of them! I need to take some time to go through all the changes (there are things such as ghost part of the arrow, which I'm not sure I'll adopt since I'm trying to stay close to the original RxJava diagram look-and-feel), rearranging it also from a UX perspective (probably I'll make the subscription details part toggleable behind some switch or button, to keep the default view simple and uncluttered). But in any case, thank you very much for this PR.

[bman654]

thanks for the project. It is pretty cool.

Let me know if you want me to make some of those changes. I'd rather leave the actual UX and UI event handling to you, but I can wire up the rendering to make it easier.

I already added a property to the sandbox to allow you to turn on/off the subscription details so it should be easy to wire up to a toggle.

If you like, I can add a property to the diagram component to control ghosting on a per-diagram basis. Then it could be turned off for all the regular diagrams and only on for the subscription diagrams.

Otherwise, I'm going to work on support for nested observable operators (window, groupBy, flat*, ...). It occurred to me this morning that I can inject a method into the example apply methods which would allow them to capture and render child observable subscriptions the same as the input subscriptions are captured. So you'd be able to write something like:

"flatMap": {
  inputs: [ ... ],
  apply: function (Rx, scheduler, capture) {
    return inputs[0].flatMap(x => capture(Rx.Observable.of(x).delay(10, scheduler)));
  }
}

You'd end up with the output diagram as well as the diagrams for each child observable. Would make it really easy to understand the difference between the different flattening operators.

[staltz]

Let me know if you want me to make some of those changes. I'd rather leave the actual UX and UI event handling to you, but I can wire up the rendering to make it easier.

Sounds like a good plan.

If you like, I can add a property to the diagram component to control ghosting on a per-diagram basis. Then it could be turned off for all the regular diagrams and only on for the subscription diagrams.

That would be good.

Otherwise, I'm going to work on support for nested observable operators (window, groupBy, flat*, ...). It occurred to me this morning that I can inject a method into the example apply methods which would allow them to capture and render child observable subscriptions the same as the input subscriptions are captured.

For flatMap and similar, I want to render a diagram component inside the operator box, like this: http://reactivex.io/documentation/operators/flatmap.html

Rendering the child observable subscription isn't at important as the above.

[bman654]

Do you want that to be somehow data-driven? Or more of a "const pre-defined" diagram specified in the example definition?

[staltz]

It should be visual, and above all, draggable just like other diagrams.

[bman654]

🆒

[seivan]

@staltz @bman654 Hey guys, what happened here? This was a decent update :)

[rickdgray]

Disappointing that this project is abandoned. If the creator doesn't want to maintain it, he should hand off control to someone who will.