The Observable pattern stands at the core of what we know as reactive functional programming. Basically, the most basic implementation of a reactive functional script encompasses several concepts that we need to become familiar with:

• An Observable
• An Observer
• A timeline
• A stream of events featuring the same behavior as an object's collection
• A set of composable operators, also known as Reactive Extensions

Sounds daunting? It's not. Believe us when we tell you that all of the code you have gone through so far is much more complex than this. The big challenge here is to change your mindset and learn to think in a reactive fashion, and that is the main goal of this section.

To put it simply, we can just say that reactive programming entails applying asynchronous subscriptions and transformations to Observable streams of events. We can imagine your poker face right now, so let's put together a more descriptive example.

Think about an interaction device such as a keyboard. A keyboard has keys that the user presses. Each one of those key strokes triggers a key press event. That key press event features a wide range of metadata, including—but not limited to—the numeric code of the specific key the user pressed at a given moment. As the user continues hitting keys, more keyUp events are triggered and piped through an imaginary timeline. The timeline of keyUp events should look like the following diagram:

What you can see from the preceding timeline of keyUps is that it is a continuous stream of data where the keyUp event can happen at any time; after all, the user decides when to press those keys. Remember the Observable code we wrote, containing the setTimeout? That code was able to tell a concept Observer that every time 2 seconds passed, another value should be emitted. What's the difference between that code and our keyUps? Nothing. Well, we know how often a timer interval is triggered, and with keyUps, we don't really know because it is not in our hands. But that is really the only difference, which means keyUps can be thought of as an Observable as well:

let key = document.getElementId('.search'); 
/* 
we assume there exist a button in the DOM like this 
<input class="search" placeholder="searchfor"></input>
*/

let stream = Rx.Observable.fromEvent(key, 'keyUp');
stream.subscribe((data) => console.log('key up happened', data))

So, what I am really telling you is that timeout as well as keyUps can be thought as one and the same concept, the Observable. That makes it easier to understand all things async. There is, however, another observation we need to make, namely that whatever async concept occurs, it occurs in a list-like way.

Even though the time might differ, it's still a series of events, like a list. A list usually has a bunch of methods on it to project, filter, or in other ways manipulate its element, and guess what, so do Observables. A list can perform tricks like this:

let mappedAndFiltered = list
  .map(item => item + 1)
  .filter(item > 2);

So can Observables, as follows:

let stream = Rx.Observable
  .create(observer => {
    observer.next(1);
    observer.next(2);
  })
  .map(item => item + 1)
  .filter(item > 2);

The difference is just in the naming at this point. For a list, .map() and .filter() are called methods. For an Observable, the same methods are called Reactive Extensions or operators. Imagine at this point that keyUps and timeouts can be described as Observables and that we have operators to manipulate data. Now, take the bigger leap of realizing that anything async, even HTTP calls, can be thought of as Observables. This means that we can suddenly mix and match anything async. This enables something called rich composition. Whatever the async concept is, it and its data can be thought of as a stream, and you are a wizard that can bend it to your will. Feel empowered—you can now turn your application into a reactive architecture.