This lesson is for PRO members.

Unlock this lesson NOW!
Already subscribed? sign in

Share Network Requests with RxJS merge

3:34 RxJS lesson by

This lesson teaches how to control whether network requests are cached or are pessimistically re-executed, with the help of the RxJS merge operator.

Get the Code Now
click to level up comment guidelines


This lesson teaches how to control whether network requests are cached or are pessimistically re-executed, with the help of the RxJS merge operator.


.shareReplay(1); - Doesn't work for version Rx5, what could do the save behaviour in version 5?


In RxJS v5 that would be .publishReplay(1).refCount()

In reply to Kostiantyn

We just built this user interface such that when we click refresh it seems to do the following. It does one network request, and then with the JSON response it selects three random users.

But in reality, that's not what happens. Actually, there are three network requests, one for each user. Now, that might sound strange, and if you don't believe me, we can check here.

We can write a console log where we are creating a promise for the network request. We can just put, do network request as message. If we see the console and we rerun this, then we're going to see three network requests.

Now, this might sound strange, but there's a logical explanation to this. If you notice responseStream is used three times, once for each of these suggestion streams. These are being subscribed. So in a way, there are three subscribers to the responseStream. It's an indirect subscription, but things work as a chain.

If you subscribe to suggestion one stream, it will subscribe to the responseStream, which will subscribe to the requestStream and so forth. That's why, in the chain, we are are subscribing to responseStream three times.

Now, observables works like videos, actually. If you have on your phone one YouTube video, then you are doing one network request for that video. And if your friend has his phone and he's watching the same video, he will do also the same network request for that video.

It works in the same way. You can think of a stream as a video and subscribing as watching. So, all the related side effects will happen separately.

The question is, if we want to really have just one network request, how do we do that? Well, just like in real life, you can have one screen with one video and two people watching that. You can also do this with observables. You can say, this will be a shared observable.

Now, this means that there is internally here one subscribe. So, this share it and replay will make it's automatic subscribe. Whoever subscribes later to this responseStream, all kinds of multiple subscribers will share the same inner subscription that this share replay has.

Why replay one? Well, that's because if there happens to be a really late subscriber...let's say someone does a setTimeout and doesn't subscribe to the responseStream after a long while. Let's say, three seconds or even 10 seconds. Then, this subscribe will get a replayed response JSON. It will not do a new network request, but it will simply replay that same JSON that happened before.

That was the share replay. We can be confident that this console log will be shown only once.

Joel's Head
Why are we asking?