At the heart of RxJS are a few new primitives: Observable, Observer, Subject and Schedulers. This library has “batteries included”, meaning it comes with a wide range of useful operators that we can compose together to create declarative, high-performance data pipelines. We will learn several ways to create and subscribe to observers.

In this exercise, we will create and subscribe to Observers in a variety of different situations. Through these exercises, we will explore the flexibility of RxJS and its capability to integrate easily with events, iterables, and Promises.

We can “stop” receiving information from an Observer, either through an explicit cancellation or through using operators like take() to implicitly limit how much data we receive. We will look at the differences between these two approaches, and valid use cases for each.

Work through two examples involving cancellation of an observer: one where we know we only want a fixed number of values, and one where we need the ability to arbitrarily cancel at a set time.

Break for lunch

Handling errors from Observables is both well-aligned with what we expect from Promises, and a bit more flexible. In particular, we will look at two useful Observable error-handling techniques that do not make sense in the context of Promises: retrying sequences and ignoring errors until the next successful response.

We have an API endpoint for reading the current outdoor temperature, that can fail in a variety of ways (e.g. no internet connection, 500 server error, returning data in an unexpected format etc). Apply Observable error handling best practices to finish our thermometer app, optimizing for correctness and robustness.

Operators are kind of like “arrays that push”, so it is no surprise that one of the easiest ways to work with them is through using higher order functions like map, filter and reduce. We will look at how these “lettable” operators can be composed to create a pipeline, ultimately allowing us to subscribe to a stream of values that have already been massaged, cleaned and processed.

Build a “Simon” game, making heavy use of Observables to handle events, keep score, and to ensure that the user presses the correct (matching) sequence of buttons.

Aggregate operators allow us to iteratively build up a single value over an Observable’s sequence. We will explore the subset of these operators that come with RxJS, and highlight practical applications for each operator.

Build a textarea that keeps track of various text statistics as the user types. All stats should be updated in “soft real time” as the user types.

Subjects are objects that implement both the Observer and Observable interfaces. Rx comes with three types of Subjects: BehaviorSubject, AsyncSubject and ReplaySubject. We will explore each Subject’s characteristics and highlight practical use cases.

Finish implementing a chat application, making use of BehaviorSubject, AsyncSubject and ReplaySubject in the recommended ways.

As we prepare to work with the idea of combining Observers, the passing of time is a factor we must examine closely. We will look at how the debounce and throttle operators can be used to clean up a “noisy” observable; how we can use an observable as a buffer for incoming data; and how we can apply Schedulers to control how elements of an observable are treated within the JavaScript runtime.

Sign up for a themoviedb.org account and generate an API key. Build a movie search autocomplete, using debouncing and throttling best practices to avoid abusing the API and exceeding the API rate limit.

Despite what Ghostbusters advises us, we often need to combine Observables in various ways, so that we can subscribe to a single stream that emits a single sequence of values. There are many different pipeline operators that fit this description, and they produce a variety of different sequences. We will study our available options, using marble diagrams as visual aids, and begin to develop an intuition for selecting the right tool for the job.

We have the raw ingredients for a “Pong” game, but have no events, no motion on our ball, and no collision detection. Use Observables and the concept of combining streams to finish this game, taking care to minimize the number of un-necessary animation updates.

We use the terms “hot” and “cold” to describe what a “late subscriber” will receive from an Observable. If a “late subscriber” starts listening to a “hot” Observable that’s already emitted some values, they will only get new items in the sequence. By contrast, “cold” observables start at the beginning of their sequence for each new subscriber. There are great use cases for both of these patterns, which we will explore in detail.

Create two functions: one that creates a “cold” observable from a “hot” one, and one that creates a “hot” observable from a cold one.

The testing story for Rx observables and operators has come a long way over the past several years. We can use “marble diagrams” (the ASCII art equivalent) to declaratively assert that observables emit the expected sequence. We will look at how this is done, and how we can structure our Rx code to make testing easy.

You will be provided with a variety of functions that return observables. Write a series of marble diagram tests for these functions, and fix any bugs you may discover along the way.