Observer Pattern Q&A

[00:00:00]
>> Is there like a certain amount of times like for this example we only had it in two places but in a bigger applications, they're like actually two, doesn't warrant an observer but like five.
>> For sure I mean yeah, in this example there is no reason to use it.

[00:00:16]
As an observer I think it's totally fine to just use those methods but normally especially with maybe user tracking, user analytics or if there's ever an error. And you just wanna send it to an external service like a logging service, I don't know any analytics service. Which is very common to do that throughout the application like especially when you're working with React or anything else.

[00:00:39]
You have so many different components that, they're not always structured in a very performance way where you can just like import all these analytics functions every time. So, yeah. I mean, of course you can use it at any scale, you can still use it also for just these two functions.

[00:00:56]
But obviously it's way more you get more benefits out of it when it's actually like a larger application. Yeah, so you don't have to worry about it.
>> Could you quickly touch upon the real use case for unsubscribe
>> For unsubscribe, there are many use cases. I mean, maybe you just want to use it one time if something happens or if If it doesn't happen, then you wanna make sure that this subscriber doesn't get invoked more often.

[00:01:25]
Maybe based on external events or if certain time has passed, there's certain timeout or if an error occurred, you want to make sure to unsubscribe it. So like while the program is running, it will never try to call that observer again. Honestly, yeah. I feel like there's not really a specific use case I can think of now because there are so many different types of use cases.

[00:01:48]
Normally I do it like I said based on an error handling if an error gets thrown somewhere else and that is somehow connected to that observer. I want to make sure to unsubscribe it, so I'm not calling it more often. This error can maybe come from like an external API if I've already reached my request limit or if your request limit just to make sure that I'm not getting a huge bill at the end of the month.

[00:02:08]
Because I kept on or at invoking that subscriber, yeah. It's nice that once an observer is subscribed, that you can also unsubscribe it if need be. Yeah, but there are many of these cases. [LAUGH]
>> I got a question too.
>> Yeah.
>> We're, in this case, we're just sending things to analytics, and so maybe we don't care if it fails I'm imagining a situation where I go overboard with observables I think they're really cool.

[00:02:36]
And now I've got my observers crashing, creating problems or I want one to happen and then but if that one happens, I want the second one to happen. For sure is there like a juggling problem you can encounter with observables where it's maybe not a good case to use observables

[00:02:54]
>> Yeah I mean and this is kind of this almost goes back to the decreased performance here. It is good for, if you have many function that you wanna invoke but then there's yet a certain pressure. If it's too many or if they relate to each other, if one has to go first then definitely do not use an observable.

[00:03:11]
Do not subscribe them to the same observable because the observer doesn't care about how it's run. All he cares about is notifying that function, doesn't care how it's done and in what order and of course if you have some for like millions of subscribers. It can take a long time to notify all of them maybe even like results in the server timeout.

[00:03:31]
So you wanna ensure that the observers themselves are not related to each other like the result of one should not are not dependent on each other I should say. The result of one should not affect the other one. Maybe you can lose multiple observables for that but you can definitely go overboard with like having observables everywhere.

[00:03:51]
And then ending up in this weird problem, where does certain data come from, why does it get invoked all that stuff? It can definitely be pretty tricky to understand where stuff happens with observables I find.
>> I think that's why RX JS has lots and lots of operators.

[00:04:07]
>> Yeah, exactly, yeah. If you use RX JS yeah, exactly that they're trying to solve that problem. Personally I don't use RX JS or I haven't used RXJS and react applications but when you go to their, I don't know if RXJS. Just to show you real quick, so they have an overview, so they're all using observables as well.

[00:04:29]
So you have like observers and in here you can actually see they give you a lot more to work with, that you can invoke like the next event you can like middleware. Yeah, so what I showed before it's kind of more like the the pattern behind observables, like this is what you can do.

[00:04:47]
And then luckily, there are many developers that tell you that pattern and simplify it for those exact reasons that you say like okay, this is perfect. But there are so many things that might go wrong, so if you wanna use observables, I would definitely check out RCS or any similar library that may

[00:05:04]
>> We do have multiple courses on arcs
>> Yeah, yeah perfect. Check out their courses on RXJS net in that case.
>> One quick question. So are the subscribers notified in random order or according to on subscribed first?
>> No, so that just depends on how you implement the Notify.

[00:05:26]
So in here, I do the for each, so that does it sequentially. Maybe if I knew that they were Promises, I could do promise.all or something which returns a promise and then runs all those functions in parallel. So that all depends on your own implementation. It depends on the data you expect but, yeah, that doesn't really, yeah like I said it just depends on your own implementation.

[00:05:52]
In this case, it's all in sequence.
>> For this example, so we could have created a wrapper function that call all those functions, like the three though does it the Google, and the custom.
>> Yeah
>> Why would you reach for a wrapper function versus an observable?
>> I feel like they have different use cases with an observable, you can handle a lot of different subscribers, maybe a wrapper function in this case, could have looked something like function.

[00:06:30]
I don't know if this is kind of what you were thinking of, which in turn ,well actually no, I will not live code that's because that would just go wrong anyways, yeah.
>> Like call all three of those functions.
>> Yeah, exactly.
>> Function and call all that function.

[00:06:45]
>> Exactly
>> Instead of the observer
>> Yeah, no of course. Like in this case, that's totally an option. I feel like observers in general, it makes it so much easier like in this case, I could just import the server here. And just notify it and this name isn't super descriptive, maybe I can say analytics observer or something observable, I should say servable, Notify.

[00:07:16]
If we'd had to import that wrapper function, maybe if we need to have way more functions in that wrapper function. We'd like have to update that every time whereas here, we can easily change it. We can unsubscribe subscribers, we can subscribe subscribers at runtime, we cannot easily update a wrapper function at runtime.

[00:07:33]
So that's what I mean, they have different use cases. If you know that a couple of functions will always run the same ones, a wrapper function might be better. An observable is more for like, okay, we don't know who's gonna subscribe to it, we don't know if they might unsubscribe.

[00:07:49]
The observable doesn't care. There's just a nice way to pass data to potential subscribers if they are subscribed, if that clears things up,
>> Yeah, thank you.
>> Cool, yeah.
>> I'm curious in apps. And it might be hard to speak to this but would it be common to have a number of different observables?

[00:08:12]
And how might you delineate between observables? Would it I guess depend on which subscribers you wanted to be attached?
>> Exactly, so of course, kinda like I did here, maybe this is like our analytics observable. So, we know that all the functions that are subscribed here are all dedicated to sending analytics.

[00:08:37]
So, maybe even in the Notify or in the subscribe, maybe we wanna do some extra validation, okay, is this the function that we'd expect, is a type we expect. In the Notify we might also, I don't know, add different at any different logic, I don't know. And then normally, if we maybe wanna have another observable like click observable or something.

[00:08:56]
Like we wanna track a user click events, that'll be another observable just to make sure that we don't have one giant observable that sends events to all the-. If we had a click observable, we don't want them to send events to analytics or if that's not what we expect.

[00:09:10]
Although I guess click is the wrong thing here cuz I'm literally using click, so I guess maybe a scrolling observable. Yeah, so it's just having multiple observables in that case, if you need to use observables for that specific use case. It's definitely the better way to go, just to make sure that you don't unnecessarily invoke your observers, send analytics all that stuff.

[00:09:35]
Cool.
>> A place I use it, is if I have like model like anytime that model updates, it just trigger an event and then-
>> Yeah.
>> Anything my code can listen and subscribe many different places. And that seems to work really well.
>> Yeah, yeah, it's a very powerful pattern.

[00:09:55]
It's very nice, very nice to use.