The minimalistic but powerful, modular, functional reactive programming library in JavaScript.
I think it's subtly different though
s.let = function(operator) {
return operator(s);
}Sure you could use a transducer as an input to the let. e.g.
s.let(flyd.transduce(compose(
filter(d => d > 4),
map(add(3))
)))or you could just use plain old ramda map
s.let(map(add(3)))The point being, any function that accepts a stream and returns a stream is allowed as a let input
While flyd.transduce accepts a transducer and a stream and returns a stream.
s.ap = function( operator ){
return combine(function([value, fn]){
return fn(value)
}, [s, operator ])
}const selected = available
- .map(find_selected)
+ .let(map(find_selected))let I've been struggling to name this myself
var flatStream = flyd.combine(function(s, own) {
// Our fn stream makes streams
var newS = f(s());
flatEnd(flatEnd() + 1);
internalEnded(newS.end);
// Update self on call -- newS is never handed out so deps don't matter
flyd.on(own, newS);
}, [s]);
flattenPromise excepts a Stream Promise a
const log = message => val => {
console.log(message, val);
return val;
};
const stream$ = flyd.stream(false);
flyd.map(() => {
stream$
.map(log('this prints...'))
.map(log('...but it never reaches here'));
}, flyd.stream(true));flyd.map() away it'll work correctly)
For instance if we further your example.
const log = a => b => (console.log(a), b);
const s1 = stream(true);
const s2 = stream(true);
s2.map(()=> s1.map(log('1')).map(log('2'))
s2(true)(true);What is your expectation of logging here?
1
2
1
2
1
2
Or is it just
1
2
Imagine we add s1(true) to the end of the example
What is your logging expectation then?
Well, this is hard one to explain. I just did a simplistic example to highlight the issues. Let me try:
One example of such use case is when for example we have react-like components working with state in flyd streams (setState updates via stream updates). There comes situations when there's stateful components inserted into DOM after the state stream has already been initiated. While initiating the component - it reads in stream state nicely, but if you try to map the stream into another stream (transform, drop repeats, pick only specific props...) it didn't work properly. paldepind/flyd#177 tries to highlight the issue in a different format, but the underlying issue seems the same.
The recent fix: paldepind/flyd#178 will fix this issue though.