feat(filter): Observable<T>.filter() can take a type guard as the predicate function

[tetsuharuohzeki]

Description

Before

By the previous code base, we need to use filter() + map()

interface SuperClass {}
interface DerivedClass extends SuperClass {}

const bar: Observable<SuperClass> = someobservable;
const derived: Observable<DerivedClass> = bar.filter((v): boolean => {
    // some type guard logic
  }).map<DerivedClass>((v) => v as DerivedClass);

After

By this change, we can write this code:

const bar: Observable<SuperClass> = someobservable;
const derived: Observable<DerivedClass> = bar.filter<DerivedClass>((v): v is DerivedClass => {
  // some type guard logic
});

Related issue (if exists)

microsoft/TypeScript#10027

[coveralls]

Coverage remained the same at 97.129% when pulling f3c33cd on saneyuki:filter-typing into d876a35 on ReactiveX:master.

[david-driscoll]

Let me preface this with, awesome job, this is something I wouldn't have thought of directly, but it does make it much easier to flow types, if you have to deal with unions 👏.

Only issue I have is that I think this applies to more operators than just filter.

I feel like this would benefit....

• filter
• find
• first
• last

cc @Blesh @staltz @kwonoj

It may even also apply to partition (although we can only narrow the positive result type).

[kwonoj]

Agreeing with @david-driscoll , I think this change's good and would like to expand to other possibly supported operators as well.

[tetsuharuohzeki]

okay. I'll update this pull request.

[tetsuharuohzeki]

okay. I'll update this pull request.

updated :)

[coveralls]

Coverage remained the same at 97.129% when pulling 4494973 on saneyuki:filter-typing into 1b716ff on ReactiveX:master.

[david-driscoll]

LGTM

👍

[kwonoj]

it's just nitpicking, but I'm feeling this'd be better to be interface level comment (@ line 61) - what do you think?

[tetsuharuohzeki]

Ok. I'll change to it.

[kwonoj]

LGTM, only one nitpicking comment about comment location.

[tetsuharuohzeki]

@kwonoj I just updated & fixed what your pointed.

[coveralls]

Coverage remained the same at 97.128% when pulling 76a8a57 on saneyuki:filter-typing into 36c7676 on ReactiveX:master.

[rob3c]

I just asked about how to flow types through Observable chains in this typescript issue: microsoft/TypeScript#7657 (comment)

It'd be really nice to avoid what seems like a bunch of unnecessary casting, but I'm not sure if it's a typescript limitation or if it's addressable via better type definitions.

[rob3c]

Just a quick update: I found a way to rewrite the type definitions to not require all of the casting above. I'm creating a pull request now...

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.