Partial Application: Pre-Filling Some of the Arguments
A utility that specializes a function by locking in some of its arguments now and waiting for the rest later, and why it should build on your nearest relative, not the root.
Last time, getOrder and getCurrentOrder were built by hand, each one a small wrapper function written out in full. There's a utility that does that wrapping for you.
The Utility: partial
const getOrder = partial(apiRequest, '/orders');
const getCurrentOrder = partial(getOrder, { id: currentOrderId });partial(fn, ...presetArgs) takes a function and some arguments to lock in now, and hands back a new function that only needs whatever's left:
function partial(fn, ...presetArgs) {
return function (...remainingArgs) {
return fn(...presetArgs, ...remainingArgs);
};
}getOrder is apiRequest with '/orders' already filled in, still expecting payload and callback. getCurrentOrder locks in the order ID on top of that, needing only a callback.
Build the Second Specialization From the First
Notice getCurrentOrder was built from getOrder, not from apiRequest directly. The last post made the case for this: both versions run identically, but only one of them tells the reader that getCurrentOrder is a more specific getOrder, not just a more specific apiRequest.
Calling partial twice, once per level, is what makes that relationship show up in the code itself, instead of only existing in your head.
What Partial Application Actually Buys You
Compare the specialized calls to the raw one:
apiRequest('/orders', { id: currentOrderId }, renderOrder);
getCurrentOrder(renderOrder);Same outcome. The second one asks the reader to track a single argument instead of three, because the other two are already settled and named.
Partial application doesn't reduce what your code does. It reduces what the reader has to hold in their head at any one call site.
The endpoint and the order ID aren't gone, they're just no longer the reader's problem at this particular call site.
The One Thing to Notice About the Shape
partial can lock in one argument or five at once, in a single call. Give it fn and three preset values, and you get back a function waiting for whatever's left, however many that is.
That flexibility is also partial application's whole personality: you decide, call by call, how much to fix now and how much to leave for later. There's a second, stricter way to specialize a function that gives up that flexibility on purpose, and gets something else in return.
Keep reading