What to make of RxJS?

Big hard method good!

Reactive Extensions is a functional responsive programming abstraction developed by Microsoft. It was first used in.NET (in the System.Reactive namespace but not in the standard library) and has since been extensively ported to other languages. For example, RxJS is a JavaScript port of Rx.

Although the languages are different, the core ideas of Rx and the main apis are still common, so what we have here applies equally to RxWhatever.

To explain functional responsiveness, let’s take a brief look at functional programming. In LoDash, for example, we can use method chains to implement complex operations:

interface Person {name: string, age: number}declare const people: Person[]

_(people)
  .filter(person => person.age >= 18)
  .forEach(person => console.log(`${person.name} is an adult.`))Copy the code

For general functional programming, we combine and transform some collection containers of data (Array, Map, Set, etc.), while in Rx, we deal with a special data collection called Observable, which can be regarded as an event flow.

Now, since each data item is an event, we don’t have all the events at the beginning, and we don’t know exactly when the events occurred.

For a very simple example, we still need to process the person above, but the person is not acquired simultaneously, but is created dynamically through user interaction. Of course, we could have written everything in the callback function, but that would have resulted in very high coupling and bad code quality.

So, we can make the creation of person here a stream of events and not care where it’s used or how it’s used.

class SomeComponent {
  people: Subject

  onCreate(person: Person) {
    people.next(person)
  }
}Copy the code

For real callers, it’s just a matter of getting the Observable and doing the rest.

const people$ = getPeopleObservableSomehow()

people$.filter(person => person.age >= 18)
  .subscribe(person => console.log(`${person.name} is an adult.`))Copy the code

If we have other data sources, such as initial data from the server and subsequent data generated through interaction, we can do a combination:

const initialPeople = getPeopleSomehow()const people$ = getPeopleObservableSomehow()const allPeople$ = Observable.from(initialPeople)
  .mergeMap(people$)

allPeople$.filter(person => person.age >= 18)
  .subscribe(person => console.log(`${person.name} is an adult.`))Copy the code

In this way, our code can have high reusability, while greatly reducing the coupling and improving the quality of the code.

In addition, one of the major differences between functional responsive programming and its imperative counterpart is that functional responsive programming is push-based while imperative programming is (usually) pull-based. In other words, we don’t have values in functional responsive programming (we don’t get data by assigning).

We know that the iterative behavior achieved through callback functions can also be achieved through loops (e.g., for… Of and Array#forEach), can an Observable use loops?

It’s not recommended most of the time, but it’s totally feasible. For example, we can simply implement Iterable for Observable:

Observable[Symbol.iterator] = function () { let current = null let resolveCurrent = null let rejectCurrent = null let isDone = false function update() { current = new Promise((resolve, reject) => { resolveCurrent = resolve rejectCurrent = reject }) } update() this.subscribe(item => { resolveCurrent(item)  update() }, error => { rejectCurrent(error) update() }, () => { isDone = true }) const next = () => ({ done: isDone, value: isDone ? null : current }) return { next } }Copy the code

In this way (only an idealized implementation, not strictly verified, should not be used directly in real projects), we can pass for… To use in a loop:

for (let itemPromise of someObservable) {  let item = await itemPromise  }Copy the code

However, we would still need to use await in the body of the loop, which is not pretty (it is pretty pretty, just for the purpose of saying so), so we can go one step further and implement Async Iterable directly (still a Stage 3 proposal, hopefully in ES2017) :

Observable[Symbol.asyncIterator] = function () {  }Copy the code

Then we can loop in a simpler way:

for await (let item of someObservable) {  }Copy the code

In Angular 2, the EventEmitter is an Observable, because the @Output EventEmitter is a Subject. But while Angular 2 uses it, it’s not tied to our code, so if you don’t want to use Rx, you can ignore it altogether.

Another area where Rx is used is the Http module, which Observable serves as the interaction object for most of the API. Of course, Http itself is not necessary, it is only an official external extension, and there is no implementation specificity compared to other third party libraries (although the API design may be more uniform). So if you still don’t want to use an Observable, you can convert it to a Promise using.toPromise, or use a third-party Http Client like SuperAgent, or use the Fetch API directly. Because of zone.js, there is no need to wrap Angular accordingly.

In fact, Rx is also used in the Router module. For example, some apis in the ActivatedRoute interact in the way of Observables to realize dynamic responses. Of course, we could just use ActivatedRouteSnapshot so that we can directly process the data itself. The Router module also has no implementation specificity, and we can use the Angular 2 version of uI-Router if we wish.

However, as you can see from the above, Angular officially recommends Rx for the most part, and makes extensive use of Rx in API design to simplify the complexity. If you really want to develop team projects with Angular 2, it is worthwhile to know something about Rx. By contrast, not using Rx at all may actually require a higher learning cost.