- [Instructor] Before we start learning RXJS,
let's talk for a minute about what it does,
and why we like it.
For me, the easiest way to explain this,
is to back up and understand the evolution of JavaScript,
and the word asynchronous.
Asynchronous means not occurring at the same time.
When we right code, the computer will start at the top of
the file, and execute our code one line at a time.
In this context, asynchronous means that when you call a
function, the computer will continue to the next line,
and keep executing code.
Sometimes this happens before the first
function has completed.
Originally, that was awesome because it made JavaScript
run very fast, and fast is good right?
Right.
When I first learned JavaScript, most of our web content
consisted of static HTML pages,
because Angular and React hadn't been developed yet.
So there was nothing wrong with being asynchronous.
In fact, it was really fast, and we liked that.
Then one day I started using Angular.
With two-way data binding in NG repeat,
suddenly I could use variables and loops right in my HTML,
and it was awesome.
This made it so much easier to write dynamic content.
I could loop through each item in a collection,
and display all my data,
even if I didn't have those values yet.
Behind the scenes, Angular would do all this magic,
interpolate all my variables, and render the DOM,
or in other words, create the HTML page.
So far, so good, right?
Wrong.
I ended up with an empty page...why?
Because my old friend Async, and my new friend Angular
were having some fun at my expense.
Basically, I made a request to the server
to get all my data.
Meanwhile, Angular interpolated my variables,
and rendered the page super fast.
Unfortunately, Angular did this without waiting for my data
to come in from the server.
So when the page was rendered, it was blank.
Suddenly, being asynchronous wasn't
as cool as I thought it was.
So how did we solve that?
With Callbacks.
Here's a simple example where we're passing a Callback
into a function as an argument.
In this example, we're going to request data from the server
like normal, but now with the Callback my code is smart
enough to wait for the data to come back from the server
before moving on to the next function.
So basically, a Callback says,
wait for this code to complete before continuing.
So, perfect, right?
Well, not exactly, not yet.
Because we ran into problems again when our applications
got more complex.
And we ended up with Callbacks inside of Callbacks,
inside of Callbacks, et cetera, et cetera.
Affectionately referred to by developers everywhere
as Callback Hell.
Not to mention, we couldn't return values from a Callback,
and error handling was really difficult.
So while Callbacks were a great solution at first,
we quickly outgrew them.
After Callbacks, the next big thing was promises.
We were pretty excited about Promises,
they made error handling super easy, we could return values,
and we could even chain Promises, so awesome.
So basically a Promise was like a placeholder.
We could return a Promise, which would let us know we were
waiting on something.
The Promise also gave us a method called "then,"
which is the trigger signaling that the
Promise operation has completed.
The Promise gave us nifty methods like Resolve,
meaning stuff worked.
Reject, for error handling.
So with dot then, Resolve, Reject, and a few other helpful
methods, Promises made code cleaner,
and life easier for many people, myself included.
However, technology continued to evolve and before long,
we outgrew Promises too.
But why?
Because suddenly, there was a new industry buzzword
called Real Time.
Next thing you know, we have Real Time Updates,
Real Time Analytics, Real Time Data.
We want messages delivered instantly,
and we want the absolute latest data,
and now, we also want it constantly updated
across all our various devices.
And while we can still use Promises for this,
we can only use each Promise once.
So now you understand Callbacks, right?
We're just telling it to wait for something
before going to the next step.
And we understand Promises, right?
It's just a cooler version of a Callback.
Same functionality, plus built in error handling and the
awesome "then" method.
Well guess what, if you understand Callbacks and Promises,
then you understand Observables.
Basically, an Observable is a reusable Promise that keeps
listening after the "then" method.
So, here you see dot subscribe, which is very similar to
dot then, except it's reusable.
So you can wait for something to happen, respond,
then keep listening for the thing to happen again,
and respond again.
Every time your Observer fires dot next,
your subscribe function will go again.
We'll do this together later in the course,
but for now, just know that the console log will print one,
then two, then three,
then you can close it when you're finished.
So you can wait for something to happen, respond,
then keep listening for the thing to happen again,
and respond again, make sense?
Instead of "then," Observables have a subscribe method,
which will listen for Real Time updates,
and respond each time.