Skip to content
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

Re-fix isObservable() and add test - fixes #29 #30

Merged
merged 3 commits into from
Sep 16, 2016

Conversation

andywer
Copy link
Contributor

@andywer andywer commented Sep 16, 2016

Moved isListr and isObservable into a separate util.js and added a unit test for the util.js. Verifies that isObservable() works with both rxjs/Observable and zen-observable.

isObservable() checks for obj.constructor.name === 'Observable' now. Still somewhat hacky, but at least a plausible way to go as long as there's no official solution.

Btw: Maybe propose this to sindresorhus/is-observable#1?

Copy link
Owner

@SamVerschueren SamVerschueren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change the name to lib/utils.js

import {isListr, isObservable} from '../lib/util';

test('isListr', t => {
t.falsy(isListr(null));
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use t.false and t.true.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initially I did. But it failed, since right now isListr() will return null or the listr instance itself if it is. So then I just added a ... ? true : false to isListr(), but xo failed, because for some weird reason it complains that the ternary is superfluous...

Any suggestions?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrap it in Boolean(...)

@@ -0,0 +1,8 @@
'use strict';

const isListr = obj => obj && obj.setRenderer && obj.add && obj.run;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Export the function right away without intermediate step.

@andywer
Copy link
Contributor Author

andywer commented Sep 16, 2016

Fixed the code 👍

@SamVerschueren
Copy link
Owner

Can you rename util to utils? Filenames and variables.

@SamVerschueren SamVerschueren merged commit a620662 into SamVerschueren:master Sep 16, 2016
@SamVerschueren
Copy link
Owner

Sweet! Thanks for looking into this @andywer 🍻 !

@andywer
Copy link
Contributor Author

andywer commented Sep 16, 2016

@SamVerschueren No problem 🙌

@TylorS
Copy link
Contributor

TylorS commented Sep 28, 2016

This actually breaks the stuff that I'm working on because of the changes to isObservable. The stream library I'm using is most.js and it's constructor.name is Stream and not Observable. However it does implement Observable interfaces.

@SamVerschueren
Copy link
Owner

@TylorS I'm not interested to actually support all the possible observable-like implementations out there. The reason I use duck-typing currently is because of an issue with is-observable which uses Symbol to detect if it is an Observable. If that issue gets fixed someday, I will start using that one and most.js will break again. So currently I'm trying my best to support RxJs and zen-observable. The only thing I can say about your issue is that maybe you can wrap it in a real Observable?

@andywer
Copy link
Contributor Author

andywer commented Sep 29, 2016

@TylorS @SamVerschueren I can understand both your standpoints. I had a quick look and is-observable would indeed work with most.js.

So how about that: We check with the current custom logic and fallback to is-observable or vice versa. If one of both is true we can be almost certain it is an Observable.

PS: I can also open an issue on zen-observable to use the symbol-observable so is-observable will work with the zen-observable as well.

@SamVerschueren
Copy link
Owner

Let's discuss this further in #31

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants