When a manager gives us the requirements for an application feature, they don't care too much about *how* we build it. And often times, they think that hard things will be easy.

Dealing with time and coordinating different types of events can be tricky.

Luckily, we have RxJS to help!

In this course, you will use RxJS to build a loading spinner in an app that meets the ever-changing requirements from a mock Product Manager.

You'll also learn how to implement a "Konami Code" style feature that listens for a correct sequence of keys to be typed in a set amount of time.

Follow the thought process that Rares uses as he breaks problems down into manageable pieces that remain flexible, and become more comfortable solving problems reactively.

In this course we'll look at how to approach problems reactively - where we program according to what events can happen in our app. We'll put ourselves in a real world situation, where we have an app that can launch some tasks in the background, and a virtual manager, that will constantly expand the scope of our initial requirement. I will start by breaking down the requirements into very small bits, that we can tackle individually. We'll then be very intentional about how we define our observables, naming them correctly and creating the right abstractions that very clear boundaries and are as predictable as possible to the consumers. We'll look at integrating third-party non-RxJS code into our reactive streams and also at exposing our reactive library to the outside world, that might not be RxJS aware. And we'll make sure to learn new operators and look at RxJS mechanics along the way.

Thinking Reactively with RxJS Course Intro

There are certain scenarios that really lend themselves to a reactive solution - and they mainly involve the passage of time and the coordination of multiple asynchronous events. In this lesson we'll look at some examples and introduce our first problem: how do we show a spinner on the screen when there are tasks happening in the background?

Use reactive, RxJS based solutions for complex problems

We will introduce our first requirement: showing a loading spinner immediately when tasks are going on in the background. We will then break this requirement into more and more specific english sentences, which we will later turn into actual observable stream.

Break down a requirement into small problems

In this lesson, we will use the simple data sources we created earlier, to create a more specialized stream that gives us the current count of tasks that are in progress.

Pipe events to numbers and maintain a running count using the scan operator

Because we're thinking in terms of very isolated layers of abstractions, we're also looking to build well abstracted observables that make sense on their own. One way you could figure out if an observable can live on its own is: If I threw my initial requirement away, could this observable still be useful for something else? As part of building well designed abstractions, we need to assume they can be used in any context, and not just in the one we're focused on building at the moment. So we need to make them as predictable as possible to consumers. In this lesson, we'll ensure that the stream we built previously guards against situations where we have more task completions than starts, and also always gives an initial value.

Create safe and predictable observable abstractions

The scan() is very useful in RxJS. It allows you to maintain a running state over time. In this lesson, we'll look at some of the state types scan can hold: transient or single source of truth, and how we can achieve each of them by combining it with the `share` operators.

We'll also look at the differences between `share() / shareReplay(1) / shareReplay({bufferSize: 1, refCount: true})` and how to avoid memory leaks when using them.

Maintain shared observable state using the scan and shareReplay operators

Having access now to an observable that tells us when the in-progress task count changes, we will use it to create two even more specialized streams that will bring us close to solving our initial problem: an event stream that fires when we need to show the spinner and another that fires when we need to hide it. We will be using the pairwise and filter operators.

Use the filter and pairwise operators to determine when to show and hide the spinner

Having built all the event streams we need, we can now assemble them and generate the observable equivalent of our main requirement sentence: “When the loader needs to show, show the loader, until it’s time to hide it”.

Build an observable from a simple english requirement

Before we can test what we built, we need to go back to the empty Subjects that we used as placeholders to define when tasks start and end and actually connect them to our app. In addition, we will learn how to keep our external APIs simple, and avoid making our users understand RxJS.

Expose complex reactive code as simple function based APIs

Two very important features of the Observable primitive is that they can be  activated by subscribing to them and disposed off when we are not interested in them anymore. All good observables need to clean up after themselves when they are disposed off. We took advantage of this when we wrote the observable that switches to showing the loader when the count is positive, and stops listening to it when the count is zero. In this lesson, we will learn how to encapsulate all the complex imperative logic for showing and hiding the spinner, inside a simple observable that can be plugged into any stream.

Encapsulate complex imperative logic in a simple observable

Our app is working! But now our manager comes in and tells us that some tasks in our app are finishing very fast, so users are seeing a short glimpse of the spooner which makes the app look glitchy. Our new requirement is to wait at least 2 seconds before showing the spinner. So without introducing any complexity into our main observable, we will create a new intermediary stream that will be a proxy between the observable that immediately tells us when to show the spinner and the one that actual shows it. This new proxy will delay the events accordingly.

Extend Your Reactive Logic in RxJS using Observable-like Proxies that Delay or Drop Events

Having just congratulated us on the very quick and bug-free turn-around of our previous work item, our manager pings us again to tell us that this time, some tasks finish very shortly after our 2 second threshold. So users are still seeing the glitchy spinner behavior. Our new requirement is that once we start showing the spinner, we need to show it for at least 2 seconds, even if there are no more tasks in the background. To solve this, we will create another proxy, this time for the hiding set of events, and use the combineLatest to wait for two events to happen before we can hide the spinner: we actually get the instruction to hide it (no more tasks in the background) and at least 2 seconds have passed.

Use RxJS combineLatest to Only Emit Notifications When Certain Events Have Happened

Our manager, unaware of how much our functional reactive approach has kept us delivering these features on time and bug-free, decides they want a small new feature added to the spinner before the next release: a percentage indicator, showing how many tasks have finished out of the total started since the spinner was last shown. So in this lesson we will be looking at combining the existing observables that gives the up to date count of tasks, together with a more advanced use of the scan operator, to create a stream that tells us the total count of tasks that have been launched since the spinner was last shown, and how many of them have completed. We’ll also take advantage of scan’s disposal behavior to reset its state when the spinner hides.

Maintain Self-resetting State in Your Observable Streams using the RxJS scan Operator

After another pat on the back from our manager, we get a notification that a new task has been assigned to us: “While most users find it useful, some have asked if they can disable the spinner. Add a feature that turns off the spinner functionality once a certain combination of keys has been pressed within a time period”. So in this lesson, we will look at building an observable factory, that can be initialized with a certain list of key codes, and will fire whenever that key combo gets pressed quickly, within a 5 second window. We will be introducing the fromEvent, concat and takeWhile operators.

Build an Event Combo Observable with RxJS

In this lesson, we'll be looking at an issue with our combo implementation: given that we're switchMapping to a new inner combo each time the user presses the combo initiation key (the letter "a" in our example), if the initiation key is found anywhere in the middle of the combo, it will just cancel out any on-going inner combos.

To fix it, we'll look at the differences between `switchMap` and `exhaustMap` and why `exhaustMap` is a much better choice for our scenario: `switchMap` disposes of any previous inner observables when it gets a new notification from the source, while `exhaustMap` waits for the inner observable to finish, before considering any new notifications from the source.

Use RxJS exhaustMap to Wait for Open Combos to Finish Before Starting New Ones

While we’ve made sure to expose our spinner service using simple, external APIs, most of the time, it will be called in the same way, from observables and promises. In this lesson, we will be creating an RxJS operator that be easily plugged in to different observables to track them via the spinner.

Simplify Usage of Your Reactive Service by Building an RxJS Operator to Manage It For You

We will create a Promise wrapper, that can be used instead of normal promises, to track different tasks that we need to show the spinner for.

Thinking Reactively with RxJS

Instructor

Credits

What you'll learn

Credits

Course Content