Closed erykpiast closed 8 years ago
Good concerns. I don't think it'd be too terrible, but it doesn't have to be that way. It'd be possible just to collapse each of the 7 functions into a single file per stream library, resulting in just 7 files. It just needs to be imported and exported accordingly. I don't think this is 'intelligent' per se, but the functions required are quite simple so I don't think it should be much of an issue.
If you meant that from the other side of things, I made sure to use ES2015 modules to make sure tree-shaking can occur using things like rollup
.
I just try to find some solution to avoid creating n^2
functions for n
libraries, no matter if each one is in separated file or not. It's just interesting problem to solve :)
I'm actually thinking of modifying it slightly because of how I envision it being used with Cycle.
From convert.library.toLibrary
to convert.library.to.library
import * as convert from 'stream-conversion')
function callDrivers(drivers, sinkProxies, streamLibrary) {
return Object.keys(drivers).reduce((sources, driverName) => {
const driver = drivers[driverName]
const conversionFn = convert[driver.type].to[streamLibrary]
sources[driverName] = driver(sinkProxies[driverName], conversionFn, driverName)
return sources
}, {})
}
If you (or anyone else) have better thoughts on how this could be accomplished I'm all ears though. It's still early so the API will and probably should fluctuate a little bit.
@erykpiast I switched to using a set of interfaces which I think is what you were hinting towards. It should be significantly easier to maintain in the future. Tests are sort of generated now as well. Also added support for Bacon.js and Kefir.js.
All of this with v0.2.0
Nice! :+1: n*2
functions and its still pretty readable. I was thinking about some generalization of stream API in order to make this code clear, your approach seems perfect.
So, I've created this issue mostly to rise a discussion, I think outcome is valuable. Feel free to close it if you wish :)
Thanks, I think it pushed me in the right direction! :+1:
Feel free to reopen if you feel there is more to discuss on this topic.
I'm just curious, how do you plan extend this utility to support, lets say, next 5 libraries? As far as I see Implementation follows API design very tight (which is OK at this point), but for 7 libraries it will results with 49 files... It may be an issue. Or may be not, what do you think? Do you have any smart, sophisticated solution under your jacket?