Cannot opt-in import operator's Type Definitions from 'rxjs/add/operator/***'

[tetsuharuohzeki]

At 5.0.0-beta.1, We can success to compile the following code.
However, this code should not success the compilation because the code does not import rxjs/add/operator/map.

import {Observable} from 'rxjs';

// The compilation should not success
// because this code does not import 'rxjs/add/operator/map'.
Observable.timer(1).map(() => {}).subscribe(() => {});

I'm not sure this problem is a higher priority issue, but I think this may be a problem.

@kwonoj @david-driscoll Do you recognize this problem?

[tetsuharuohzeki]

Do you recognize this problem?

Ah, My intention was "Have you already know this problem?"

[kwonoj]

That's expected currently, by the way it works. So answer is yes, I do aware of it.

Solving this is not trivial though. What we want (and do) is allowing import operator module dynamically, and for this we also want to bring type definition to be dynamically provided per import, while type definition is typically expected to be published statically. It's also somewhat related with operator import itself, if you look into add/*, you can see it's using prototype patching at runtime. Means at compile time, TypeScript does not able to do much. I was once thought about using mixin / ambient class merging for modular operator supports those behavior, but that also had couple of drawbacks at the moment.

[kwonoj]

You may refer issue at #642, not directly related but somewhat related. It's also hit by statically published type information, so extended operator definition's not supported at the moment.

[kwonoj]

Just adding few additional details from TypeScript side support so far I know

• Extension method : on discussion
• traits : probably won't
• ES7 bind operator (::) : on discussion

Those are mechanics I was considered as possible solutions related to some of type / modularity issues but all of them are not in our hand at this moment. It's still possible there's elegant way that I haven't thought about.

[kwonoj]

Noticed this microsoft/TypeScript#6213 too, might be feasible solutions..

[benlesh]

So to clarify this issue, the issue is that TypeScript thinks it's okay to use map even if map isn't there because we didn't import it?

[kwonoj]

Yes, that's correct by Observable already have all type defintions of CoreOperator regardless of importing actual operator or not.

[kwonoj]

I'm assigning myself for evaluating once typescript side changes arrives.

[masaeedu]

@kwonoj If you're doing that refactoring, it might be a good idea to deduplicate the method signatures at the same time. I was discussing this with @david-driscoll in the gitter chat room, but essentially, it is possible to define the signature of the operator functions in an interface, then import that interface in CoreOperators, Observable and wherever else a member of that type is needed.

Once the feature you mentioned lands, you'd change the patch generator to simply re-export the interface like so:

import {map} from '../operators/map';

declare module "../Observable" {
    interface Observable<T> {
        map: map<T, U>;
    }
}

The interfaces themselves could be generated to expand out the ... parameters up to certain number of arguments, and can be evolved separately from the implementation (so long as the implementation is still assignable to the interface). I've done some work on this in https://github.com/masaeedu/RxJS/tree/operator-typing-fixes

[kwonoj]

Thanks for details. Yes, that was my intended evaluation to let patch operator contains declarations and each (Observable, i.e) imports it to add necessarily. Appreciate for suggestion!

[tetsuharuohzeki]

After #1262 now, we can use the feature microsoft/TypeScript#6213 !

[kwonoj]

I'm already trying on it locally and found some interesting issues compiler complains. Think need some more time to triage and align changes to make this work.