Transcript from the "Handling Empty Searches" Lesson
>> Jafar: So we're gonna do a little more of these exercises as time goes on to understand Observer. We might even use up the whole table, I'm not sure, so be ready. So there's one more problem with this and then I think we can ship it. What happens if I type, for example, ab, okay.
[00:00:24] Good, we still got it working great. And then I hit back space. Okay, well we do want to issue a network request here, hopefully it's going out there, am not sure what's happened there. Might have been a failed network request
>> Jafar: Question?
>> Speaker 2: What is the advantage of using the distinct until change over using onChange observable?
>> Jafar: On change observable, I don't think I'm familiar.
>> Speaker 2: Distinct until chained with an un-
>> Jafar: I think what's being said is, why not just subscribe to onChange on the text box? Is that correct? I believe onChange on the text box only fires when you tab away from the text box, I could be wrong about that.
[00:01:15] So if you're listening for the onChange event of the text box, you're only going to get that event fire when you tab away from the text box. It's not going to fire every single time you press a key and so it's not very good for auto complete example but good question.
[00:01:28] Right so but if I backspace and delete everything here. I'm not sure if Wikipedia, what might be happening under on the hood is, Wikipedia might not be able to handle an empty search. So, that might be why we're not getting some search results here. But we probably don't wanna send a request for an empty search in the first place, do we?
[00:01:45] Right, probably not that useful to send an autocomplete box request for an empty search. Question?
>> Speaker 2: So, a question about this, the retry, they're saying instantly after the error, there's another retry sent out.
>> Jafar: Instantly after, yes.
>> Speaker 2: So, is there anything that you put on there to throttle that?
[00:02:00] To just weigh that a little bit?
>> Jafar: I'm not sure. If not, I think the key thing to understand here is that observable comes out with a ton of operators. A huge number of operators. What I would highly recommend you at home use, is RX.lite which is a version that's really stripped down to the most common operators that you would use.
[00:02:17] And it's got a relatively small download size once it's G is zipped and modified. But if you don't have an operator that you need, right, you guys now know how to write observables. So it's nothing to it but a for each function that returns a subscription. And so in those cases where there's an operator that you don't want.
[00:02:33] Like for example they might be talking about an exponential back off, so one common practice is with when you have an error, instead of just returning immediately, or trying immediately, excuse me. You might want to wait a certain amount of time, and then if you get another failure, you might want to wait a certain amount of time times two, right.
[00:02:47] So just to avoid hammering the server, and I don't believe RX has an operator out of, I apologize. To the writer of RX, sorry Matthew if I'm, if I'm saying the wrong thing here but I don't believe it has a operator right out of the box. It does an exponential back off.
[00:03:01] But part of the goal here is to be able to teach you, as I've shown you how to write observables right. If there's not operator you don't have you can go ahead and write it, just using the, unfortunately when you're writing observables you have to deal with callback.
[00:03:11] Remember when we wrote the time out observable? Or the from event observable? Right, those methods? In that world you've got to deal with call backs. But the good thing is only inside of there, right? You just have to make sure that all that call back stuff is taken care of inside of there.
[00:03:23] And outside, you get a nice clean observable that takes care of itself and cleans after itself. So if you're missing an operator, you should feel confident, hopefully, to go and write that operator, right? It's nothing wrong with that. It should be easy for us to write an exponential backoff retry operator.
[00:03:38] Won't be much more code than we saw in the from event, as a matter of fact. So maybe we can get to that, I'm not sure. So we probably don't wanna send out an empty search, right? We probably don't wanna send out an empty search. So how can we avoid doing that?
>> Jafar: How do I not send out an empty search, guys? What's the operator I wanna use?
>> Speaker 3: Filter.
>> Jafar: Filter right, it's all there is to it. Let me see if I can filter this operator,
>> Jafar: And I'll use trim is it, is it
>> Jafar: You want larger than zero, because the filter condition is the.
>> Speaker 3: I'm just had an hour trying to find if there have an RX.lite package and ironically the auto complete search function is failing.
>> Jafar: How [LAUGH] on bower?
>> Speaker 3: Yeah, on bower.io.
>> Jafar: So let's run that one more time and just confirm that we we don't get a search sent off for an empty search term.
[00:05:07] To see if we get a search sent out for a, we should and then if I hit back space, no search
>> Speaker 3: Cleared, eh?
>> Jafar: Sorry?
>> Speaker 3: You should clear your results then?
>> Jafar: That's a good point. Yeah that is actually a good point. Yeah maybe maybe filter is not the right operator here.
[00:05:28] Right because we should clear the search results that I did. If we filter it then the old result set is left over very good very good. So maybe right, good point. I'm glad we're displaying the results here so that we can see when a bad decision is being made.
[00:05:46] So if we want to avoid sending out the search results, right. If we wanna avoid sending out an empty string or maybe ignore an empty string, right, there might be a different way we could go about it here. Well I tell you what, why don't we come back to that, because I wanna move forward and cover some other topics.
[00:06:02] But that's auto complete box anyways. And I think what you'll find is that the same pattern keeps coming up again and again. We have an event, we have an asynchronous request and then we'll have some condition under which we wanna stop, right? So, you'll pick the right flatten, excuse me, we have an event in an asynchronous request, and we wanna pick the right flatten for the job.
[00:06:23] Does that make sense? So, as soon as we have the event, we'll map it into an asynchronous request, and we'll end up with a two dimensional observable. Because that's how we make sure that one thing happens after another. We have an event and then we use map to say, only after this event occurs, do I want to run this function which creates an async unobservable which will cause an asynchronous event, asynchronous request to occur.
[00:06:46] And because, for each item in the event stream we're creating another observable, we end up with a two dimensional observable. And then we have to choose the right flattening pattern for it, that makes sense?