Audience Questions

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Speaker 1: Is the Close button's observable gone to, I'm thinking it's still around if you click Close.
>> Jafar Husain: Good question. What happened to the close observable? Well, let's see where it lives. It lives inside of this closure. So as soon as this closure ends, right, and, well, not technically as soon as closure ends, because we're listening to searchFormCloses, which is all listening to keypresses.

[00:00:34]
It's very difficult sometimes to figure out if something's still in memory but notice that as soon as this closer, runs once, right? We're going to begin listening to keypresses and keypresses is a global event in the browser. If you look up an event to keypresses, it's there unless you come along and remove it.

[00:00:52]
So even though this whole function completes and we've declared closeClicks inside of this function, you might expect that this observable has gone away, but it hasn't. It hasn't because it's chained off of a closure of a closure of a closure of a closure, holding on to keypresses. Excuse me, to, yes, keypresses on the DOM of that, that's still inside of the DOM.

[00:01:20]
So as long as that object is still inside of the DOM, right, you're gonna have that handler exist and it's going to be holding onto indirectly this right here, right. You can just follow the chain down and see that because we're still listening to keypresses, we're still listening to searchFormCloses.

[00:01:37]
Does that make sense? Yeah, another question?
>> Speaker 1: When does searchButtonClicks for each get run so that the do action gets fired?
>> Jafar Husain: It will get run as soon as this whole operation is foreached over. If I delete this, we haven't even hooked up to the Close button or Search button or anything for that matter.

[00:02:04]
>> Jafar Husain: Because all we've done with this whole expression here, can get rid of the extra boilerplate code, with this whole expression, all we've done is create an observable waiting to be called. So I haven't done a thing, I haven't looked up a single event handler. It's all because of forEach and remember we can go through the go around the table and play the forEach onNext game again, right.

[00:02:27]
But that's basically what's happened. We've created an observable but nobody's called forEach yet. So it's just an object with a single function waiting to be called. Crossed my hands over that microphone. Yep?
>> Speaker 1: What would be the best way to test for open observables?
>> Jafar Husain: For observables that have not yet been unsubscribed?

[00:02:46]
Is that the question? Right, so that can be challenging. If you're trying to figure out if an observable hasn't been unsubscribed, it's difficult. You could always go inside of an observable that you own and log the subscriptions and then log the unsubscriptions, right. So you could use do action, for example, right, to log so, you can create an observable that wraps around another observable, and every single time forEach is called they could just forward on the forEach and then log open.

[00:03:13]
And then every single time an onCompleted is called you could log close. You could use do action on the onCompleted to log close. Do action doesn't have a function for, onSubscribe. But you could just create an observable that just forwards the forEach call onto another observable, to do that.

[00:03:28]
Yep.
>> Speaker 1: Could we use, take one, for the searchOnCloseStream to clean up those listeners?
>> Jafar Husain: We could. But that's just gonna end up being a no op. I mean, it's going to end up being a no op because that's what takeUntil does under the hood. Effectively it does, as soon as it gets a single item out of searchFormCloses, it call subscription.dispose on searchFormCloses.

[00:03:52]
So then it stops listing to searchFormCloses. Now, granted, as soon as company calls search again, right. As soon as the search button is clicked again, this function will run all over again. We will create closeClicks, an observable which is based off of the close button click, clicks, and then we'll create this whole sub-expression all over again.

[00:04:12]
And then we'll be listening to that. But in the meantime, between a search and a close click, did I break my example?
>> Jafar Husain: I broke my example.
>> Jafar Husain: In the meantime, we shouldn't be listening to that event all.
>> Jafar Husain: This was working. That should work now.
>> Jafar Husain: Okay, so between the search and the close click, as soon as we hit close we're not listening, and we proved that earlier we're not listening to text box anymore right.

[00:05:07]
We're creating these observables but then we're really throwing them away, as soon as another item comes through the stream. And so in other words, as soon as we click Search again, we're creating a potentially all those DOM elements again. In this case we're just hiding them and showing them, but as you can see, wherever we're hiding and showing we could actually be dynamically creating and putting on screen those elements.

[00:05:25]
So it's safe to do that because we're also making sure to unhook from the text box, from the keypresses event. So we won't just leak event handlers everywhere. So you will see the same pattern again and again in user interfaces. Some action causes a form to open, that may contain one or more asynchronous actions, right.

[00:05:43]
And you all want it to stop as soon as you hit a Close button or that form closes. And so that combination of switchLatest and takeUntil will get you that without ever having to worry about explicitly unsubscribing from events.