I've been using this lately and it has proven to be very useful. Here is a very simple and effective way for debugging RxJs 5 code in Angular applications, or in any RxJs application in general.

Probably in the future there will be more advanced tools to debug RxJs. But if you are starting an Angular project now and would like a way to debug what is going on and keep a good understanding of the code, this would help.

This can be used in production without any problem. Its a great defense against memory leaks and other problems that might tend to creep in, as we will see in a second.

The RxJs do operator

Logging is a side-effect and the RxJs operator meant for that is the do operator. This operator could be used to debug RxJs in the following way:

Notice that if we want to add something else to the value we can define a function using the arrow operator, but otherwise if we simply pass the console.log function to the do operator, the values of the observable chain will be logged.

The problem with using the do operator this way

The problem is that there is no way to turn off logging in production. We might want to have the logging on all the time, but it might be too detailed. It would be great to have this information only during development, here is what it would look like.

The RxJs debug operator

Here is an example of some Angular RxJs code that is being debugged:

And here is the console output:

Loading participant from backend Object {id: 1, name: "Alice"}

This is what we are looking for: only one line in the console, with a initial message that explains what is going on followed by the data emitted by the observable (in the same line).

But debug is not part of the Observable API, so how do we implement that ?

A simple implementation of the debug operator

We can add our own operators to RxJs if we need to. And we can make them work with auto-completion, let's see how. First let's implement the debug operator:

So what is going on here ? We are getting a reference to the prototype of Observable and adding it a new method. This means all observables in our application will be able to call this method.

Then we are using the do operator to log to the console the result of new stream values, errors and completion. And its all only logged if the flag debuggerOn is set to true.

Watch the logging utility in action This video shows how to implement this logging utility step by step in an Angular CLI application:

A starting point for more advanced logging

We could take this further and add more functionality to it, make it more configurable. But this simple debugging utility would already help in a lot of situations.

One thing to bear in mind is to avoid calling other observable operators from inside this utility operator. We could start turning cold observables into hot and trigger all sorts of unexpected behaviors.

But this is Typescript, and debug is not part of the RxJs type definitions. So does this mean that we will get a compilation error?

Adding Type Definitions for the Debug Operator

Type definitions are open for extension, so we can add our own type definition for the debug operator. We could put it right bellow the definition of debug:

This code is extending the type definitions of Observable with a new method called debug . With this in place, we would have no compilation errors for debug calls, and we would have auto-completion available for debug :

Great defense against common problems

As our program gets more complex, it might be hard to reason about the multiple observable chains of the application without any logging. Its a good idea to add debug logging from the beginning, and constantly monitor the console output during development.

If something strange comes up, like for example:

a subscription that should have been cleaned up that somehow is still active (this could lead to a memory leak)

multiple subscriptions when only one was expected

All these situations can be detected early and fixed simply by keeping an eye on the log during development, and constantly validating our current understanding of how our program really works.