flyd
flyd copied to clipboard
Inconsistent argument order in takeuntil
Given this excerpt from the readme, I assume all flyd
modules should accept the operation data as the last parameter:
More functional in style. Flyd is more functional than existing FRP libraries. Instead of methods it gives you curried functions with arguments in the order suitable for partial application. This gives more expressive power and modularity.
Why does takeuntil
deviate from this paradigm? Is there a specific reason?
To me, takeuntil(endStream, source)
makes more sense.
I can make a pass at a PR for this, just want to find out if it's not an important design decision that I'm missing the point of first.
This bit me today. Should I make a PR?
In fact, as a side note, I found many of the modules listed to be the causes of problems which disappeared once I replaced them with flyd.transduce
and Ramda. Perhaps, either they should be much more scrutinized, or just drops those which have Ramda equivalents.
I agree, this is very surprising behaviour.
I think we need to either
- Flip the argument order
- Document why this is the argument order in the readme for takeuntil
Personally I always import takeuntil like this
import * as takeuntil from 'flyd/module/takeuntil';
const takeUntil = R.flip(takeuntil);