Think Reactive

Asynchronity in depth

We deal with asynchronity every day. User input, timer events, remote data delivery ― they all are asynchronous.

On one hand we have no idea when async action takes place or even if it takes place. On the other hand, contemporary Javascript provides a lot of mechanisms for dealing with it: Promises, async/await, old-good callbacks, etc.

All these approaches are good. However they all have one peculiarity: they think singular. They imply the idea of a “single async action → single response”.

You can object by pressing the button 18 times and getting 18 messages. But you remember that under the hood the same handler was invoked every time. So it’s a cloned singular, not a true plural.

Unobvious issues

Let me provide you with some cases:

• Consider that not every async action deserves the response (filtering).
• Distinguish two separate single clicks from one double-click.
• Consider response to async action should be modified by another async action.
  Remember the gaming experience: W makes your character walk 🚶 but with Shift it makes them run 🏃‍♂️.
• Consider to adjust the speed or frequency of the response (debouncing and throttling).

What’s common do all these scenarios have? ― They are less focused on single async action and its response. They require you to see a bigger picture and treat multiple async actions in one go. That’s the true plurality I was talking about previously.

Reactive approach

The “plural-friendly” async approach is called Reactive programming (Rx). It has been implemented in different languages; I’ll use the RxJS for the demo.

Here is the crush-course of Rx:

• Multiple async events (signals) over the time are considered as a structure called stream or Observable. Think

  --- * -- * ------ * ----- * -- * ---->
  

  This way of visualizing is called a marble diagram.
• It’s possible to subscribe handlers to the Observable: so the handler is invoked every time the async signal takes place.
  It’s possible to unsubscribe handlers too (“switch off”, stop responding to the signal).
• The Observable stream might be modified before subscription. How? Think the way lodash/underscore can treat the list ― RxJS is capable to handle streams in pretty same way and even more (taking into consideration that async signals are spread in time).

There are way more interesting stuff to read like hot and cold streams, BehaviorSubjects which is both Observable and Observer at the same time and many more.

Demo time

The WebAudio API will be used to show the power of RxJS. Whilst browser is playing the audio, we’ll grab the sound data realtime using a “spy” (AnalyserNode). What kind of data? ― The Fast Fourier Transform (FFT). What for? ― we’ll build the sound visualization.

Stay tuned!