DEV Community

Array.reduce() is Goated 🐐✨

Matt Lewandowski on May 14, 2024

The title says it all 🐐. I want to talk about my all-time favorite javascript array method: Array.reduce(). I know there are a lot of contenders ou...

Read full post

lionel-rowe • May 15

Counterpoint from Google's Jake Archibald:

All code using array.reduce should be rewritten without array.reduce so it's readable by humans mutes thread
— Jake Archibald @jaffathecake

Along with the follow-up YouTube video: Is reduce() bad? - HTTP 203

Ratchet • May 16

So can map, forEach, flat, sort, it's non-argument. Everything is readable to human and is a preference. Reduce is a functional construct that exist in all functional languages and is pulled into most imperative languages too. JS should add reduceLeft.

Stephen Fairbanks • May 15

I'm with Jake. I'd only use Reduce to reduce a list of number to a single value.

lucas-ayabe • Jul 31

Except reduce is way more readable if you use it along with functional style code, and think in the computations with a immutable way is easier, once you know both approachs.

I guess that traditional loops are only more readable if you prefer an imperative style of programming or really like procedural paradigm.

Bob Gulian • May 15

Reduce Scrooge

Bob Bass • May 15

Reduce is cool but it's not readable or intuitive which slows down development with teams.

When I see someone at work use reduce, they're usually being clever. I don't like clever when there was a simple option.

I'd almost always prefer to see .filter, .map, or just a good old fashioned for/in or for/of loop with relative mutable variables or arrays/objects defined above it.

Reduce is great, but it gets a 0 for readability and a 0 for simplicity in my book.

Ghimmy • May 17

Simple is boring atimes... If you name your functions well/add the write comment then it's not a problem.
The only argument you can bring against using reduce is performance...

Bob Bass • May 17

Respectfully... I'm so glad we don't work together if you're argument is "simplicity is boring".

Also, reduce is never actually used in a readable way. Everyone wants to claim to use best practices but in the wild it's always

acc: any ..., {}

Or something like that.

So you've got poor performance, bad patterns encouraged, and it only takes five times longer to grok.

lucas-ayabe • Jul 31

reduce actually is the solution when your array methods are slow, because chain map, filter, etc causes more cycles through the array, so you can do all at the same time with a reduce, as any array traversing operation can be expressed by a reduce.

Its called transducers, and a transducer is a really elegant way to express composed array operations.

If you like a imperative style of programming, and/or mainly the procedural paradigm, sure, reduce never will be the more readable solution, but if you program in a declarative way, composing computations, reduce will be more readable than any imperative loop, as you can forget the array, think only in a function that maps one state to the next state, and that will work in the reduce.

Samuel Rouse • May 14

Nice article with great examples!

I especially appreciate the Performance Considerations section, as the creation of object on every loop adds up quickly. Comparing a mutating reducer and a new-object-per-loop reducer, by 1000 entries a "bad" reducer will run for almost ~70 ms, while the object mutation reducer is under 1 ms. With 2000 entries that balloons to ~300 ms while the mutation is still 1 ms!

Matt Lewandowski • May 14

Thank you!

I'm glad you appreciate that. I've definitely come across this mistake in production applications, where it made a huge difference in render speeds. ~70ms times a few re-renders can be massive.

xtofl • May 22

reduce was never intended to cause side-effects (i.e. pushing something onto an array you're not certain is owned by you alone). Yet, mutating the accumulator is the only solution to the performance caveat.

Interestingly, functional programming flavored C++ counters the same problem by using something called 'linear types': data types that support 'growing' into new versions of themselves.

I heard it first at meetingcpp.com/mcpp/slides/2018/li...

Vildan • May 14

For flattening js has flat array method, for unique values set, for map, of course map. s So reduce is one of tools to write your code but not the only one

Matt Lewandowski • May 14

Yes, this is outlined in the article. It's just another tool that is useful to understand. There will be use cases where it makes more sense to use reduce, and it's important to be able to understand why someone might be using it in a code review.

Cefn Hoile • May 16 • Edited

The commentary suggests you would need .reduce(...) if you wanted to transform along the way, but more intuitive for that would be .flatMap()

dx0x58 • May 15

Hi, thanks for the article!
I want to make a small addition to a case with unique values in an array.
The time complexity for the specified option will be O(n^2)

const numbers: number[] = [1, 2, 3, 2, 4, 3, 5, 1, 6];

const uniqueNumbers: number[] = numbers.reduce((acc, curr) => {
  if (!acc.includes(curr)) {
    acc.push(curr);
  }
  return acc;
}, []);

Because there are two nested array iterations here: .reduce and .include
Which will be very ineffective on large input data.

this can be done in O(n) time using Set:

const numbers = [1, 2, 3, 2, 4, 3, 5, 1, 6];
const uniqueNumbers = [...new Set(numbers)];

lucas-ayabe • Jul 31

This is true, but not if you need to deal with non-primitive data like literal objects for example.

Michael Casile • May 14

Great article. Small and well done salesmanship without taking 40% of the article with WHY it's good. Great examples. I've got code where I brute-forced thru some of this ... looking to find the time to do it more elegantly w/reduce.

Marcel Christianis • May 14

The redux example is mindblowing!

Gave me a whole new perspective on reducers.

Matt Lewandowski • May 14

I'm glad you appreciated that! I was back and forth on whether or not I should include it, since it's pretty bulky. I really wanted to tie it to redux and also useReducer in React. They become a lot simpler when you understand the core concept.

If you ever build a old-school js game, like chess, and want the application history like redux provides, you can easily achieve like this.

Dmytro Shchehlov • May 17 • Edited

@mattlewandowski93
despite Redux uses reducers, array.reduce doesn't implement the Redux store, more than there is no array.reduce in redux dispatch. Even combineReducers doesn't use array.reduce.

But, array.reduce is a good candidate to build the reducing decorator that can handle the batch of actions:

type ActionBatch = { type: string, actions: UnknownAction[] };

const isActionBatch =
  (action: UnknownAction, batchActionType: string): action is ActionBatch =>
    action.type === batchActionType && Array.isArray(action.actions)

const batching = 
  (batchActionType: string) =>
  <S, >(reducer: Reducer<S>): Reducer<S> =>
  (state: S | undefined, action: UnknownAction) =>
    isActionBatch(action, batchActionType)
      ? action.actions.reduce(reducer, state as S)
      : reducer(state, action);

const batch =
  (type: string) =>
  (...actions: UnknownAction[]): ActionBatch => ({ type, actions });

Such approach allows to avoid multiple dispatching (i.e. rendering) and keep initial reducer simple.

The full example here: TS Playground

Marcel Christianis • May 15

Thanks for writing this!

I've now realized I've been taking the reducer in redux & useReducer for granted.

It's really refreshing to understand the fundamentals of the abstraction that I use daily.

Dmytro Shchehlov • May 17

@marcelc63

Why do you think Redux reducers are named "reducers"? :)))
The concept of Redux is a reducing of actions flow to the current (or final) state.

Caleb O. • May 15

Great article!

if (!acc[curr.age]) {
    acc[curr.age] = [];
  }
  acc[curr.age].push(curr);
  return acc;

This snippet above could've been shortened to this BTW.

acc[key] = acc[key] || []
acc[key].push(curr)
return acc

harjot singh • May 16 • Edited

can be further shortened to :

return (acc[curr.age] ??= []).push(curr), acc;

Caleb O. • May 16

Haha! The nullish coalescing assignment!

Vaviloff • May 28

You should check out Perl, haha.

Ripaz • May 16

Most of these can be written with for...of/forEach, which will also reduce cognitive complexity it introduces.

const productMap: Record<Product['id'], Product> = {};
products.forEach((product) => product[product.id] = product);

// Or using `Object.fromEntries`
const productMap = Object.fromEntries(
  products.map((product) => [product.id, product])
);

Also, the easy way to check if you should use reduce or regular for loop is to ask one question: will the reduce work the same with and without default value. If yes, then use reduce, otherwise for loop is better choice.

E.g. from examples, this will only work if the default value is empty object

const productMap: { [key: number]: Product } = products.reduce((acc, curr) => {
  acc[curr.id] = curr;
  return acc;
}, {});

lucas-ayabe • Jul 31

Well, any array operation that can be expressed by a forEach can be expressed by a reduce, because they abstract almost the same thing. Reduce, or fold, is the abstraction for stateful computations in a world where you can only do stateless computation, so if you ever need to express an forEach in a immutable way, you can do by using a reduce, and if you need to express a reduce in a mutable way you can use a for loop or forEach.

To be fair, at this point, you don't need any array method, as all of them could be expresed as some simple algorithm using for loops.

Its a matter if you prefer imperative or declarative style of programming, and if you really need to optimize for performance or a more elegant code is needed.

Ripaz • Nov 16 • Edited

I agree with all what you said, as I have missed to point out why I the forEach/for is better in this case.

The examples in this post are not presenting or using reduce/fold as it was intended, with immutability in mind. For example, if we take into account the function from post

const productMap: { [key: number]: Product } = products.reduce((acc, curr) => {
  acc[curr.id] = curr;
  return acc;
}, {});

It introduces the mutation into the mix, therefore the usage of reduce here is redundant and we have not benefit from it, as we are just passing around the reference of an object. Imagine if we passed default accumulator value for reduce as an variable that we defined previously before using reduce, then effectively, both that variable and reduce's return would be the same object (pointer).

If we created a new object that would not mutate previous one, each time we iterate over the item, then that would be a proper use case of an reduce/fold.

products.reduce((acc, curr) => ({ ...acc, [curr.id]: curr }), {});

Note: there are times where you will need to mutate an value because of performance, but in languages (like JS/TS in this example) where I have a option to use other methods that improve readability; I would rather go with the forEach/for than reduce/fold.

David Ferguson • May 14

Don’t get me wrong, I like a good reduce function, but let’s not pretend that the stuff you’re showing off as examples are all easily doable with some of the other array methods, especially a forEach. The primary difference is that with a forEach you have to initialize your state (counter vars and such) outside of the function so that they persist through each iteration of the loop.

I don’t know that I’d use example #8. That’s more easily done with a Set.

Matt Lewandowski • May 14

Hey @jdfwarrior_99, I am not pretending anything. I am simply showing use cases for the reduce method. There are always going to be many ways to approach any problem. All array methods are like forEach. They're just loops. Having the block scoped variable allows you to easily chain methods.

It can be done with Set, however, it could be beneficial to do it with reduce if you wanted to use the unique variable in the interaction. With Set, you would have to create the set first, then do another iteration of the data to use it. In applications where performance is critical, these things can make a big difference.

ivan-sapeha • May 15 • Edited

If we're talking about performance, using for loop always will be faster than any of the array methods

Harris Miller • May 15

Understanding how to do that with reduce is important to knowing how to expand in the idea of unique. Consider a uniqBy function. You can just "use a Set" for that

Vincent Huss • May 16 • Edited

@mattlewandowski93
Beware though, your approach in example 8 has a quadratic complexity, it will scale very badly performance wise. (It's a loop within a loop). Unless I'm sure I have no more than 10 elements in my array, I would definitely use a Set or a hash map (independently of using reduce or not)

Mitchell Mutandah • May 14

The Redux example is another level! I'm going to try it out ASAP 😎

Wheval • May 14

Okay, now i have to write about my goat method😁

Rasmus Schultz • May 15

Several of these examples aren't even reducing anything - you're just doing mutations and returning the same object over and over.

Your code is now slower and unnecessarily convoluted, to the point that you don't even realize when you're just doing an obfuscated .forEach.

Reduce operations are necessary in pure functional programming languages because you don't have mutations - in JavaScript, they're an exercise in futility.

Morgan Ney • May 15 • Edited

I’m skeptical of people who overuse reduce. They tend to be more enamored with overcoming their own difficulties with it, than its usefulness. It often produces hard to read code and is used where there are better alternatives.

~~All code using array.reduce should be rewritten without array.reduce so it's readable by humans mutes thread.~~

Another comment beat me too it ☝️

Cefn Hoile • May 16

Simple rule. If you return the same reference as the accumulator every time, don't use .reduce(...)

Too many of these examples violate that rule and would therefore be simpler, more performant and more readable as a loop.

Josh Olson • May 16 • Edited

Yeah, no thanks. Reduce sucks compared to a simple loop or a method with a more intuitive name. We want the sum? Let's call it sum. We want to sum by something nested? How about a map and then a sum? Or a sumBy?

All of your other examples are terrible. Sorry, I'm not sugar-coating it. This was clickbait garbage.

Linus Fernandes • May 17

#!/usr/bin/env ts-node
/* eslint-disable @typescript-eslint/no-explicit-any */
const numbers: number[] = [ 1, 2, 3, 4, 5 ];
const sum: number = numbers.reduce((acc, curr) => acc + curr, 0);
// Output: 15
console.log(sum);

const nestedArray: number[][] = [ [ 1, 2 ], [ 3, 4 ], [ 5, 6 ] ];
const flattenedArray: number[] =
    nestedArray.reduce((acc, curr) => acc.concat(curr), []);
// Output: [1, 2, 3, 4, 5, 6]
console.log(flattenedArray);

interface Person {
  name: string;
  age: number;
}

const people: Person[] = [
  {name : "Alice", age : 25}, {name : "Bob", age : 30},
  {name : "Charlie", age : 25}, {name : "Dave", age : 30}
];

type GroupedByAge = Record<number, Person[]>;

const groupedByAge: GroupedByAge = people.reduce((acc, curr) => {
  if (!acc[curr.age]) {
    acc[curr.age] = [];
  }
  acc[curr.age].push(curr);
  return acc;
}, {} as GroupedByAge);

/*
Output:
{
  '25': [{ name: 'Alice', age: 25 }, { name: 'Charlie', age: 25 }],
  '30': [{ name: 'Bob', age: 30 }, { name: 'Dave', age: 30 }]
}
*/
console.log(groupedByAge);

interface Product {
  id: number;
  name: string;
  price: number;
}

const products: Product[] = [
  {id : 1, name : "Laptop", price : 999},
  {id : 2, name : "Phone", price : 699},
  {id : 3, name : "Tablet", price : 499},
];

type ProductMap = Record<number, Product>;
const productMap: ProductMap = products.reduce((acc, curr) => {
  acc[curr.id] = curr;
  return acc;
}, {} as ProductMap);

/*
Output:
{
  '1': { id: 1, name: 'Laptop', price: 999 },
  '2': { id: 2, name: 'Phone', price: 699 },
  '3': { id: 3, name: 'Tablet', price: 499 }
}
*/
console.log(productMap);

// Accessing a product by ID
const laptop: Product = productMap[1];
// Output: { id: 1, name: 'Laptop', price: 999 }
console.log(laptop);

const fruits: string[] =
    [ "apple", "banana", "apple", "orange", "banana", "apple" ];

type FruitCount = Record<string, number>;
const fruitCounts: FruitCount = fruits.reduce((acc, curr) => {
  acc[curr] = (acc[curr] || 0) + 1;
  return acc;
}, {} as FruitCount);

/*
Output:
{
  'apple': 3,
  'banana': 2,
  'orange': 1
}
*/
console.log(fruitCounts);

type MathFn = (_x: number) => number;
const add5: MathFn = (x) => x + 5;
const multiply3: MathFn = (x) => x * 3;
const subtract2: MathFn = (x) => x - 2;

const composedFunctions: (MathFn)[] = [ add5, multiply3, subtract2 ];

const result: number = composedFunctions.reduce((acc, curr) => curr(acc), 10);
// Output: 43
console.log(result);

interface State {
  count: number;
  todos: string[];
}

interface Action {
  type: string;
  payload?: any;
}

const initialState: State = {
  count : 0,
  todos : [] as string[],
};

const actions: Action[] = [
  {type : "INCREMENT_COUNT"},
  {type : "ADD_TODO", payload : "Learn Array.reduce()"},
  {type : "INCREMENT_COUNT"},
  {type : "ADD_TODO", payload : "Master TypeScript"},
];

const reducer = (state: State, action: Action): State => {
  switch (action.type) {
  case "INCREMENT_COUNT":
    return {...state, count : state.count + 1};
  case "ADD_TODO":
    return {...state, todos : [...state.todos, action.payload ]};
  default:
    return state;
  }
};

const finalState: State = actions.reduce(reducer, initialState);
/*
Output:
{
  count: 2,
  todos: ['Learn Array.reduce()', 'Master TypeScript']
}
*/
console.log(finalState);

const nums: number[] = [ 1, 2, 3, 2, 4, 3, 5, 1, 6 ];

const uniqueNumbers: number[] = nums.reduce((acc, curr) => {
  if (!acc.includes(curr)) {
    acc.push(curr);
  }
  return acc;
}, [] as number[]);

// Output: [1, 2, 3, 4, 5, 6]
console.log(uniqueNumbers);

const grades: number[] = [ 85, 90, 92, 88, 95 ];

const average: number = grades.reduce((acc, curr, index, array) => {
  acc += curr;
  if (index === array.length - 1) {
    return acc / array.length;
  }
  return acc;
}, 0);

// Output: 90
console.log(average);

Updated the examples since some examples were throwing typescript errors.

Moray Macdonald • May 23

Great article! Ignore the reduce haters, it's an incredibly useful function and any JS developer at mid level or above should be able to understand it. I'd recommend that you don't use acc and cur as your variable names in future though, give them more descriptive names to make it easier for people who haven't read this article to understand what's going on.

On the subject of incredibly useful JS features, I'd update example 4 to use a Map instead of an regular object. It's a really useful data structure designed for EXACTLY this purpose, and the way Map.set works means that you can do the whole thing in one line:

interface Product {
  id: number;
  name: string;
  price: number;
}

const products: Product[] = [
  { id: 1, name: 'Laptop', price: 999 },
  { id: 2, name: 'Phone', price: 699 },
  { id: 3, name: 'Tablet', price: 499 },
];

const productMap = products.reduce(
  (map, p) => map.set(p.id, p),
  new Map<number, Product>(),
);

(OK I lied, it's clearer on multiple lines on such a narrow comment box!)

Finally, when you're using Typescript you should know that reduce can take a type argument, so you can make things neater by writing

const result = arr.reduce<string[]>((a, c) => {...}, [])

instead of

const result = arr.reduce((a, c) => {...}, [] as string[])

const result: string[] = arr.reduce((a, c) => {...}, [])

It doesn't exactly save characters, but it makes things much more readable, and (I think?) slightly easier for the compiler to understand.

Pierre-Henry Soria ✨ • May 15

Outstanding read Matt! 🐐 From flattening nested arrays into a single one till the average calculation, your examples are great. I like the Use Case 7, using reduce() to implement a very simple state management (although, limited of course). But no libraries required with reduce()! 🚀

Boris • Jul 22

Saved this article in my reading list and today I was very glad about it, because I remembered the lookup map. Came back, read it again and solved my problem immediately without constructing some kind of weird for loop.

Miri Yehezkel • May 15

Interesting article, gives a good amount of examples on how reduce is coded.
Some things didn't sit well, such as finding unique values - the reduce would basically loop over the array every iteration rather than using a set?

What I gather from it is, here are ways to use reduce, and here are example of how you might misuse reduces. Really interesting article!

Vincent Huss • May 16 • Edited

I'm shared,
One counter argument I have against reduce is that it's a constrained version of what a classic loop let you do (the loop that is implemented within the reduce function). Why use a constrained and less universal way of doing something ?

Edit : that might be controversial but I actually don't think it's a good thing when a language has (or encourages) multiple ways of doing one thing. Having developers aligned on one similar way of doing something is what speed up efficiency in a big team.

Another note on performance (although it might be negligeable I'm not sure) is that you have the function call overhead at each iteration.

Last one, in favour of reduce this time, it encourages to scope the intermediate variables inside the callback function, leaving only the main array variable visible in the main scope.

lucas-ayabe • Jul 31

If you think this way, you'll never use any abstraction, more universal things are good to be building blocks as this makes them more composable, but to do the actual work and make easier to reason and think about our code, we need to abstract things to loose the cognitive load of our brains.

This counter argument could be used for any array method, as all of them are abstractions for 20 ~ 30 max LoC algorithms. Why would you use an filter method if you can just use a for with a if inside? Its the same logic.

Any time you use an for loop in an array thats not for just traversing it (like to show item by item of the array), what you're doing is an array operation, and all array operations can be expressed by an reduce, so i can flip the your argument, and ask why would i ever prefer an imperative loop instead of a concat operation inside a reduce without the boilerplate?

All the times you make something like this:

let sum = 0;

for (x of numbers) {
  sum += x;
}

or in a more abstract way:

let accumulator;

for (const item of array) {
  accumulator = join(accumulator, item);
}

In other words, an stateful operation while traversing the array, and they occour a lot, you always will need to repeat the same boilerplate code, so in these cases you can replace all the boilerplate by a reduce, as you only need to think about the concat logic of a type. Once you think the reduce as a concat of all the items of an array, it becomes much more readable than any for loop for the same logic, ex:

const add = (x, y) => x + y;
xs.reduce(add, 0);

// or

xs.reduce((x, y) => x + y, 0);

I like 2 articles that sold the concept for me, and I hope they are of use to you too:
web.archive.org/web/20220325111509...

web.archive.org/web/20220325111821...

Roch Deschaseaux • May 16 • Edited

Use case 6 composing fonction would be better if it created a new reusable fonction :
const add5 = (x: number): number => x + 5;
const multiply3 = (x: number): number => x * 3;
const subtract2 = (x: number): number => x - 2;

const functions: ((x: number) => number)[] = [add5, multiply3, subtract2];

const composedFunction = functions.reduce((acc, curr) => input => curr(acc(input)));

const result = composedFunction(10);
console.log(result); // Output: 43

Bob Gulian • May 15

Good article. I’m a huge fan of reduce, use it everywhere. The ‘redux’ example is clever but not real world, in my opinion. RTK really puts it together in a performant way.

I also think reduce is just fun. I love figuring out how to solve new problems with it and the payoff…if you use it correct it is pure functional, input an array and get a brand new …. Something!

Juan Lopez • May 15

In c# there's an aggregate extension for IEnumerables, ie arrays. Years ago, it dawned on me that if I have an array of delegates and you can use a state with error checking feature you can create another aggregate extension method to check for the error across all of the delegates. If one fails you stop the iteration and fail early keep the error state and return back to caller that state. All of the if statements collapse beautifully!

Wilson • May 17

Using reduce with objects is inefficient. Use with non-object arrays.

Davod01 • May 17

i loved your example

GP • May 15

Great examples and Thank you for sharing!

Shrijal Acharya • May 15

Love it. 👌

Giovani Fouz • May 17

Great controversy has aroused from this matter. But it is good to learning.

Ana Carolina • May 17

That really blew my mind, my favorite case was the third one because I'm always doing this at my job and I loved the way to do it with reduce, it's so much better! Thank you for the tips

Eckehard • May 17

We are so happy you did not fall in love with any of the other methods of Javascript.

João Angelo • May 16

Hi Matt Lewandowski
Your tips are very useful
Thanks for sharing

Syed • May 22

I liked the idea of using Reduce for these use cases, however, there's always case for right too for the right job. It's up to developer to decide what's important atm.