Reactive Programming: Dealing with Asynchronicity

Ricardo Sanz
Drupal Developer & DevOps
drupal.org/u/tunic
sanzante @ Twitter

Intro.
Approaches to deal with asynchronicity.
Reactive Programming.
Plumbing!
Observables.
Operators.
Code examples.
Final notes.

A way to manage asynchronicity.
Based on the ReactiveX library.
Observer pattern, Iterator pattern and functional programming.
Available in many languages: JavaScript, PHP, Java, Scala, Go, Kotlin, Swift, C#, C++, Pyhton and others.

The browser environment is asynchronous.
Unpredictable events over time.
AJAX.
User interaction (mouse, keyboard, etc).
Timers or animations
WebSockets.
Workers.

An asyncrhonous environment is an environment with events that happen over time that we can't predict. This is very common in the browser because it's an asynchronous environment. If we check a Drupal request we find that the exeuction path is more or less predictible (complex but predictible), and data is available when needed (when a database query is done we asume that result, success or failure, is available in the next line of code, the same for reading a file). In the browser this is not true. We don't know when many operations will return their data: AJAX operations are the main example, but it's the same for workers, user interactions, WebSockets, timers and animations. Allof them are sources of asynchronicity

How we can manage this uncertainty, this asynchronicity?

Simple reaction to an event.

Function call (listeners).

               jQuery('#grip').click(function() {
  jQuery('#panel').slideUp();
});

Coding complex reactions is hard.
Callback hell.

              var doc;
memStorage.get(docId, response => {
doc = memResponse;
  if (!memResponse) {
    localStorage.get(docId, localResponse => {
      doc = localResponse;
      if (!localResponse) {
        serverStorage.get(docId, serverResponse => {
          doc = serverResponse;
          if (!serverResponse) {
            // Error.
          }
      });
    }
  });
});

Objects that wrap asynchronous operations and react when there is a result.
They're chainable.
They greatly improve flow and error management.
Added to ES2015 (ECMAScript 6).

They are resolved only once: they return a single value.
Following the execution flow may not be trivial.
They are not lazy.
They are not cancellable.
Promise hell.

... so if you want to repeat an action you must run again the code that set ups the promise. Usually you can do it calling again the function that manages this, so it's not a big deal.. But you'll need to control this re-execution process.
This works well for one-shot actions (even complex ones) but it could be a problem when it comes to actions that are repeated over time or with sliglhtly different behaviors. Once the promise has been fullfilled no longer returns values. [[[ Get more info about this here: Promises vs Observables, by Mateusz Podlasin ]]].
There many articles explaining that you need to understand Promises quite well to avoid rookie and advanced user mistakes.. [[[ See article by Nolan Lawson, PouchDB core team developer: We have a problem with promises ]]]
As the promise is created the code that tries to solve it is executed as soon as possible. It is assumed that the answer is needed now.
Except using some libraries like Bluebird, once the promise is created it will try to resolve or fail, but it cannot be cancelled (although it can be ignored, of course). This can result in wasted resources.
To be fair, this may happen when Promises are not used the right way.

Although they are a great improvement over callbacks, the following strategy is even more powerful.

Programming with asynchronous data streams.
Use of data pipes that process and alter data.
Declaration of reactions to changes.
Similar example: how Angular, React and Vue.js update user interface on data change.

It greatly simplifies asynchronous working.
Very easy to combine and manage asynchronous data sources.
Generates a shorter, simpler and more intuitive code^*.
Maintainability.

Is about creating data pipes.
Asynchronous data sources are piped.
The pipes transform the data.
The pipes are modulated.
When data reaches the end of the pipe a reaction is triggered.

Example: Click event listener (using callback approach).

              jQuery('#grip').click(function() {
  jQuery('#panel').slideUp();
});

Example: From a click to an AJAX request, and then to a instantiated object list.

Pipes with transformations are the interesting ones. For example, the transition from one click to a list of objects loaded from a service. In this case, at some point the user clicks a button. This click becomes a URL of an endpoint of remote service, for example, a competition's classification data: athletes, score, nationality, name, etc. That URL then becomes the data contained in that URL, which will be a JSON. On the next step the JSON content is turned into instances of a custom class that contains the data received. Lastly, the final action occurs, which is to assign these objects to an internal variable.
So, the initial data, a click, has travelled a pipe that has been transforming that data, until the final action, that's the assignment to a variable. This is nothing new, it's done all the time using callbacks or promises. We could chain the output of one call to another, and deal with the complexity that is produced. The good thing of Reactive Programming is how easy is to define this data management.

Breath pause!

Observables from Observer pattern.
Data streams.
They emit data until they finish or an error is triggered.

They allow to chain streams.
They allow to transform the stream data.
They allow to modulate streams.
They can create streams.
They can combine streams
They output an observable

Filter operator, filters values that don't match the condition.

Map operator, transforms stream data.

            fromEvent(button, 'click')
.pipe(
  map(() => 'https://example.com/api/classification'),
  flatMap(url => http.get(url)),
  map(items => items.map(new MyItem(item)))
)
.subscribe(instances => this.list = instances);

You can express from simple reactions to extremely complex reactions to change.
No more hells.
Observables resolve as many times as needed.
Execution flow is intuitive ^*.
It's lazy.
It's cancellable.

With many ashynchonous data sources.
Complex interactions.
Complex interdependency.
To avoid internal state to manage asynchronous events.

Can be asyncronous or synchronous.
Can be cold o hot.
Can be multicast o unicast.
Can share or not the data source with their subscribers.

Because others have already done it.

It can express very complex models.
It handles any data source.
Observables: proposed for standard, currently in stage 1.
Less code, improved maintanibility.
Available in many languages.
Asynchronicity.

This is the mobile app fo the World Archery Federation, one of our clients.
You see three dropdowns, each is dependant on previous: if you change, the next dropdowns change.
Data is not just retrieved from and endpoint, we need some previous data to render dropdowns (identifiers, labels, etc), so we have dependant data. You could argue that API should be simpler to use and I would agree, but it wasn't the case and we had to stick to already existent API.
Data is refreshed, sometimes very often. While this view is pretty static, the underlaying library that access API is prepared to refresh data automatically and on demand. This would affect the displayed data.
App should work offline, so library builds a local data repository with the fetched data, requesting fresh data when it's outdated.
This resulted in a pretty asynchronous hell. We worked on this with AngularJS without reactive programming: we lost some mental health those days. Then we did it again with Angular using Reactive Programming, and although it was hard because we had to learn how to use it, the asynchronous hell just became a complex but funny problem to solve.

Get the application for Android or iOS.

The introduction to Reactive Programming you've been missing: https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
Interactive marble diagrams: http://rxmarbles.com/
Rx Visualizer: https://rxviz.com/
ReactiveX: http://reactivex.io/

Join us for

contribution opportunities

Friday, December 11, 2020

Mentored
Contribution

First Time
Contributor Workshop

General
Contribution

#DrupalContributions

Locate this session at the DrupalCon Europe website: https://events.drupal.org/europe2020/preliminary-program/