Transcript from the "Introduction" Lesson
[00:00:00]
>> Hello, welcome to RxJS fundamentals. This is an intro course on how to use RxJS to solve some common problems. With that, there is one, no expectation that you've used RxJS before, so that's good. We're also gonna be completely framework agnostic. I know that a lot of times our RxJS is associated with Angular these days, but you can use it with anything.
[00:00:24] I've used it with React and Redux before, I use it today in this svelte app that I work on, it is at the end of the day just JavaScript. So we're gonna play with it agnostic of any framework and again, we're gonna start from the very basics, and kind of build up an understanding.
[00:00:42] Cuz in my experience, there's a lot of great content on RxJS, but a lot of times, it's like let's go into some conceptual understanding of marble diagrams. And then all of a sudden, escalates quickly until there's seven nested observables and you're like, I wanna cry. So we're taking things very slowly, we're gonna build up from each piece as we get to some more sophisticated examples towards the end.
[00:01:06] So we will kind of play around with some basic unit tests, you understand how some of the fundamental parts of RxJS work. We'll start building some very kind of simple interactions in some applications. And we'll solve some of the kinda common UX issues that come up that RxJS is just really well suited to handle.
[00:01:27] In a lot of cases, you don't necessarily need to use RxJS for everything. So part of this is understanding where a simple promise will do, and where you might end up in a situation where things are getting a little squirrely. At the end of the day, anything you can do in RxJS, you can do in regular JavaScript because RxJS is built in regular JavaScript.
[00:01:46] The big question is should you, right? Enough of these things where you start reinventing the wheel and throwing global variables or even module scoped global variables everywhere. And then eventually, you and your team developed a deep resentment for you, which I'm gonna try to save you from during this.
[00:02:05] So, let's just talk, we're not gonna do a whole lot of the kind of conceptual theory here. I wanna start getting our hands dirty very, very quickly. But let's do just at least a high level understanding of what's going on, what is RxJS? What did you just sign up for?
[00:02:19] What are we gonna be talking about for the next little bit? So then I saw this quote from the RxJS documentation, you can think of RxJS like Lodash for events. In Lodash, we have a lot of helper functions for dealing with arrays and objects, and all the stuff that just comes with JavaScript not really having a standard library to speak of, right?
[00:02:44] So Lodash gives us a bunch of utility functions. Yes, you could write them yourselves. But a lot of times if you want them kind of tweaked for performance, everything along those lines using a battle tested library makes sense. RxJS Is basically dealing with that, but things that happen over time.
[00:03:00] And you're like, okay, like what? Well, if you think about it, the way that our applications work is, we send the code to the browser, we send some HTML, loads of some CSS and some JavaScript. We render an initial page, the traditional web page, right? And then really, everything that happens after that, right, as soon as we load up that HTML page and run through the initial scripts, the event loop kind of just sits there and waits for stuff to happen, right?
[00:03:27] And all that stuff that can happen is an area where there is a chance that RxJS might be helpful, depending on what kind of problem you are trying to solve, right? Things are gonna happen over time. Arrays give you a collection of things all at once. You can work through the array.
[00:03:42] You can map over it, you can filter it. But if those values come in over time, maybe through a series of click events, maybe through a timer, maybe with an API requests, right? Yeah, you can load it into an array, recheck the array, or you can just kind of think about things as streams of events happening in our application and write code around that as we go.
[00:04:02] So, there is an abstraction for asynchronous values that is now in the Ekman script standard, and it's called promises. And promises are great. I love promises, they're wonderful. The problem with promises, and this is not really a problem with them, it's just what they promised to do, is that they resolve to one eventual value, right?
[00:04:24] And so you have a promise of this one API request or one thing that happens, it becomes a value. Now imagine programming without arrays or objects, right? It's up a series of go to statements, you could figure it out, it'd be great. But the idea of having this idea of a collection, right?
[00:04:41] The way you can think of a promise as one eventual value, I think a really good mental model that could be helpful is thinking about effectively an observable as an array of eventual values. So promises are one just like a primitive like a number, a string, or even a JavaScript object is one object.
[00:05:00] And an array can be a set of them. A promise is good for one value, that could also be an array in this case. An observable is things that are gonna happen kind of over time. So let's talk a little bit about what some of those things might be.
[00:05:14] We have APIs, right? And yes, you send a promise, you go get the JSON or what have you from an API. Great, but there's a whole bunch of like edge cases, like do you wanna refresh, stuff along those lines? So promises are great for a happy path. You even have a catch in the case that it doesn't work out.
[00:05:33] What if you wanna try, retry a certain number of times. Okay, well yeah, you could maybe keep a value somewhere in scope and just try to iterate it, and then write an if statement, so on and so forth. You can see how this things start to get a little squirrely.
[00:05:49] What happens if you wanna reload the data at a regular rate? Okay, now you can do a set interval, and you can aspire to clean up that interval and help you get it right. But you're also matching that with now the retry thing that we just talked about.
[00:06:02] What happens is you wanna iterate across a paginated API, right? A lot of times as front end engineer, the reason that I'm employable is because for a lot of the UI that we wanna build, the API's don't support that. So I have to do a bunch of Rube Goldberg machines in order to get the UI in place.
[00:06:19] So if we need to start iterating recursively, then yes, you could do that. But could you do that with retries? Could you do that with a regular refresh interval? Starting to pull all these pieces together like any one thing, maybe not that complicated. Pulling it all together requires a better abstraction so that we don't get lost in our own complexity.
[00:06:38] So observables can help with all of this. This is the other part. I used to work at a company that I will not name. But we had this idea of a user, right? And you need to know the current user to figure out what you are gonna show on the page.
[00:06:53] That seems fine, right? And there was an API for getting the current user. However, if you wanted to know whether it was a regular account or a sub account, well, that was another API. Did you want to know if it was part of a team or an individual account?
[00:07:06] That was another API. Did you wanna know if it's a free or premium account? Well, that was another API. So in order to figure out what to show on the page, we had to send out this battalion of API requests and try to orchestrate it all at once.
[00:07:19] And so we have a lot of situations where to show a given piece of UI, maybe you have a list index that only gives you the IDs of the things that match if you want to figure out more data, you have to go hit each one of those individually API's, right?
[00:07:31] Coordinating all that stuff can be some what complicated and so observables seek to help us with that, right? And to help us deal with the common error path and just give us a effectively. RxJS is not a framework but if we think about like a scaffolding or a framework for dealing with the complexity of orchestrating multiple things that could happen asynchronously.
[00:07:52] So observables can help with this as well. Then there's also just little UX quality of life things, right? It's usually good to show a loading indicator, right? And that's fine, but how soon do you show the loading indicator, right? Cuz the first time I implement that, this is what happens, is the API ends up being fast, and then I showed a loading indicator flashes for a hot minute and then it vanishes, right?
[00:08:18] And so how do you time it? Okay, I only wanna show the loading indicator in one situation, if it takes a certain amount of time show the loading indicator, right? But what if the API request comes back right after I show the loading indicator? Well, even if the API has failed, I might wanna still show the loading indicator for long enough time that's not visually distracting to the user, even if we're done loading, right?
[00:08:39] These are the issues of dealing with events that happen over time and coordinating all of these things that RxJS seeks to help us with. There's all sorts of little other things like dragging and dropping, right? If you think about that problem, you end up, all right, so on mouse down on the element that we wanna click, cool.
[00:09:00] Then I want to set up an event listener that is listening for mouse movements until they release and we have a mouse up event, right? And then we also have the issue of where they're dragging might have other implications in our UI, right? If it is a hover state where they can drop it in that given area, we might wanna show different things.
[00:09:21] So reacting to all those things and setting up all those different movement events can be super helpful as well. So that's the pitch. That is hopefully I've sold you on spending some time together learning this.