I recently discovered that I can use ES6 default value for parameters to by default use the method that has the proper implementation, and injecting something else when needed. It goes at the end of the list of parameters, so it doesn't need to be provided.
Does anybody see any possible problem with that approach?
Lets say you have this amazing util function that looks up some data in some static/global read only Map and does some calculation that you need in many places in your code base, lets imagine the following signature: function wow(number): Metric.
In some other function foo in a different module I'm doing the following to be able to use it easily, but still be able to pass a mock or stub when I want to unit-test foo without invoking wow.
In TypeScript this could look like this:
import {wow as wowGLobal} from '../../[...]';
function foo(data: PayLoad, wow = wowGlobal) {
const metric = wow(data.x);
[...]
}
To be annoyingly pedantic, createFoo above is not a curried function, because it can't be called like createFoo(wow, data) and like createFoo(wow, data) at the same time, it's a higher order function with aurity of 1
I recently discovered that I can use ES6 default value for parameters to by default use the method that has the proper implementation, and injecting something else when needed. It goes at the end of the list of parameters, so it doesn't need to be provided.
Does anybody see any possible problem with that approach?
Could you provide an example?
Lets say you have this amazing util function that looks up some data in some static/global read only Map and does some calculation that you need in many places in your code base, lets imagine the following signature:
function wow(number): Metric.In some other function
fooin a different module I'm doing the following to be able to use it easily, but still be able to pass a mock or stub when I want to unit-testfoowithout invokingwow.In TypeScript this could look like this:
Is this helpful?
Ah, got it.
I probably would have implemented with a curried function.
in the regular place I'd use
and for testing something different, but I guess your way works too, it's just a bit more implicit.
To be annoyingly pedantic, createFoo above is not a curried function, because it can't be called like createFoo(wow, data) and like createFoo(wow, data) at the same time, it's a higher order function with aurity of 1
I allow it!