FAQ: Iterators - The .reduce() Method

It, like all the iterators, does take a function expression. That is one of the two parameters (second being optional initial value).

    Array.reduce(function (a, b) {
        return a + b   // or other operation with a and b
    })

We are able to abstract the function and replace it with the function’s identifier, as you have above.

callback = (a, b) => a + b;

Array.reduce(callback)

One fails to see how the above arrow function is ‘messy’. In simple scenarios this syntax is much less cluttered given the shortcuts that allowed.

Hi, and thanks for your prompt reply.

I’ll be glad to explain my point about it being messy.

First of all, look at my posted example. The code is formatted and clearly distinct. It also has a name that identifies what the function does. It stands out in readability: the brackets that show the scope of the function.

The fat arrow format wraps the code around in an unformatted appearance. The name of the function is not immediately understood (function functionname pretty much can’t be beat).

I admit I’m not as proficient at JavaScript as I am at Python or Visual Basic so that might be the reason for my reluctance to use the fat arrow approach. What I can tell you right now is if I were to walk away from my example for say two months and then come back to read it again, I’ll get the gist of what I was attempting because it’s clearly modular and self-explanatory in format. That’s not going to happen with the fat arrow approach.

Aside from this, I still want to know why the function expression was flagged as wrong. Is it because the code validation check only allows for a fat arrow solution? I also noticed this in previous lessons where the validation check flagged my solution wrong only because I used a let instead of a const in variable declaration. It would have still worked if let was used. Is this an attempt to force me to adopt the ES6 standard in my coding?

That may be the case, though I cannot say with any certainty. We don’t have a hand in curriculum development, being only volunteers on the forum. We are not CC staff.

One could go into why I like arrow function syntax, but that is not to suggest that function declarations should go the way of the dodo. They have their value, hoisting being part of that. Function expressions are not that far removed form arrow functions since they are both expressions. If the body of the function has multiple lines, they differ even less since very little changes.

 var myFunc = function (param} {
    // code
    return // value
}

 const myFunc = param => {
    // code
    return // value
}

All the difference is in the first line. The function keyword is replaced with the arrow, and single parameters don’t need parens. (None or more than one do need parens.) They both have a variable binding for repeated calls.

Either form above is valid, and for a multiple line body one might suggest the function keyword is more conventional and the slight simplicity isn’t really an advantage.

When working with simple callbacks, I personally like how we can strip away all the superfluous syntax.

[1,2,3,4,5].map(x => x ** 2)  //  [1, 4, 9, 16, 25]

vs.

[1,2,3,4,5].map(function (x) {
    return x ** 2;
})
  • no parens on single parameter
  • no function keyword
  • no curly braces on single line body
  • implicit return of single line expression

They are simple to learn, and one hardly expects to ever forget how they work or what they are if we see them in code.

In Python one might tend toward conventional function definitions vs. lambdas, probably with good reason in many cases. In ES6+, it is harder to explain away the advantages gained by arrow functions.

The above is my own opinion.

Thanks @mtf for all your answers on this topic.

1 Like

I didn’t have any problem with this exercise, pretty straight forward for me BUT!

Again, I’ve commented on this last time… I just don’t understand the connections between the parameters here… How’s the connection with the parameter of “accumulator, currentValue” for the function works?

What I am trying to say is that, how did this function know that we want the named para’ “accumulator” to be the first/starting point of the value and then the named para’ “currentValue” to be the value that it has to add up to??

Unless I’ve missed the point that that’s the way this function works? What ever name you assigned the parameters to, that’s the order that it works with…? But I’m pretty sure that’s not the case… As I can assigned more than 2 parameters right…?

The default value for accumulator (or whatever we name it) is at index 0 of the array and for the currentValue (also by any other name) is at index 1.

When a second parameter is present (for reduce()) then that becomes the accumulator starting value, and the currentValue starts at index 0.

    [1, 2, 3, 4, 5, 6, 7, 8, 9].reduce((a, b) => a + b)
    // 45
    [1, 2, 3, 4, 5, 6, 7, 8, 9].reduce((a, b) => a + b, 10)
    // 55
    [1, 2, 3, 4, 5, 6, 7, 8, 9].reduce((a, b) => a + b, 100)
    // 145

    [2, 3, 4, 5, 6, 7].reduce((a, b) => a * b, 1)
    // 5040

The last is the same a 7! (factorial(7)).

2 Likes

Ah, I see… So it’s to do with the default

Well thank you, that would make a lot of sense! :relaxed: :slightly_smiling_face:

1 Like

is the second parameter in the .reduce() specific to this particular method? I.e. if i put array.reduce((callbackfunction, x) - the x will always only be the initial value for this method?

That is correct.

[1,2,3,4,5,6,7,8,9].reduce((a, b) => a + b, 10)

The value of a to start will be 10, and the value for b will be 1.

1 Like


hello, people
could anyone tell me how could it be?
everything is done but there is no results. only syntax error warning

Line 2 is one possible problem.

right. it is not a question.
a question is how did i cross a lesson while i have a problem in code?
i thought it is impossible

Not following your latest question. Did you fix the syntax error, yet?

Why do we use a comma to concatenate the console.log() commands instead of a plus sign? I tried both and they both work, however the comma seems to add a space automatically. Is that the only reason? It seams that the comma can be used to concatenate strings with other strings as well and this seems like a better way to do it to me than needing to include a space and using the plus sign. Does the plus sign only serve the purpose of increasing readability so that string concatenations don’t appear to be parameters or arguments?

const newNumbers = [1, 3, 5, 7];

const newSum = newNumbers.reduce((accumulator, currentValue) => {

console.log('The value of the accumulator: ', accumulator);

console.log('The value of the currentValue: ', currentValue);

return accumulator + currentValue;

}, 10);

console.log(newSum)

Because the method takes comma separated inputs. There is no string manipulation here.
Just consecutive string output to the display.