Join egghead, unlock knowledge.

Want more egghead? It's 45% off for a limited time only!

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock All Content for 45% Off

Already subscribed? Sign In

Save 45% for a limited time.

Get access to all courses and lessons on egghead today.

Autoplay

    Update RxJS to 5.x

    Share Network Requests with RxJS merge

    André StaltzAndré Staltz

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

    rxjsRxJS
    4 - 5
    Code

    Code

    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    Transcript

    Transcript

    00:00 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.

    00:13 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.

    00:28 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.

    00:49 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.

    01:15 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.

    01:30 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.

    01:53 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.

    02:03 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.

    02:23 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.

    02:46 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.

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

    Discuss

    Discuss