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.

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.

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()

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.

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)];

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.

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 😎

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.

Wheval • May 14

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

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 ☝️

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;
}, {});

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.

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.

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.

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.

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.

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!

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()! 🚀

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

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.

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.

Victor Chigbo • May 15

Wow
I never knew about this.
Thank you @mattlewandowski93

Conor Kennedy • May 15

Well done

GP • May 15

Great examples and Thank you for sharing!

Shrijal Acharya • May 15

Love it. 👌

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.

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