slice
.
@raine another options is to add another function, one that performs the algorithm, like @00Davo said:
baseAlgorithm = (read, payload) =>
read(payload.type, payload.site)
.then(buildEmailOptions(payload))
.then(transporter.sendMailAsync.bind(transporter));
ioAlgorithm = (payload) =>
baseAlgorithm(readTemplates, payload);
module.exports = {baseAlgorithm, ioAlgorithm};
Then you can test the algorithm with a unit test, and the io version with an integration test.
input is
['apple', 'the', 'one', 'two', 'three', 'elephant', 'whatever']
var filterByLength = R.filter(function(str) {
return str.length > 3 && str.length < 6;
});
desired output is
['apple', 'three']
R.lt(x, y)
means x < y
and curried arguments apply left to right. https://github.com/algesten/fnuc exists mainly because that's Kind of Weird.
fn(a, b) === fn(a)(b)
for Ramda functions. To say its the same except for certain non-commutative operators was problematic. And we probably couldn't just say binary functions, either, or would you expect R.map(fn, list)
but R.map(list)(fn)
? Madness.
gt
and lt
, like I explained. It's not the end of the world, but Ramda's argument order has started to make a lot of sense to me, until I met gt
and lt
just now. :P
R.pipe(R.add, R.map)(10)([1, 2, 3])
lt
, gte
, etc. We had subtractN
, divideBy
, and such, but no good names for these.
R.lt(7, 12)
just seems to me it should return true
and divide(20, 5)
should return 4
not 0.25
. fnuc
was built around trying to solve this issue, but I think it ends up somewhat incoherent.
R.lt(6)
to test if the following value is less than 6. I think I've even used it like that to explain currying to colleagues. :P