-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Should we just detect that it fulfills the interface instead of using Symbol? #1
Comments
I don't understand. I use Symbol detection is better as it's guaranteed to work. The reason |
I was definitely getting false negatives on zen-observables using Not sure why. Might be related to recent changes to It seems to be an issue with whatever version shipped with ava@0.14 (we've bumped since releasing). Also, I had loaded |
I ran the test with latest (0.2.3). |
// @Blesh |
Symbol detection is preferred because However, the only way to be sure you have an observable is to find |
Passes: const isObservable = require('is-observable');
const ZenObservable = require('zen-observable');
const assert = require('assert');
assert(isObservable(new ZenObservable(() => {})), 'zen'); Fails: const ZenObservable = require('zen-observable');
const isObservable = require('is-observable');
const assert = require('assert');
assert(isObservable(new ZenObservable(() => {})), 'zen'); Only difference is the import order of |
I experience the same false-negatives in |
Not sure how "hot" this topic still is, but how about: Boolean(obj && typeof obj.subscribe === 'function' && obj.constructor.name === 'Observable') It's still hacky, but at least it's plausible. Used in |
@andywer This is what various Observable libs returns with
|
@sindresorhus Ohh dear lord... 🙈 🙃 |
RxJS 5 will return any number of things from that depending on what you're doing. ScalarObservable, Observable, PromiseObservable etc. |
I cannot reproduce this issue anymore. This example for instance failed, like @jamestalmage described above. const ZenObservable = require('zen-observable');
const isObservable = require('is-observable');
const assert = require('assert');
assert(isObservable(new ZenObservable(() => {})), 'zen'); Zen as well as RxJS both worked, independent on the order I imported them. Am I missing something or can we close this one? |
Can someone confirm my findings? I really want to switch to |
Seems to work now 👍 |
Darn, this happens again with RxJS@6. I don't have any problems with RxJS@5 though. const {Observable} = require('rxjs');
const isObservable = require('is-observable');
const assert = require('assert');
assert(isObservable(new Observable(() => {})), 'rxjs');
If I import |
It looks like it is unrelated to the opening post. Apparently, const symbol = typeof Symbol === 'function' && Symbol.observable || '@@observable'; This means that it looks if So for Listr, I used the following implementation const symbolObservable = typeof Symbol === 'function' && Symbol.observable || '@@observable';
const isObservable = value => Boolean(value && value[symbolObservable] && value === value[symbolObservable]()) || require('is-observable')(value); And now the detection works perfect. Not sure how to go forward for |
@SamVerschueren libraries shouldn't be polyfilling for you, devs need to add polyfills first, then load libraries. I had to learn that the hard way with RxJS. :) PS: That little bit in RxJS with the |
@benlesh I totally agree and understand that libraries shouldn't polyfill. The thing is that const rxjs = require('rxjs');
const isObservable = require('is-observable'); So RxJS falls back to |
This module no longer uses the |
Using Symbol is not 100% reliable unless every implementation installs the symbol the same way.
One recent issue: zenparsing/zen-observable#9
Should we detect similar to
is-promise
? Via feature detection:Why is Symbol detection preferred?
The text was updated successfully, but these errors were encountered: