DEV Community

Quick Tip: Transform an Array into an Object using .reduce()

Frederik 👨‍💻➡️🌐 Creemers on February 17, 2019

I spare you the time of reading some long boring intro, here's the meat of the article: Let's say you have an array like this: [ {id: 1, ca...

Read full post

Basti Ortiz • Feb 18 '19

Honestly, I really don't like naming the first parameter of the callback function as acc. It's very ambiguous, at least for me. I prefer to name it prev because it's much clearer to me that the prev contains the result of the previous iteration (or the initialized value if it is the first iteration).

Harry Dennen • Feb 19 '19

That makes sense for .map(), but for .reduce() the previous value is also the accumulated value which will eventually be returned. Making that distinction in the naming convention is a nice visual cue imo.

Mihail Malo • Feb 18 '19

That's the imperative name for it though, no?
You're not supposed to know that iteration is taking place, just that the values are being absorbed into the accumulator :v

Basti Ortiz • Feb 18 '19

That is indeed the true and only technical name for it, but semantically speaking, I prefer naming it prev. To each its own, I suppose.

Mihail Malo • Feb 18 '19 • Edited

Yeah, I'm totally just being a smartass.
Many, most even, reducers we write are not commutative.
This one could be parallelizable, actually, if we add a merging function, but still we start with an empty object for acc/prev, not one of the items.

@_bigblind You've seen people write something like

const allStr = strings.reduce((acc, next)=>acc+next, '')
// instead of
const allStr = strings.reduce((acc, next)=>acc+next)

right?

Basti Ortiz • Feb 18 '19

Excuse my lack of knowledge on the subject, but what does it mean for a reducer to be "commutative" and "parallelizable"? And what do you mean by "merging function"?

Jason Rice • Sep 1 '22

This is really inefficient because of the nested spread operator in the reduce function. Here's some more info: prateeksurana.me/blog/why-using-ob...

Frederik 👨‍💻➡️🌐 Creemers • Sep 8 '22

Hey, thanks for your comment, and great post! I had no idea that the spread operator was O(n) in terms of number of properties, though that totally makes sense. I wonder if some JS engines would optimize this code into a mutation if they could somehow make sure that the value before mutation is never accessed, but of course, we shouldn't rely on JS engine optimizations to fix our bad JS habits :).

Mihail Malo • Feb 18 '19

That's a really cool fully immutable solution.
I understand it, but I would personally avoid it in JS, if not for readability by juniors then at least because I have an addiction to micro optimization.

const idsByCategory = posts => {
  const categories = new Map() // I prefer Map
  for (const { category, id } of posts) {
    const existing = categories.get(category)
    if (!existing) categories.set(category, [id])
    else existing.push(id)
  }
  return categories
}


// This is what Prettier does to it
const categoryPosts = posts.reduce(
  (acc, { id, category }) => ({
    ...acc,
    [category]: [...(acc[category] || []), id]
  }),
  {}
)

// Yes, this is short.
const categoryPosts = posts.reduce((acc, { id, category }) => ({...acc, [category]: [...(acc[category] || []), id]}), {})