All topics
Functionsadvanced

Function Currying and Partial Application

Transforming a multi-argument function into a sequence of single-argument functions, and pre-filling some arguments ahead of time.

Currying is the technique of converting a function that takes multiple arguments into a sequence of functions that each take a single argument, returning a new function until all arguments have been supplied and the original computation finally runs. Partial application is a closely related but distinct idea: fixing some of a function's arguments in advance to produce a new function expecting only the remaining ones. Interviewers bring these up specifically to test comfort with closures and functional composition, since both techniques are built entirely on functions returning functions.

Currying is like a vending machine that only accepts one coin at a time and won't dispense your snack until you've inserted every coin required — each coin insertion (argument) gives you back the same machine, ready for the next coin, until the final one triggers the drop.

Key Concepts

1
A curried version of add(a, b, c) looks like curriedAdd(a)(b)(c), where each call returns a new function that has 'remembered' the arguments supplied so far via closure, until the final call has enough arguments to compute and return the actual result. This is powerful for building specialized functions from general ones: const add5 = curriedAdd(5) creates a reusable function that always adds 5, without rewriting add itself.
add(a, b, c)curriedAdd(a)(b)(c)const add5 = curriedAdd(5)add
2
Partial application is more flexible about how many arguments are fixed at once — you might fix two arguments and leave the rest for later, rather than strictly one-at-a-time as curry implies. In practice, JavaScript's built-in Function.prototype.bind does a simple form of partial application: fn.bind(null, arg1, arg2) returns a new function with arg1 and arg2 pre-filled, waiting for the rest.
Function.prototype.bindfn.bind(null, arg1, arg2)arg1arg2
3
Both patterns show up in functional libraries (Lodash's _.curry, Ramda) and in real code for things like configurable middleware, event handler factories (onClick(elementId)(event)), and building specialized API request functions from a generic one (fetchFrom(baseUrl)(endpoint)). The tradeoff is that heavily curried code can be harder to read for developers unfamiliar with the pattern, so it's typically reserved for utility layers rather than sprinkled throughout application logic.
_.curryonClick(elementId)(event)fetchFrom(baseUrl)(endpoint)