What useful function does tap operator bring in RxJs?

What does tap operator actually do? What happenes (should happen) when you execute it on a value? Should it just execute some code? If it should just execute some code, then is it just a wrapper for that code?

For example, for does it do below?

clickStream$.pipe(
   tap((event) => {
       event.stopPropagation();
       event.preventDefault();
   }),
   debounce(300),
   map((event) => event.key)
).subscribe((key) => console.log('key debounced: ', key))

or in this example

export class LoggingInterceptorService implements HttpInterceptor {
  intercept(req: HttpRequest<any>, next: HttpHandler) {
    console.log('Outgoing request:');
    console.log(req.url);
    return next.handle(req).pipe(tap(event => {
      if (event.type === HttpEventType.Response) {
        console.log('Incoming response: ');
        console.log(event.body);
      }
    }));
  }
}

By piping Rxjs operators together we start out with one observable, and end with another observable.

const userBooks$ = getUser(emailAddress).pipe(
                     switchMap(user => getBooksForUser(user.id)); 

1. We start out with a method that returns an Observable<User>
2. We pipe this to switchMap and call another method that returns and Observable<Book[]>

This is the functional reactive nature of Rxjs. You pipe together operators to transform streams.

You can think of these as list comprehension methods like map, reduce, filter, merge ... but for asynchronous streams -- not for arrays or lists.

So if all we can do with pipe an Observalbe<T1> to operators and get Observable<T2> out -- how do we do other things, like call console.log(..) -- or show an error to the user? Or whatever we need to do that interacts with the world outside the chain of Rxjs operators. Anything that touches state, calls something, outside of the operators is a side effect.

const userBooks$ = getUser(emailAddress).pipe(
                     tap(user => console.log('user id: ', user.id),
                     switchMap(user => getBooksForUser(user.id).pipe(
                       tap(books => console.log('books: ', JSON.stringify(books))); 

tap(..) does not change the transformation of the stream -- it is completely non destructive. For this reason it is often used for debugging, as these can be safely added and removed without affecting the chain of operators.

It's about separating side-effects from pure (mathematical to be more precise) computations. Inspired by functional programming, where side-effects are either impossible at all (and thus such a language is completely useless for a lot of real-world scenarios: for example, you can never query a database or write something to console) or allowed only within some explicit conditions (like the famous IO monad in Haskell), rxjs does its best to follow such a way of thinking. Unfortunately, it still lacks razor shape separation line: on the contrary to abovementioned Haskell one might introduce a side-effect outside the tap: let say, one codes something like myObservable.pipe(map(x => { console.log(x); return x * x; }); (you can never translate this code to Haskell bypassing IO type) - there is side-effect mercilessly mixed up with pure computation. JavaScript is a programming language does not enforce purity at all; yet rxjs tries to provide a useful set of primitives allowing you to introduce side-effects apart from pure code: myObservable.pipe(tap(console.log), map(x => x * x)). Now the map is pure with all the benefits of purity and tap is a well-defined area of controlled impurity. Purity indeed not the central idea of framework, but arguably one of them.

P.S. At this point you might think that a "mathematical computation" is something you've learned at school: multiplying some integers or whatever algebra; that's not quite correct. Don't hesitate to take some time and learn the distinction between pure and impure functions and their applications and consequences to get an adequate understanding of the problem.

The tap operator is used to introduce side effects.
You can think of a side effect as something that happens on the side of your main action.

In your example, the clickStream$'s observers are only interested in receiving notifications whenever click events occur. What happens inside the tap operator is a side effect, because, besides emitting click events, you also have other actions like event.stopPropagation() and event.preventDefault().

Another side effect could be logging. Another one would be sending a request to the server when the user submits a form.