In JavaScript, write `compose` and `pipe` helpers that combine several single-argument functions into one. How do they differ, and what constrains the functions you can put in them?

## Both are folds ```js const pipe = (...fns) => (x) => fns.reduce((value, fn) => fn(value), x); const compose = (...fns) => (x) => fns.reduceRight((value, fn) => fn(value), x); ``` Each takes any number of functions and returns a new function. Calling that returned function threads the initial value through the list, handing each function the previous one's result. ```js const trim = (s) => s.trim(); const lower = (s) => s.toLowerCase(); const hyphenate = (s) => s.replaceAll(' ', '-'); const slugify = pipe(trim, lower, hyphenate); slugify(' Hello There '); // "hello-there" const slugify2 = compose(hyphenate, lower, trim); slugify2(' Hello There '); // "hello-there" - same result, reversed argument list ``` ## The only difference is direction `pipe(f, g, h)(x)` evaluates `h(g(f(x)))`. `compose(f, g, h)(x)` evaluates `f(g(h(x)))`. Compose matches how function application is written on paper — the innermost call is on the right — while pipe matches the order you read the code and the order things actually happen. In application code `pipe` almost always wins on readability for exactly that reason; `compose` survives because it is the traditional spelling in functional libraries and because it reads naturally when you think of it as "f after g". A useful way to remember which is which: with `reduce` the list is consumed front to back, so the first function runs first — that is `pipe`. `reduceRight` consumes back to front, so the last function runs first — that is `compose`. ## The unary constraint The fold carries exactly one value between stages. That produces a hard rule: **every function after the first must be unary**, and its parameter type must match what the previous stage returns. If a stage needs two inputs, it cannot sit in the chain as-is — you either bake the extra input in ahead of time by writing a small factory that returns a unary function, or you thread an object through the pipeline and have each stage take and return that object. The first stage can be made variadic with a small tweak: ```js const pipe = (...fns) => (...args) => fns.slice(1).reduce((value, fn) => fn(value), fns[0](...args)); ``` Now `pipe(add, double)(2, 3)` works because `add` receives both arguments; everything after it is still unary. Whether that is worth the extra complexity is a judgment call — the plain version is easier to reason about, and most pipelines start from a single value anyway. ## The failure modes worth naming **A missing `return`.** A stage written as `(user) => { user.name = user.name.trim(); }` returns `undefined`, and every later stage receives `undefined`. The error surfaces at the *next* stage, not at the guilty one, which is why pipeline bugs feel harder to locate than ordinary ones. The habit that prevents it: make every stage a pure transformation that returns its result rather than a mutation that returns nothing. **An async stage.** If one function returns a promise, the next synchronous stage receives a promise object, not the resolved value — `pipe(fetchUser, formatName)` calls `formatName` with a pending promise. Mixing sync and async in a plain pipe is a silent type mismatch. An async pipeline needs its own combinator that awaits each stage. **A throwing stage.** Nothing in the fold catches, so an exception in any stage propagates out of the composed function and the remaining stages never run. That is usually the behaviour you want, but it means the composed function has the union of every stage's failure modes and no place to attach context. **Debuggability.** A composed function has no meaningful name and the stack trace shows the anonymous inner arrow, which makes a long chain harder to debug than the equivalent sequence of named statements. Inserting a `tap` stage — `const tap = (label) => (v) => { console.log(label, v); return v; }` — is the standard trick, and it is itself another small higher-order function. ## When to reach for it Composition pays off when you have several genuinely reusable single-purpose transformations applied in a fixed order, and especially when you want to build the pipeline once and apply it to many values. It does not pay off when the steps need branching, several inputs, or error handling between stages — a plain sequence of named `const` assignments is clearer and debuggable. Being able to say *when not to compose* is as valuable in the interview as writing the one-liner.