In this article, I am going to introduce a new diagram for helping you think reactive and solve Rx problems easier as well as a better way through which we can communicate regarding reactive (e.g. RxJS) problems.

Why do we need a diagram?

While Marble diagrams are very clear in defining a building block of an RxJS pipe (e.g. an operator, etc.), and they can also be used to express the desired output from a list of inputs, they lack the ability to model a complete solution.

Rx is full of operators and static functions with which you can solve your problems. But although RxJS is pretty much magic and enjoyable, solving relatively easy problems can become very complex.

This is the reason I think we need a modeling diagram such as RxDiag to help developers better understand the concept, the whole problem and then easily implement it.

Reactive Programming similarity to Hardware Circuits

Reactive programming is very similar to hardware circuits. How? ok, suppose we write this code in an imperative style program:

sum = a + b

where = usually means assignment. This line of code would add a and b, then assign the result into variable sum.

Ok, What will happen if in the next line we write:

a = a + 1

a will increment and equation sum = a + b will no longer be valid. BUT in reactive programming, if we say sum = a + b we mean that the equation is ALWAYS true.

This property of reactive programming is very similar to hardware circuits. For example a full-adder circuit ALWAYS outputs the sum of its two inputs with a minimal delay. This is the same behavior if we write the following code:

import { combineLatest } from "rxjs";
import { map } from "rxjs/operators";

export function add(a$, b$) {
  return combineLatest([a$, b$]).pipe(map((a, b) => {a + b}));
}

Calling function add with two Observables passed, the return value would be sum of each emitted value of a$ and b$.

const sum$ = add(a$, b$);

Why circuits diagram?

As mentioned above, Rx is very similar to hardware circuits. Hardware circuits, on the other hand, are usually, easily drawn on paper by some boxes as circuit elements and lines as wires.

Just like wiring in circuits we have piping in Rx. So why not name it after circuits?

The Diagram

For solving an Rx (e.g. RxJS) problem, first you should model it. Think of the streams as pipes from which data is coming periodically.
Now think of static functions and operators in RxJS as big boxes where you can input your pipes and take out and output pipe.
Now just put everything on a piece of paper. That's it, you just created an RxDiag!

In this diagram:

• Although coloring is totally optional:

  • blue box shows a static function
  • red box shows operators.

• Single-line arrows show input values which are not streams (numbers, functions, etc.).

• Two lines arrows show Observables.

• Three lines arrows are Higher Order Observables.

• Arrow heads show the direction of flow of data.

That would be all!

Other Samples:

Suppose that in your web page, you have a search input, in which a user types. You have a search(text) method which sends an AJAX request to your server and returns an Observable.
We know that AJAX implementation in RxJS has a very nice characteristic: it will cancel the http request, if you suddenly unsubscribe from the observable and result has not come yet.

Now our very famous problem stands:
When user types we want the search to start. If the user stopes typing she should see the result after they come back from the server. But if the user eventually continues typing and now result has come, the request should be cancelled because its results will not be the latest.

Also, if the user is typing fairly fast, we don't want the search request to start until we are sure the user has stopped typing (for 200 milliseconds).

Here is the RxDiag for that problem:

Happing reacting :)