search

0no-co / wonka

🎩 A tiny but capable push & pull stream library for TypeScript and Flow
MIT License
709 stars 29 forks source link

Converting to/from JS Observables #27

Closed rafamel closed 5 years ago

rafamel commented 5 years ago

Hi there! As urql is using wonka now, it would be of great help for those of us who want to tinker with it if there was an easy way to pipe to/from RxJS observables. What would be the best approach here?

rafamel commented 5 years ago

Just as a note, I've been reading up on callbags and I think they're a better fit than Observables/RxJS for one of the libs I'm building. I'd like to use Wonka just because TypeScript but I'm quite uncertain w/ going forwards as it's unclear how or why it differs from the callbag spec.

Also, I didn't dig too deep but judging by some tests I run while replicating the code for interval it looks like sinks need to be called w/ BuckleScript Block.__ which, if true, would render the idea of it all being just functions and the interop with other JS/TS callbags libs/utils not viable? Any input on this regard would be highly appreciated.

kitten commented 5 years ago

it would be of great help for those of us who want to tinker with it if there was an easy way to pipe to/from RxJS observables

Definitely! I had to/from observable and to/from callbag operators planned for a while now, but haven't written them yet. Note though, that I wouldn't actually write the to/from observable operator to be Rx-specific but to just use spec-compliant JS observables, which would then also be compatible to Rx.

I'm quite uncertain w/ going forwards as it's unclear how or why it differs from the callbag spec.

I'm currently writing some more docs and part of that is explaining how it differs from callbags. It essentially takes 100% inspiration from them, but it isn't following the spec in that it doesn't use the same function signatures.

Regarding the BuckleScript block stuff, you shouldn't call sinks directly from JS/TS. They take a special signal, and I may provide some helpers around that in the future that create these events, but for all intents and purposes that's an implementation detail and part of the internals.

If you have more ideas for operators that help with creating new operators "from scratch" let me know though, but the idea is for Wonka to have enough operators so that every missing one can be derived.