conversion API for dataflows (and drivers)

Wouldn’t it be nice if it was easily possible to write app where you can use components created with different stream libraries in mind?

Scenarios where this can be useful include migrating to another stream library, or evaluating library, or it would just make possible to use shared components written for xstream in rx app and vice versa.

Convention for driver sources this could be like for isolate: A source would provide two helper methods convertSource and convertSink that would take adapter of stream lib which they should to convert to (for source) and from (for sink).

So basically those function for driver sources would do the same thing as dorivers do with runSA (that is passed as second param) while init - convert driver’s native streams to some other streams.

Though the problem is see with non driver sources, there some conventions would be needed too. But basically such sources are either streams or plain object maps with streams.

API could be taken from @TylorS’s https://github.com/TylorS/stream-conversions Maybe covertSource and convertSink should take not adapter, but conversion interface from stream-conversions

API could look like:

import RxComponent './RxComponent'
import convert from '@cycle/convert'

const XsComponent = convert.rx.to.xstream(RxComponent)

// so XsComponent can be used transparently in xstream app

Also RxComponent could have like drivers streamAdapter property that would let converter to know from which lib it should convert the dataflow. And API using adapters could look like:

import RxComponent './RxComponent'
import convertToXs from '@cycle/convert/xstream' // converter to xstream
import rxAdapter from '@cycle/rx-adapter'

const XsComponent = convertToXs(RxComponent, rxAdapter)

// if RxComponent.streamAdapter would be defined:
const XsComponent = convertToXs(RxComponent)

This is kind of raw idea. What do you think?

[wclr]

made a lib for that https://github.com/whitecolor/cycle-convert

[wclr]

@staltz you could ask me to help for example. And those are kind of tasks that should be solidly accomplished once (good API should be finalized) - some time and decent efforts are required for that - this is obvious. But those libs are really small and simple (and this is the sign of good design decision and correct approach) and will serve as foundation and should not require big efforts in future.

As for adapters API - you may consider it to be necessary evil but I consider it as a good part. You still have it and drivers use it (adapters conversions). In this terms conversion API that I was taking about would be just a logical addition to this stuff that is already in place de facto.