All those years of responsive programming we missed

There are a lot of bad explanations and definitions on the web. Wikipedia is often very general and theoretical, Stackoverflow is often very prescriptively written, and Reactive Manifesto looks like something for your PM or boss. Microsoft’s Rx terminology, “Rx = Observables + LINQ + Schedulers”, is also too heavy and full of Microsoft-like things to confuse us even more. Terms like “Reactive” and “Propagation of change” do not convey any meaningful concepts relative to the MV* framework you use and your preferred programming language. Of course, my View framework reacts from the Model, and my changes propagate of course, without which my interface would have nothing to render at all.

So, no more of this crap.

A data flow is a chronological sequence of Ongoing events ordered in time. As shown above, it can emit three different events (already called events in the previous sentence) : a value event of some type, an error event, and a completion event. When a completion event occurs, in some cases we might do something like close the window or view component that contains the button.

We can only capture emitted events asynchronously, allowing us to execute one function on a value event, one function on an error event, and another function on a completion event. Sometimes you can ignore the latter two events and just focus on how to define and design the function to execute when the value event is emitted. The process of listening to this stream of events is called a subscription, the function we define is called an observer, and the stream of events can be called the observed topic (or observed). You should be aware of that, right, it’s the observer model.

The diagram above can also be redrawn in ASCII format, please note that we will continue to use it for the rest of the tutorial:

- a - b - c - d - X | - > a, b, c, d is the value of X is the error events | is complete event - > time line (shaft)Copy the code

Now that you’re familiar with reactive programming event streams, let’s not bore you with something new: We’ll create a new click event stream that evolved from the original click event stream.

First, let’s create an event flow that records the number of button clicks. In common reactive libraries, each event stream is accompanied by functions such as map, filter, scan, etc. When you call one of these methods, such as clickstream.map (f), it returns a new event stream based on the click event stream. It does not make any changes to the original click event stream. This property is called immutability, and it can be used with a responsive stream of events, like soymilk and churro. This can be done as a chained function, such as clickstream.map (f).scan(g):

  clickStream: ---c----c--c----c------c-->
               vvvvv map(c becomes 1) vvvv
               ---1----1--1----1------1-->
               vvvvvvvvv scan(+) vvvvvvvvv
counterStream: ---1----2--3----4------5-->
Copy the code

The map(f) function maps each return value from the original event stream to the new event stream based on the f function you provided. In the case above, we map each click event to the number 1, and scan(g) aggregates the previously mapped values and processes them according to the X = g(Current) algorithm, which in this case is a simple addition function. Then, when a click event occurs, the counterStream function reports the current total number of click events.

In order to show the true beauty of reactive programming, we assume that you have a “double click” event flow, in order to make it more interesting, we assume that the flow of events and deal with “three clicks” or “click the” event, and then take a deep breath to think about how to use the traditional status and imperative to handle way, and I’m willing to bet, doing so would rather nasty, There are variables involved to hold the state, and there are time interval adjustments.

Reactive programming is very succinct; in fact, the logical part only needs four lines of code. However, let’s ignore the code for now. Whether you’re a novice or an expert, looking at diagrams and thinking about them is a great way to understand and establish the flow of events.

In the figure, the gray box represents the functional process of replacing the above event stream with the following event stream. First, according to the event silence interval of 250 ms. The event-free period, the interval between the occurrence of the previous event and the occurrence of the next event) separates the click event stream segment by segment, and adds one or more click events from each segment to the list (this is the function: Buffer (stream.throttle(250ms)) does something, so let’s not get into the details right now, let’s just focus on the responsive part). Now we have multiple lists containing event streams, and we use the function in map() to calculate the integer value of each list length to map to the next event stream. Finally, we use the filter(x >= 2) function to ignore integers less than 1. So, in three steps we generate the desired event stream, and then we can subscribe (” listen “) to the event and do what we want.

I hope you get a sense of the elegance of this example. Of course, this example is just the tip of the iceberg of the magic of reactive programming, and you can also apply these three steps to different kinds of event flows, such as a stream of events in response to an API. On the other hand, there are so many functions you can use.

Let’s dive into some real examples, one that teaches you step by step how to think in a responsive programming way, no fictional examples, no half-baked concepts. By the end of this tutorial we will have generated some actual function code and be able to see why each step did what it did.

I have chosen JavaScript and RxJS as the programming languages for this tutorial for the following reasons: JavaScript is the language most people are familiar with, and Rx series libraries are widely used in many languages and platforms. Examples are.net, Java, Scala, Clojure, JavaScript, Ruby, Python, C++, Objective-C/Cocoa, Groovy, etc. So, no matter what language, library, or tool you’re using, you can learn (and benefit from) from this tutorial.

We will focus on imitating its main functions, which are:

• To start, load the recommended user account data from the API, and then display the three recommended users
• Click Refresh to load the other three recommended users to display in the current three lines
• Click the ‘X’ button on each row of recommended users to clear the current clicked user and display a new user to the current row
• Each line shows a user’s picture and, when clicked, links to their home page.

We can ignore the other functions and buttons because they are secondary. Since Twitter recently shut down unauthorized public API calls, we’ll use Github’s API to get users instead and build our UI from there.

If you want to see the final result first, here’s the finished code.

Yes.

Promise++ is an Observable, and in Rx you can do something like this: Var stream = Rx. Observables. FromPromise (promise), promise can easily be converted to an observer (observables), was a very simple operation can let’s start using it now. The difference is that none of these being watched are compatible with Promises/A+, but in theory they are not in conflict. A Promise is a simple observed object with a single return value, and Rx goes a step further by allowing multiple returns.

It’s better that way, it’s more prominent that the observed is at least more powerful than Promise, so if you believe what Promise promises, keep an eye out for what responsive programming can do.

Now going back to the example, you should quickly notice that we are calling the subscribe() method again inside the subscribe() method, which is sort of like callback hell, The responseStream creation also depends on the requestStream. As mentioned earlier, there are many simple mechanisms in Rx to transform other event streams and create new ones, so we should try this too.

One of the most basic functions you need to know now is map(f), which takes each value from event stream A, performs the f() function on each value, and then populates the resulting new value into event stream B. If we apply this to our request and response event flow, we can map the request URL to a response Promises (disguised as a data flow).

var responseMetastream = requestStream
  .map(function(requestUrl) {
    return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));
  });

Then we created a monster called “Metastream” : an event stream loaded with an event stream. Don’t panic, metastream is the value of each issue is another event stream flow of events, and think you see it as a pointer (Pointers)] ((en.wikipedia.org/wiki/Pointe…

A responsive Metastream does look confusing and doesn’t seem to be helping us at all. We just want a simple response data stream, where each emitted value is a simple JSON object, not a ‘Promise’ JSON object. Ok, let’s take a look at another function: Flatmap, which is another version of the map() function and is flatter than Metastream. All events emitted in the “main trunk” event stream will be emitted in the “branch” event stream. Flatmap is not a fix for Metastreams, and MetaStreams is not a bug. Both are great tools for handling asynchronous response events in Rx.

var responseStream = requestStream
  .flatMap(function(requestUrl) {
    return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));
  });

It’s nice because our response event flow is defined according to the request event flow, and if we have more events in the request event flow in the future, we will also receive response events in the corresponding response event flow, as expected:

RequestStream: - a - b - c -- -- -- -- -- - -- -- -- -- -- - | - > responseStream: -- -- -- -- -- -- -- -- -- -- -- -- -- b -- -- -- -- -- -- - | c - > (lowercase is request event flow, capital flow) is a response to an eventCopy the code

Now we finally have a stream of events that respond and can render with the data we receive:

responseStream.subscribe(function(response) {
  // render `response` to the DOM however you wish
});

Let’s put all the code together and see:

var requestStream = Rx.Observable.just('https://api.github.com/users');

var responseStream = requestStream
  .flatMap(function(requestUrl) {
    return Rx.Observable.fromPromise(jQuery.getJSON(requestUrl));
  });

responseStream.subscribe(function(response) {
  // render `response` to the DOM however you wish
});

Until now, we have only touched on the UI recommended for attention in the rendering steps that occur in response to the subscribe() function of the event stream. Now that we have the refresh button, we have a problem: When you click the refresh button, the current three recommendations focus on the user is not clear, and as long as the response data reach after we got the new recommendations focus on user data, in order to make the UI look more beautiful, we need to click the refresh button when the incident clearly the current three recommendations focus on the user.

refreshClickStream.subscribe(function() {
  // clear the 3 suggestion DOM elements 
});

No, man, not so fast. We have a new problem because we now have two subscribers influencing the UI DOM element that we recommend attention to (the other is responsestream.subscribe ()), which does not seem to comply with the Separation of concerns, Remember the principle of reactive programming?

Now, let’s model the user data for recommendation concerns into a stream of events, where each emitted value is a JSON object containing the user data for recommendation concerns. We will treat these three user data separately. The following is the event flow of user no. 1 data that we recommend to pay attention to:

var suggestion1Stream = responseStream
  .map(function(listUsers) {
    // get one random user from the list
    return listUsers[Math.floor(Math.random()*listUsers.length)];
  });

Others, like suggestion2Stream, which are recommended, and suggestion3Stream, which are recommended, can be easily copied and pasted from suggestion1Stream. This isn’t duplicate code, just to keep our example simple, and I think it’s a good example to think about how to avoid duplicate code.

Instead of having the rendering happen in responseStream’s subscribe(), we do that here:

suggestion1Stream.subscribe(function(suggestion) {
  // render the 1st suggestion to the DOM
});

We’re not handling the render in the subscribe() responseStream, we’re handling it like this:

suggestion1Stream.subscribe(function(suggestion) {
  // render the 1st suggestion to the DOM
});

Going back to “clear out current recommendation followers when refreshing,” we could easily map the refresh hits to no NULL suggestion data, and including that in suggestion1Stream, as follows:

var suggestion1Stream = responseStream .map(function(listUsers) { // get one random user from the list return listUsers[Math.floor(Math.random()*listUsers.length)]; }) .merge( refreshClickStream.map(function(){ return null; }));

When rendering, we interpret null as “no data” and hide the UI elements.

suggestion1Stream.subscribe(function(suggestion) { if (suggestion === null) { // hide the first suggestion DOM element }  else { // show the first suggestion DOM element // and render the data } });

Now we have the following schematic diagram:

refreshClickStream: ----------o--------o---->
     requestStream: -r--------r--------r---->
    responseStream: ----R---------R------R-->   
 suggestion1Stream: ----s-----N---s----N-s-->
 suggestion2Stream: ----q-----N---q----N-q-->
 suggestion3Stream: ----t-----N---t----N-t-->
Copy the code

N is null

As a supplement, we can render the empty recommendation at the beginning. This is done by adding startWith(null) to the recommended event stream:

var suggestion1Stream = responseStream
  .map(function(listUsers) {
    // get one random user from the list
    return listUsers[Math.floor(Math.random()*listUsers.length)];
  })
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);

The result is this:

refreshClickStream: ----------o---------o---->
     requestStream: -r--------r---------r---->
    responseStream: ----R----------R------R-->   
 suggestion1Stream: -N--s-----N----s----N-s-->
 suggestion2Stream: -N--q-----N----q----N-q-->
 suggestion3Stream: -N--t-----N----t----N-t-->
Copy the code

We are done, and here is the complete sample code wrapped:

var refreshButton = document.querySelector('.refresh');
var refreshClickStream = Rx.Observable.fromEvent(refreshButton, 'click');

var closeButton1 = document.querySelector('.close1');
var close1ClickStream = Rx.Observable.fromEvent(closeButton1, 'click');
// and the same logic for close2 and close3

var requestStream = refreshClickStream.startWith('startup click')
  .map(function() {
    var randomOffset = Math.floor(Math.random()*500);
    return 'https://api.github.com/users?since=' + randomOffset;
  });

var responseStream = requestStream
  .flatMap(function (requestUrl) {
    return Rx.Observable.fromPromise($.ajax({url: requestUrl}));
  });

var suggestion1Stream = close1ClickStream.startWith('startup click')
  .combineLatest(responseStream,             
    function(click, listUsers) {
      return listUsers[Math.floor(Math.random()*listUsers.length)];
    }
  )
  .merge(
    refreshClickStream.map(function(){ return null; })
  )
  .startWith(null);
// and the same logic for suggestion2Stream and suggestion3Stream

suggestion1Stream.subscribe(function(suggestion) {
  if (suggestion === null) {
    // hide the first suggestion DOM element
  }
  else {
    // show the first suggestion DOM element
    // and render the data
  }
});

You can be inhereSee a demonstrable example project

The above snippet is small but does a lot: it uses the separation of concerns principle in place to manage multiple streams of events and even cache response data. This functional style makes the code look more like declarative programming than imperative: we’re not giving a set of instructions to execute, we’re just defining the flow of events to tell it what it is. For example, we used Rx to tell the computer that suggestion1Stream is a data stream combining the ‘close 1’ event with a user’s data from the latest response data, and null when the refresh event occurs and the program starts.

Notice the absence of flow-control statements such as if, for, while, or callback-based flow-control as is typical in JavaScript. If you can (I’ll leave you some implementation details as an exercise later), you can even use the filter() function on subscribe() to get rid of if and else. In Rx, we have data flow functions such as MAP, Filter, Scan, Merge, combineLatest, startWith, and many other functions that can be used to control the flow of event-driven programs. The collection of these functions allows you to achieve more power with less code.