var assign = _.partial(_.modArgs(_.assign, Object), null);
super neat!
@00Davo
Maybe make the usual source of the promise a default argument, and pass a replacement for it in unit tests.
It currently looks like this,
module.exports = (payload) =>
readTemplates(payload.type, payload.site)
.then(buildEmailOptions(payload))
.then(transporter.sendMailAsync.bind(transporter));readTemplates is the impure one. did you mean that in this case, readTemplates would be passed as an argument to the exported function?
Ya i dig it, looking at the API you already get a hint of what it will be doing
modArgs modifying args, modArgsSet modifying a set of args. It also shows their close relationship so woot. I don't dig the sS bit of modArgsSet or using Set but it's short and gets the point across.
00Davo: interesting approach. i've always kind of thought that changing code to accommodate testing is bad but i'm going to try this approach. the alternative would be to couple tests to private parts of the code, in order for the tests to know which function does the impure stuff
Explaining the hows are easy, whys are though...
The important difference in the example above is that in the FP code I can let
max be const. In the other I have to make it a let. IMO this highlights the key difference between imperative and functional code. The first is a definition of what max is. The second is a sequence of steps that ends of with max having the correct value.
BTW, is this functional enough?
let map = function(f, args) {
let [x, ...xs] = args;
if (x === void 0) {
return [];
} else {
return [f(x)].concat([].slice.call(map(f, xs)));
}
};
if
let [x,...xs] = args is avoided it would be nice...
I'm missing a parentheses after
slice.
@raine @CrossEye Re contracts and Eiffel - that implementation is significantly different from Eiffel's in that it allows contracts for higher order functions - you can specify "this function accepts a function of two arguments that returns a boolean" in the contract. Makes it a huge win for FP, and drastically improves error messages. Eiffel contracts are more "before calling this, state is X, after calling, state is Y"
@jackfirth: I only glanced at the docs, and didn't dig very deep. While I've never bought the notion that the only good FP is strongly typed FP, I certainly have some sympathy for attempts to add stronger typing to JS. After all Ramda's avoidance of overloading and of optional parameters certainly works along those lines. But I'm usually not that intetested in attempts to add real strong typing to JS. I'll have to take another look at this one though.
@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.
But you still have the shortcut function that you care about
If yu don't want to expand the public api, then shove the base algorithm in some internal file somewhere, or move it to an entirely separate module and depend on it.
hey guys, do you have any ideas how can I solve this much more elegant? thanks,Tamas
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']
that's obviously longer, though
