-
Notifications
You must be signed in to change notification settings - Fork 3k
Add prototype-patching operator modules #750
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
It's obvious how this will benefit browser end-users, but what about the node users? While updating Also: What are alternatives we've considered? |
I think from the outside, the story doesn't really change for a node user: before: //Rx.ts
import {Observable} from './Observable'
import {map} from './operators/map'
//etc
Observable.prototype.map = map;
export {Observable} after: //Rx.ts
import './operators/map'
import {Observable} from './Observable'
//etc
export {Observable} browser user who wants the whole mess: import {Observable} from 'rxjs/Rx'; browser user who only wants map import {Observable} from 'rxjs/Observable'
import 'rxjs/operators/map' node user who wants the whole mess var Rx = require('rxjs') //package.json maps to main: Rx.js I just tested that and it appears to work fine. Barring that, |
@robwormald what is the status on this? |
About 20 minutes away
|
👍 |
Closed by @robwormald in d17a42f |
(Recapping some offline discussion between @Blesh, @IgorMinar, @robwormald and myself)
In order to allow exporting a minimal
Observable
and to increase composition of operators, while maintaining nice chaining syntax, we propose exporting each operator as an easily-importable module that will have a side effect of patching theObservable
prototype.With TypeScript 1.8, there will be support for this type of module to re-open and extend types, so we can not have to stub out all types on the
Observable
class like we do now. In anticipation of this change, we should go ahead and add interfaces for all operators, with optional methods. TheObservable
class will implement all operator interfaces instead of manually stubbing out methods on the class itself.It's not ideal for an import to have side effects, and to mutate a shared object. In this case, I think the mutation is not likely to cause issues for people, since most folks will only import operators in one place inside an application. And if folks are only importing operators from rxjs, there's no risk of method name collision.
Eventually, when JS has sugar like function bind to make extension-like functions more composable, there should be a breaking change to remove the side effect of the imports.
The text was updated successfully, but these errors were encountered: