Advanced Asynchronous JavaScript

Q&A: Unsubscribe Methods, onError

Advanced Asynchronous JavaScript

Check out a free preview of the full Advanced Asynchronous JavaScript course

The "Q&A: Unsubscribe Methods, onError" Lesson is part of the full, Advanced Asynchronous JavaScript course featured in this preview video. Here's what you'd learn in this lesson:

Jafar answers questions about defining unsubscribe methods and loading the next image when triggering onError.


Transcript from the "Q&A: Unsubscribe Methods, onError" Lesson

>> Jafar Husain: Any other questions we have around this?
>> Speaker 2: I've got a question about the from event stuff. I know you can use from event for hooking into other vendor libraries like Mapbox, for example.
>> Jafar Husain: Mapbox did you say?
>> Speaker 2: Like any library that would implement an event system.

>> Jafar Husain: Anything that uses the add event lister or move event lister pattern, yeah.
>> Speaker 2: So is it, is it dependent on it using that exact function name?
>> Jafar Husain: I'd say, yeah.
>> Speaker 2: And is there anyway to hook custom unsubscribe logic or at that point would you just do your own observer around it.

>> Jafar Husain: In other words what you're saying is, if when you want to unsubscribe you wanna do additional stuff. Then yeah, I would basically, there's a variety of things you can do. But in that case I would basically define my unsubscribe method and then put the extra logic inside of the unsubscription.

So that's one of the rare cases. In general, where you're defining your own subscribe method, it's at the edges of the system where you're adapting existing callback APIs. Into and observable. Those are usually the rare cases where you have to write your own subscribe method. The other more rare case is performance, and that's something worth talking about, right?

I can tell you that this way in which we've implemented preload image. There's a lot of observables actually being created here, if you think about it. We've got an observable for failure, one for success. We have the outer observable defer, then we have the observable created for merge.

There's a lot of layers now, in general, my advice here is do not worry about performance in practice if you're using observable correctly. You're only doing, you know, this work of setting up the observables. In general, events come very infrequently. Like, most events, a must you're doing something like gesture recognition or and our mouse moves or something.

Most events come in very infrequently, and so although this is the lot of work relative to a simple state machine and a bunch of nested call backs, it's still probably not negligible for your program. So as always, my recommendation is do the simplest thing, which is usually an observable flow.

And then profile it and find out if it's slow. And then you can rewrite it by collapsing a whole bunch of these operators, as we just saw, into a single definition of subscribe. Does that make sense? So subscribe can sometimes be useful for performance but be careful before you start doing that for perf reasons.

So make sure you know that's actually where the bottleneck in your program is. Because most of the time it isn't.
>> Jafar Husain: Any other questions you've got there in cyber space? Yeah.
>> Speaker 3: If we on error instead of loading and a URL. Wanted to trigger the next image?
>> Jafar Husain: Totally good idea.

Yeah, good idea what if we wanted to trigger the next image? We'd probably have to reformulate the program a little bit cuz right now it's index based but it's an interesting question actually. I don't have time to tackle that, maybe I do. So let's think about it, in reality we have an observable that it's kind of interesting because it's challenging with an observable, because it's a push system rather than a pull system, right?

With an iterator we would just pull, that failed, I'm gonna go and pull the next one, that failed, etcetera, right? What you could do is you could create a new observable that actually cycles through all the indexes, right, and you could basically take until the first one comes out that's successful.

But that's actually kind of challenging to do, because it would have to cycle through all the indices you'd have to being preloading them, right. Since it's asynchronous. So you wouldn't know until you actually successfully preloaded. So this might be an area where you might want to write a custom operator.

And in a sense it's kind of like a flattened. Right, if you think about it. I've got this stream of data and I've got this two-dimensional stream. And I want to try something. I wanna load something ,right, but in this case I'd have to probably think about the program a little bit differently because the index is only coming in from next and forward buttons.

It's really the user in control of feeding you the next index.
>> Jafar Husain: Yeah, I think we could do it. I'd need to reformulate the program quite a bit.
>> Jafar Husain: Another thing we could talk about would be like, and similar, along the same lines, would be like, well, what happens if we press next and then, cuz I know with the image viewer.

I like to be able to maybe just press next and then just hang back and have it switch every ten seconds or something like that, right? So that'd be an interesting exercise, I'll leave those ones for exercises for the user. But that one might be a little more tractable.

How do you set it up so maybe something like a set interval, right? How do you set it up so that when they hit next, they're really just changing direction? And then every ten seconds you're applying that change to get the indexes, does that make sense?

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now