disperse, the more I like it! Converge "converges" the arguments with every given transformer, and disperse "disperses" the arguments across all given transformers! :D .. Maybe I'm falling in love, and I should kill my darlings and such.. It's a good name right? :worried:
useWithnecessarily disperse first,
convergedispersing the entirety of
argumentsto all transformers and
useWithdispersing individual arguments to individual transformers. So it's a little unclear from that perspective, I think. It's still better than
useWithto describe the behaviour at least.
useWith's new name would be helpful, considering "spread" is used with similar meaning by Q (and other promise libraries?).
R.spreadsounds like an alias to
R.apply(which is really what it means in Q and such too), so you would have to come up with a function name containing "spread", which might get long.
divergeis not bad, as long as we don't make to much of its connection with
converge. The two words describe well different parts of the operation, and in actuality the way the word 'converge' fits would equally fit
useWithare essentially the same. It comes down to one passes the transforms a single argument of the index of the transform and the other passes it all arguments. So I'm trying to come up with a common name that describes that (tough). I'll keep kicking it around.
Although I recognize that there's an abstraction where
converge are quite similar, my mental models of them are so different that it's hard to think of them as even related, except in that they both offer extensions to the notion of
useWith is all about running transformations on each of the parameters before supplying them to the main function; the focus is clearly on the main function. But
converge is about running a number of functions against the same data, and then at the end, almost incidentally, combining their results; the focus is on the individual transformations.
Of course this is only a matter of perspective, and it's certainly no more or less valid than the notion that @jdalton is proposing based on potentially similar implementations. But it's interesting to realize how different such perspectives can be.
var assign = _.partial(_.modArgs(_.assign, Object), null);
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?
modArgsSetmodifying a set of args. It also shows their close relationship so woot. I don't dig the
Setbut it's short and gets the point across.
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
maxis. The second is a sequence of steps that ends of with
maxhaving the correct value.