RxJS History
Get the project source code below, and follow along with the lesson material.
Download Project Source CodeTo set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.
- |
Lesson Transcript
[00:00 - 00:08] In this lesson, we are going to explore a little bit of history of how RxJS came to be. Initially, developers utilized callback functions.
[00:09 - 00:19] Those are just functions that you pass as parameters to other functions to be executed once a task is finished. However, this approach quickly revealed several drawbacks.
[00:20 - 00:27] The first one is readability and maintainability. It becomes clear that this structure is very hard to read and I also maintain.
[00:28 - 00:34] The second drawback is error handling. You see how quickly it becomes very unpleasant to do error handling.
[00:35 - 00:39] And the last one is debugging. This structure is actually called callback hell.
[00:40 - 00:45] Now, in order to solve this problem, smart people came up with promises. So, what are promises?
[00:46 - 00:59] Promises are objects that denote the potential completion or failure of asynchronous operation. The ability to change results from preceding functions enhances code readability offers a cleaner structure and mitigates the callback hell.
[01:00 - 01:05] This is what the promise looks like. So, you will call your function which will return a promise.
[01:06 - 01:11] Once the promise resolves, you can call another function with its output. And so forth and so forth.
[01:12 - 01:18] So, basically, this part here does the same as in the previous one. Except, now it has solved a few problems.
[01:19 - 01:28] So, this structure becomes more readable. It's a lot easier to maintain, debug and also handle any errors that rise from handling a promise.
[01:29 - 01:37] However, promises come with their own set of limitations. They are not cancelable, meaning once initiated, a promise will run to completion.
[01:38 - 01:45] Additionally, promises execute immediately upon creation, which isn't always desirable. Later, async/await came to be.
[01:46 - 01:53] Async/await is built on top of promises. And it's actually syntactic sugar for promises.
[01:54 - 02:02] This is what it looks like. And for people that know languages like C# or Python, this syntax looks very familiar.
[02:03 - 02:11] The advantage of async/await is that it makes asynchronous code look synchronous. And also, it proves readability, maintainability and error handling.
[02:12 - 02:20] But unfortunately, async/await doesn't really solve the problem that promises have. So, they have the same drawbacks as promises do.
[02:21 - 02:27] And so, there is no cancellation mechanism. And also, once a function is executed, it executes immediately.
[02:28 - 02:36] So, there is no way to delay this. Later on, people came up with RxJS, which is short for reactive extension for JavaScript.
[02:37 - 02:43] This is what it looks like. It does the exact same thing as the previous async/await or promise that you've seen.
[02:44 - 02:57] For those of you who are not familiar with observables, subscriptions, I promise, by the end of this course, you will feel very comfortable in using observables and subscriptions and working with RxJS.
In this lesson, we are going to explore a little bit of history of how RxJS came to be. Initially, developers utilized callback functions. Those are just functions that you pass as parameters to other functions to be executed once a task is finished. However, this approach quickly revealed several drawbacks. The first one is readability and maintainability. It becomes clear that this structure is very hard to read and I also maintain. The second drawback is error handling. You see how quickly it becomes very unpleasant to do error handling. And the last one is debugging. This structure is actually called callback hell. Now, in order to solve this problem, smart people came up with promises. So, what are promises? Promises are objects that denote the potential completion or failure of asynchronous operation. The ability to change results from preceding functions enhances code readability offers a cleaner structure and mitigates the callback hell. This is what the promise looks like. So, you will call your function which will return a promise. Once the promise resolves, you can call another function with its output. And so forth and so forth. So, basically, this part here does the same as in the previous one. Except, now it has solved a few problems. So, this structure becomes more readable. It's a lot easier to maintain, debug and also handle any errors that rise from handling a promise. However, promises come with their own set of limitations. They are not cancelable, meaning once initiated, a promise will run to completion. Additionally, promises execute immediately upon creation, which isn't always desirable. Later, async/await came to be. Async/await is built on top of promises. And it's actually syntactic sugar for promises. This is what it looks like. And for people that know languages like C# or Python, this syntax looks very familiar. The advantage of async/await is that it makes asynchronous code look synchronous. And also, it proves readability, maintainability and error handling. But unfortunately, async/await doesn't really solve the problem that promises have. So, they have the same drawbacks as promises do. And so, there is no cancellation mechanism. And also, once a function is executed, it executes immediately. So, there is no way to delay this. Later on, people came up with RxJS, which is short for reactive extension for JavaScript. This is what it looks like. It does the exact same thing as the previous async/await or promise that you've seen. For those of you who are not familiar with observables, subscriptions, I promise, by the end of this course, you will feel very comfortable in using observables and subscriptions and working with RxJS.