Does anyone find it ironic that solution 2 to Use the reduce Method to Analyze Data mutates data?

In the functional programming section of Data Structure & Algorithms- Use the reduce Method to Analyze Data, solution 2 mutates the state of the accumulator object as it iterates through the movies array.

I’m not sure why that would be ironic? Mutation of the accumulator object is pretty standard in a reduce.

The explanations of functional programming in this section say you are supposed to copy vars, not change them. I guess it seems like there should be a caveat or something. I don’t know, maybe I’m being too knit-picky, it just seems a little contradictory.

The section says that you should avoid side effects. Changing an accumulator variable to … you know… accumulate information, is the purpose of the reduce method. That wouldn’t be a side effect, it would be the primary effect.

Redux doesn’t do that. I think that’s probably the most used reducer in real-world apps. Why not something like this:

    .reduce((obj, rating) => {
      return Object.assign({}, {
        count: obj.count + 1,
        sum: parseFloat(rating) + obj.sum,
    }, {count: 0, sum: 0});

Redux specifically forbids you from modifying a accumulator and requires you to rebuild the accumulator on every single iteration, no matter if it is a large, complex object? That sounds dubious to me. Even if that is true, plenty of other real world languages and applications allow you to do exactly this:

In Rust you have to specify that you are mutating the accumulator, but its perfectly legal. And that’s one of the most restrictive languages you’ll find.

There is nothing wrong with mutating an accumulator unless you’ve fallen prey to the ‘functional orthodoxy over all practical concerns’ disease.

Variables that are outside of scope shouldn’t be changed, but that doesn’t mean that all variables should be constants and never reassigned. reduce doesn’t modify the array it reduces, it produces a new array. It doesn’t put you at risk of changing a value that another piece of logic is using.


That explanation makes sense to me.

I’m glad I could help. Happy coding!

“reducer” is something coined for Redux, it does a similar thing and works in a similar way to the reduce method, hence the name, but it’s not an application of reduce. It’s a bit of a misnomer,

The immutability is required because if a change is requested (via an action) the function has to return a new version of the input (state) , otherwise it needs to return the current state. If it mutated then would always be the same object referenced, so it would be impossible to track changes.

reduce takes a collection of values and “reduces” it to a single value. A “reducer” function takes a collection and returns a new collection of exactly the same shape – it would maybe be more accurate to call it a mutator, but anyway.

JavaScript does not have immutable data structures, so generally what is done with, say, reduce, is to mutate the value the input is being reduced to, then return the new value. So outside the function you get input => brand new value, the mutation only occurs internally. It’s inefficient to do it any other way due to the lack of immutable data structures (which aren’t common outside of languages that require them anyway)


This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.