reduce: many values into one

map gives you a list. filter gives you a shorter list. But plenty of questions have a single answer: what is the total, what is the largest, how many of each kind are there, what does this whole array look like as one string. Those cannot be expressed as a list, and none of the methods so far produce them.

reduce is the general tool for collapsing many values into one. It is the most powerful method in the family and by some distance the hardest to read at first, which is why it comes last. Everything you can do with map or filter, you could do with reduce — that is not a recommendation, it is a warning about how easily it is overused.

The honest framing: learn reduce properly so you recognise it, use it where it is genuinely the clearest option, and reach for a plain for...of loop without embarrassment when it is not.

Think about totalling a receipt by hand. You start at zero. You read the first line and add it to your running total. You read the next line and add that. The running total is carried from one line to the next, and when the lines run out, the running total is the answer.

Two things are moving: the item you are looking at right now, and the running total you are carrying. That carried value is what JavaScript calls the accumulator, and it is the only genuinely new idea in this lesson. Everything else is arranging that idea into syntax.

You write array.reduce(reducer, initialValue). The reducer receives the accumulator first and the current element second — accumulator, current, in that order, every time. What the reducer returns becomes the accumulator for the next call, and the final return value is what reduce hands back.

That last sentence is the whole mechanism, and it is worth reading twice. The reducer does not modify anything; it produces the next value of the carried result. On the first call the accumulator is the initial value you supplied. On the second call it is whatever the first call returned. And so on, until the elements run out.

Like the other methods, the reducer can also take the index and the array as third and fourth arguments. You will rarely want them, and the accumulator being first is the thing to fix in memory — swapping the first two parameters produces code that runs happily and gives nonsense.

The second argument to reduce can be left out, and it changes the behaviour in two ways. Without it, the accumulator starts as the FIRST element of the array and iteration begins at the second, so your reducer is called one fewer time. With it, the accumulator starts as your value and iteration begins at the first element.

For summing numbers both forms give the same answer, so it is tempting to drop it. Do not. Calling reduce on an empty array with no initial value throws a TypeError — there is no first element to start from and nothing to return, so the method refuses rather than inventing an answer. An initial value of 0 makes the empty case return 0 without a special branch. (The exact wording of that error differs between JavaScript engines, so match on the error type rather than its message.)

There is a second reason, which matters more once your accumulator is not a number. The initial value is what declares the SHAPE of the result: {} for an object, [] for an array, 0 for a count, "" for a string. Someone reading reduce((counts, item) => ..., {}) knows what is being built before they read the reducer at all.

The accumulator does not have to be a number. Start with {} and you can build a tally: for each item, add one to the count stored under its category. Start with [] and you can build an array, though if the result is one output per input you wanted map. Start with "" and you can build a string, though join is usually better.

The tally is the case where reduce genuinely earns its place, because there is no other method that does it. The pattern is always the same: read the current value out of the accumulator, work out the new value, write it back, and return the accumulator.

That write-back mutates the accumulator object rather than creating a new one each time, which is a deliberate and normal choice here — the object was created by your initial value and nothing outside the reduce can see it until the reduce finishes. Creating a fresh copy on every element instead is possible and much slower, and the data-modelling module returns to that trade-off.

This is the reduce bug, and everyone writes it. If your reducer has a braced body and does not return the accumulator, the next call receives undefined, and the final answer is undefined. Nothing throws; you just get nothing.

It bites hardest with the tally pattern, because the interesting line — counts[key] = counts[key] + 1 — looks like the whole job, and the return counts underneath it looks like ceremony. It is not ceremony. It is the only thing that carries your work forward.

The rule of thumb: every path through a reducer must end in a return, including any early exits inside an if. If you see undefined coming out of a reduce, look for the missing return before you look anywhere else.

reduce is worth reaching for when the operation genuinely is 'combine these into one value' and the reducer is a short expression — sums, products, maximums, tallies, flattening. In those cases it states the intent in one line and there is no loop machinery to misread.

A for...of loop is the better answer when the body is long, when several different things are being accumulated at once, when you need to stop early, or when the reducer would need conditionals inside conditionals. A reduce with a ten-line body and three ifs is not clever, it is a loop wearing a costume — and it is harder to step through in a debugger, because the body is a function call rather than a block.

Experienced developers disagree about where the line sits, and that is fine. What is not fine is choosing reduce because it looks advanced. Pick the version a tired colleague could read at five o'clock.

reduce carries an accumulator from one call to the next: the reducer takes (accumulator, current) and returns the next accumulator, and the last one returned is the answer. Always pass an initial value — it fixes the empty-array TypeError and it announces the shape of the result. Every path through the reducer must return the accumulator. Use it for genuine combining, and use a for...of loop when the body grows.