discuss: ES Observable Interop

[lacolaco]

Angular 2 depends on Observable of RxJS, and RxJS is a prolyfill for ECMAScript Observable Proposal.

Some other JavaScript libraries are starting to add interop of that spec.

• feat(store): add observable proposal interop to store by blesh · Pull Request #1632 · reactjs/redux
• Add ES7 interop by briancavalier · Pull Request #254 · cujojs/most

There are implementations the Observable spec.

• RxJS 5
• zenparsing/zen-observable: An Implementation of ES Observables

And recently, core-js ver.2.4.0 supports shim of ES Observables.

core-js/CHANGELOG.md at master · zloirock/core-js

So, already we can use plain Observable without RxJS. Does core team have any plans to add ES Observable interop to @angular/core, @angular/http and other angular2 packages, and make RxJS dependency optional?

[robwormald]

In the short term I don't think we have any plans to move off RxJS, mostly because Observable by itself has limited utility without a certain set of operators (map/flatMap/reduce/scan/filter) etc, and outside of RxJS there aren't a lot of them implemented, and we depend on a very small portion of Rx inside of core.

Removing Rx from the core would mean anywhere we expose an Observable API (say, forms) - you would have to cast to RxJS to use something like flatMap:

Observable.from(this.searchInput.valueChanges).flatMap(fn).subscribe(...);

Which is fine, I guess, but it's not something I'm rushing to implement anytime soon, to be honest.

As of today (as RxJS supports Symbol.observable) you could use a different Observable implementation by doing the same as above with your own library.

I would, in the near term like to provide ES Observable interop for APIs that accept observables - the async pipe, for example, should be able to accept anything that implements the ES observable spec.

Given that we use a tiny subset of RxJS, is there some other pressing reason you'd like to drop the dependency? RxJS has far more utility than anything we'd implement ourselves.

[lacolaco]

@robwormald Of course, I know benefits of RxJS. And I always wonder that; "why RxJS is in peerDependencies?".

https://angular.io/docs/ts/latest/guide/npm-packages.html

rxjs - a polyfill for the Observables specification currently before the TC39 committee that determines standards for the JavaScript language. Developers should be able to pick a preferred version of rxjs (within a compatible version range) without waiting for Angular updates.

But actually, Angular uses RxJS as a library/utility of async architecture. If RxJS is a real polyfill, it should be able to replace to other implementations. If it isn't, RxJS should be in dependencies.

Long time ago, I and @IgorMinar discussed about this issue at https://github.com/angular/angular/issues/6659

But now, I want you and team to discuss again; "is RxJS a polyfill in Angular?"

I would, in the near term like to provide ES Observable interop for APIs that accept observables - the async pipe, for example, should be able to accept anything that implements the ES observable spec.

Sounds great. I love something like this. :)

Thank you.

[kylecordes]

@robwormald I am not the original poster and I unsure how pressing this is, but it seems somewhat analogous to an AngularJS 1.x situation:

Back when A1 first shipped, it was both expedient and reasonable to ship its own promise implementation. They were not (at least popularly) standardized yet, it was unclear what library might become dominant, it was unclear whether Promise would ever make it into the language spec, etc. Down the road a few years though, there was a spec almost everyone followed, and then last year promises ended up in the language itself.

Fast-forward a couple years from now, with Observable. There is an opportunity now, though perhaps not worth the cost (of possible delay and difficulty) to target the nascent Observable spec rather than the RxJS implementation (of which I am a huge fan). This would mean treating RxJS as a polyfill, and coming up with some solution to provide a handful of additional operators etc. needed that are not contemplated for the proposed spec. (Perhaps RxJS could be that solution, though hidden inside A2 and not pushed out to every A2 application in the form of a peer dependency.)

If the opportunity is taken, it is like we will all be happier with the results, a few years from now. But it will add extra work now, it will endanger the schedule etc., so probably the practical answer is to just keep the dependency on RxJS, and when we look back in a few years we can simply accept that implementation-rather-than-interface dependency (by then it will be also depended on by a million Angular applications) as a cost of Angular 2 having stabilized in 2016. Just like we can look back and see $q as a cost of AngularJS having materialized when it did.

Hope this helps, good luck.

[robwormald]

@kylecordes

There is an opportunity now, though perhaps not worth the cost (of possible delay and difficulty) to target the nascent Observable spec rather than the RxJS implementation (of which I am a huge fan).

RxJS does implement the nascent Observable specification, which is why we use it, so any effort later on would be minimal, especially as compared to implementing our own polyfill and maintaining a set of operators, of which there would be basically zero consensus on which to include.

Given the modular nature of RxJS and the complete lack of competing implementations that have any utility, I don't see the fact its a peerDependency as a major issue, as its basically a one-time setup with minimal byte cost, and an easy opt-in to a very powerful ecosystem if one desires.

I've opened https://github.com/angular/angular/issues/8848 to track interop with other Observable implementations (eg, accepting them via the async pipe) and I'm going to close this in the meantime.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}