Join egghead, unlock knowledge.

Want more egghead?

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

Unlock This Lesson
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Update RxJS to 5.x

    Clear data while loading with RxJS startWith

    André StaltzAndré Staltz
    4 - 5

    Let's fix a small UI glitch that was occurring on startup and whenever the refresh button was clicked. In this lesson we will see how to avoid common bad habits of imperative programming, and how to use reactive programming to keep the complete dynamic behavior of a value specified in one convenient place.



    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




    In our user interface over here our refresh button actually has a small bug, which might annoy some users. When we click refresh, the current list should be immediately cleared away. While it's loading, it should stay empty until new data arrives.

    Actually what happens is that as soon as we click refresh like this it doesn't get cleared immediately, but it stays as the old data until the new data arrives. This also happens when we loaded the page initially.

    Before the first response arrived, there was actually a flash of undesired content, which was this placeholder in each of these suggested users. What we need to do instead is first clear the element on startup to not have any text. Second, we need to clear the element again whenever we press the refresh button.

    I just changed here the render suggestion function such that you can give a null as the suggested user data. If it's null, then it will simply hide the element over here. What you're probably thinking right now is that we just need to call render suggestion "Null" and "Suggestion one." It will clear the first suggested user's element here on startup.

    Then we just need to do this again for the second and the third, and then there we have it. On startup, all of these elements will be cleared. There will be no flash of placeholders, but not so fast. I know this would actually solve the problem, but let's reflect for a moment. Why is this a bad idea?

    The element over here is a dynamic value changing over time. In lesson number three we learned that in reactive programming we should specify the dynamic behavior of this value completely at the time of declaration.

    Where was this declared? Well, if you think of the data that is behind this thing, this was declared here in suggestion one stream. Where was it actually defined? Was inside this create suggestion stream, if you look at this, you cannot see that at startup it is empty.

    You simply don't see that here because that is not specified here at the time of declaration. We need to somehow move this behavior of change. This is somehow specifying a change. We need to move this change into the declaration of suggestion one stream, all right?

    I'm going to do that with a nice operator called "Startwith." You're probably thinking, "OK, what does that do?" It is a pretty simple operator. It does the following. Given a stream of some sort, and let's say that this response stream happens some time later in time. It happens not immediately, but it happens after a while.

    This is mapped to a suggested user as we saw here in maps for a random user. This part near here is this stream that we previously had. What startwith does is basically it just prepends that stream with a value that you specify. It prepends it at the beginning here with a null and then later we have a user.

    That's what startwith does. That's how we can clear the element at startup because this is the first initial moment, and that's our startup moment. That's what startwith null does. What about the other feature? On refresh, we should clear the element.

    Well, same story. The dynamic behavior of this element should be completely specified at the time of the declaration. What is the time of declaration again? It's over here. Again, we're not trying to change this when refresh happens.

    One naïve approach would be to take this refresh click stream, refresh click stream and we subscribe to it. It's an event, and then we simply go and call render suggestion with null for each of those suggestions. Again, this would be something else changing that element, and the dynamic behavior of this element would not be defined here at the time of declaration.

    How can we include this behavior here into the time of declaration of the suggestion stream? We can do something like this. We can merge with the refresh click stream, and we're going to map each of these refresh click stream to null values. Even though there's a refresh event there we're just going to map that to null.

    If I make this code look a bit nicer, yeah. Now we have the startwith there, and we're going to merge that with, let's say, over here happened refresh. That refresh will be mapped to a null. It will look like this. Let's say that this was, also refresh. We're going to map that to a null.

    Then when we merged these two folks, we will see something that looks like this. It starts with a null. Then it gets an actual user data. When you refresh, it got a null again. Now let's say you clicked refresh again, and some time later that data from the response will come here. Let's actually write it like this. We're going to have our user there.

    Now when we click refresh it will immediately clear this list. Then after the loading passes, it will show us new users like that.