Not your ES5’s partial application

You’re probably familiar with JavaScript’s Function.prototype.bind method, which means you've already encountered partial application. You might also be aware of the many libraries that provide partial application through a helper function, like Lodash or spots.

The problem is that bind has limits, since you can only bind arguments in order and there's no concept of 'placeholders'. And libraries — some of which do support placeholders — are runtime constructs that can hinder performance in not-so-insignificant ways. To avoid these issues, you could just use anonymous functions and handle the arguments however you want. But we want to reduce boilerplate, not introduce more.

What if you wanted z to be 2, and not x ? Well that rules out using bind , but you could still use Lodash or an anonymous function:

But we can make it so, so much sweeter. Time for param.macro to shine:

Behind the scenes, this compiles down to plain old anonymous functions like you’d write yourself. This means no excessive runtime overhead and no production dependency, since the param.macro import is removed during compilation.

And, not to be outdone by the lambda parameter macro, placeholders also support arbitrary expressions, including but not limited to nested properties and methods.

But then isn’t it === _ ?

Right about now is the time I should point out two very important differences between the two symbols provided by the plugin, and it all comes down to what they output. The reason there are two separate symbols in the first place is to have clear semantics in all cases.

The first difference is in scoping:

While these look like they might be the same, they’ll come out acting very different:

The _ partial application symbol will always wrap its nearest parent function call, while the it implicit parameter will always be transformed in place.