Wrapping Up

[00:00:00]
>> Questions comments concerns cries of outrage.
>> How often do you use subjects in your day to day work?
>> Shockingly, it's, so this is, there's a question, was, how often do we use subjects? So subjects are very similar to like event emitters, right, you can have a subscription, and you can have multiple things that subscribe to it.

[00:00:21]
Now, theoretically, I'm technically using a subject right here, right? The share, like I'm effectively turning a cold observable into a subject, so there's two ways to answer this question. One is as somebody who builds an app in spelt all the time, spell sores are effectively subjects, right? And because Feldt handles reactive things out of the box, commonly they use them instead of like a Redux data store or something along those lines.

[00:00:48]
In the actual like, I'm coordinating some events, not as often, so a subject just to be clear is both a subscription and an observable. You can both say call dot next all the things we did originally in the very beginning. You can call.next.subscribe, obviously.next.complete.error, so on and so forth, and then things can also subscribe to it.

[00:01:13]
So there's one object that is both observable and an observer at the same time, right? And so those are useful if you have pieces of your application that maybe wanna listen to one core data store. So my application on a day to day basis, those are spelt stores.

[00:01:29]
When I did react I didn't use them at all, because Redux was my store in that case, right. Effectively the reducer was the shared thing that everything talked to and I was just dealing. And action would come in we do awesome the dance you see right here, of like figuring out when things should happen.

[00:01:46]
And I was subscribed to the store itself, so it's useful as a data store that you wanna know when it changes, right. But in terms of like a lot of the flow and coordination, this is theoretically one right here. And so pieces like that, they come up when I need to share data in two places at once, cuz again, I didn't wanna fire two data requests.

[00:02:08]
As often as like you see them immediately in the beginning of the. No, I don't, right, that's it, I think in angular, you can use them a little bit more as a store. And kind of for that same purpose that I use spelt cells, those are not subjects.

[00:02:24]
They're just subject like, I think in angular, you might end up using them a little bit more as well. Behaviour subjects are the ones that give you the last value or think of replace object. We'll play through all the values and set forgotten, and A sync subject only gives you a value when it completes, doing that for memory.

[00:02:40]
I've never used an A sync subject, I don't know why I would use an A sync subject. But yeah, behavior subject is very much like this effectively, not only is this a subject this is effectively a behavior subject, right? If you're a new subscriber, here's the last thing that I said, right?

[00:02:55]
If this shared replay, had a huge number it could be all the things that have happened, right? And so it's a way to kind of catch up with previous things as well
>> I've also had to swap an angular event emitter for a behavior subject, I don't remember why, I thought that was really interesting.

[00:03:13]
>> And Angular, if you want to use a certain type of change detection, you have to use observables.
>> Yeah.
>> So use behavior subjects or subjects.
>> But that there really good syntax.
>> [LAUGH].
>> They have like that A sync syntax.
>> Yeah [INAUDIBLE].
>> Do you have any advice for using RXJS outside of angular, for other frameworks

[00:03:33]
>> I mean I've only exclusively use it outside, so yes. So I think commonly the place that I've used it before, is in a react application and so in that case, you have redux-observable. And redux-observable is effectively middleware for redux, where you set up these things called epics, which sounds really cool.

[00:03:57]
But an epic is just a piece of middleware that every single action flows through. So you can have multiple epics that you can combine, but every single action, flows through every single epic. And what you do effectively, you could filter or there has there's a type for the type of action but effectively a filter.

[00:04:15]
And so when every single action flows through, then you find yourself where you can like deal with that. And you could also merge map it to other actions, right? And okay, I wanna, they said, hey, I'm looking for the API data, cool. Fire the reloading the API data action was then react can deal with or whatever.

[00:04:38]
And then when that comes back, then I want to fire an action for we're downloading, here's the data, take everything down, right? And so, for the application, we trying to send grid the marketing campaign editor. We basically use that for, every single action flew through that because send grid at the time still today used its public API's for all of its client side applications, right?

[00:05:02]
But those public APIs weren't necessarily built for building UIs, right?. So a lot of times we would have to kind of do a lot of orchestration and dancing with those APIs. Like cool, I actually need to hit these three API's, way to they all come back or some subset of that, progressive data loading.

[00:05:18]
And put it all in place Redux observables were weally great. But also, if you think about it, like if you're familiar with react, I think I mentioned a few times during this course. You can like, you can make a use observable hook pretty easily, right? Like pass it an observable that uses use effect, subscribe to it every time it emits.

[00:05:39]
Like have some use state that you trigger a use reducer, right. For whatever you want and then unsubscribe to it, right, so you can use them basically anyway. And that's why we focus this course on just using it in vanilla JavaScript. To kind of take it away from like, most courses on angular will have, RXJS in context of angular, right.

[00:05:58]
So part of the reason and this fundamentals course was just a separate from any framework. And so you can lock it into whether it's react or view, sure you can put a number if you tried. I have not or my case felt we kind of use it for both the stores are similar thing.

[00:06:13]
And you can also like, it's like two lines to wrap a ArcGIS observable and spelt store, but also that kind of I've triggered something. Here all the things I wanna happen, here are the end result, I think is the most important part and that can just be JavaScript like in an agnostic format.

[00:06:29]
>> Someone who follow on to your question I where I've used reactive stream handlers successfully is when I'm getting like 120 data points a second. Coming in from the streamer that I need to send somewhere else, so I can for I can create a stream handler around it fork it to disk On one side for the console logging off one and send to another endpoint.

[00:06:52]
So in that scenario, you're probably gonna end up with a large number or a lot of turnover, if you have a sliding window. I've only used these in like, you wouldn't notice memory hit. In the data that's turning over, do you have a sense of how this would work on a larger dataset.

[00:07:09]
If we use something like filter to, we're placing like 10% of our data every update?
>> Yeah, the like, so I'm currently experimenting there's this right now like for like 10 portals dashboard. You can have anywhere from a few workflows running to theoretically millions, right? At this point like I'm currently stress testing it, I'm like up to 150,000 which is still not even the scale you're talking about with.

[00:07:39]
Like it's tricky you can also keep all that data in memory too. So like my memory footprint is currently large, but I'm also like effectively building a giant object of data in memory. But the actual, like I was shocked by the, like I basically sat down to run these benchmarks.

[00:07:58]
Expecting to come out with a list of work, and it wasn't that bad.
>> Wow.
>> Right, DOM rendering was worse, than like showing out to the page where I had not, why I was thrashing the DOM too much. Was a bigger problem than processing the data in that case that said anything at scale gets weird.

[00:08:19]
Also like we said before request idle callback for like scheduling stuff, so for a lot of these requests. Idle callback is a kind of like set timeout or request animation frame, but it's browser, can give you a function to call when you're not busy. [LAUGH] And you tend to like slot into, so if the users doing something like I won't be refreshing the API, right?

[00:08:43]
But if they stop moving that mouse for a little bit and hang out for a little bit, then I will go ahead. And you can even like there is I think we talked a little bit about from event there is I think, from animation frame as well or.

[00:08:55]
But even an abstraction around that, like we saw in that first test, where you have an observer that says. Request animation frame called next to get the next value and do stuff along those lines. If there's not the API you want, you can then use that kind of base version.

[00:09:08]
But yeah, for that kind of stuff especially with the DOM requests idle callback has been super helpful. I think it's browser only so you don't have I don't think you have it in node. But like you also don't have users touching stuff in node [LAUGH] so, that's helpful as well.

[00:09:24]
>> Is there any additional resources for recipes like for current scenarios?
>> That's a great question, let's see.
>> Marble diagrams may be?
>> [LAUGH] you noticed I made it through how many hours avoiding those, right? Yeah I mean the docs are also, I think once you get the, like the fundamental concepts like I do refer the docs a lot, so it's just RXJS.dev.

[00:09:54]
Like to be clear to also if you're using in react or if you're using with Redux, right? Like Redux is also framework agnostic even though it has a body that hangs out with all the time. I think Redux observables really good, RXJS has the docs himself. I don't know how to get to it from here, but I always know that I can just do it's like API.

[00:10:18]
No. There it is, I can get the creators over here, and then the operators. And then a lot of times I will kind of go through and see which one speaks to me a lot of times. And just kind of figure out, cuz a lot of times like, yeah, these are common problems.

[00:10:35]
You're gonna have weird one off issues in your code base that are just unique to you and the complexities of the problem you're trying to solve. So in here you can kind of like figure out here as well so I spent a lot of time on this page.

[00:10:49]
And then also the the previous one of just the index that these are all like the creators. So you can see that like, have is in here from and then the operators as well to kind of work through all of them. But like for me it was just watching too much random YouTube videos that I have found piecemeal one at a time.

[00:11:07]
>> What do you recommend RXJS instead of Redux saga in a react app for analytics, very specific.
>> Yeah, so Redux saga is another way to asynchronously handle middleware using the saga pattern. I am embarrassed to tell you the story of how we chose Redux observable and RXJS over Redux saga.

[00:11:32]
But I will tell it to you because you asked, I was, this was four years ago, five years ago. We were re architecting our front end code base at the time, and going from like rails and some flux, but we didn't know flux. So we implemented our own flux, and then some JQuery and I do like a more modern version of it.

[00:11:56]
And, the choices were Redux thunk, which has gotten better with like some of the Redux toolkit stuff to be clear. Anything I'm saying ill about Redux thunk, I'm saying about 2017 Redux thunk. And then there are the choices of Redux saga and Redux observable. Redux saga uses generator functions, which as we saw in the very beginning of this course, is not like wildly different in its like syntax right?

[00:12:21]
Like, it has a set of values, generated over time, so on and so forth. But it has a little star on the function and one of the engineers on my team didn't like the syntax. So four or five years ago we committed to Redux observable. Cuz they seemed about equal at the time, but that was our decision making process.

[00:12:45]
So, mostly I continue to go with RHS cuz I am familiar with it, and it has like, we built a very large code base. And that was never the problem, right, and we had to do a lot of questionable like orchestration of API's. To ship the features that we needed to ship when we didn't have the API's that we wanted to.

[00:13:05]
And we're basically very cleanly able to do all of them, that does not mean you couldn't get that done in Redux saga. But we certain point given two options made a choice and unlike a lot of technology choices, we made a choice and then didn't regret it. Right, [LAUGH] so if we wanna test if our status wants a testimonial for the webpage, I'll have a say we chose it and didn't regret it a few years later.

[00:13:30]
Which is the highest praise I think you can give any technology thank you all, thank you so much.
>> [APPLAUSE].