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

Add extra operators to Stream #215

Open
wclr opened this issue Aug 20, 2017 · 4 comments
Open

Add extra operators to Stream #215

wclr opened this issue Aug 20, 2017 · 4 comments

Comments

@wclr
Copy link
Contributor

wclr commented Aug 20, 2017

I think it would be useful to have version of xs of ExtraStream type that would have methods like flattenConcurrently, sampleCombine on it defined so they can be used without compose semantics.

It could be imported from import xs, {Stream} from 'xstream/extra'

Or maybe just add those methods on common Stream type, and add them dynamically on Stream prototype when importing xstream/extra/...

@wclr
Copy link
Contributor Author

wclr commented Sep 2, 2017

@staltz what do you think about it?

@xtianjohns
Copy link
Contributor

I think this duplicates #128 a little bit, but in general this sounds like it would be helpful. There were some open questions about TypeScript help when patching, but rxjs seems like they've done this at least in part. I know they do module augmentation with import 'extra/operator';.

@geovanisouza92
Copy link

I was to comment exactly that: https://github.com/ReactiveX/rxjs/blob/master/src/add/operator/buffer.ts

import 'xs/extra/...'; patching prototype seems to be a simple approach from dev experience.

@wclr
Copy link
Contributor Author

wclr commented Sep 22, 2017

I know about #128, but the problem with installing some operators is just with typing. I'm not aware how Typescript could allow having progressively extended class definitions by importing some modules.

So I propose to create a separate class that extends common xstream with all the extra methods seem to me as the only normal solution. ES6 tree shaking is here to solve this so "important" front-end bundle size question, for those who really care (I don't care much).

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

No branches or pull requests

4 participants