Why use " = " for an array method?

user_12461861 0
Viewed 85

I have a question about the solution to this problem. It works, but my question is why do I have to write 

stones = stones.slice(0 ,length - 2)

Instead of 

stones.slice(0 ,length - 2)

Like sort() and push work without it.

 var lastStoneWeight = function (stones) {
    stones.sort((a, b) => a - b);
    let length = stones.length
    if(length <= 1) return stones
    let replace = stones[length - 1] - stones[length - 2]
    stones = stones.slice(0 ,length - 2) // <----- HERE
    stones.push(replace)

    if (stones.length > 1) return lastStoneWeight(stones)
    return stones
};

console.log(lastStoneWeight([8,10,4])); //return [2]
arrays javascript
4 Answers

.sort() and .push() are methods that mutate(modify) your array directly.

.slice() on the other hand, is a method that returns a new array, modified based on your parameters, without even touching the initial one.

user_101188320

stones.slice(0, length-2) is simply returning a value, it's not actually modifying the stones variable. Since it gives you a returned value, you need to assign it to something (in this case stones) or pass it into a function.

stones = stones.slice(0, length-2)
some_func(stones)

or 

some_func(stones.slice(0, length-2))
user_47609700

Some functions return a new instance after the action, while leaving the original unchanged. While the other functions change the data "in place", and they don't return an instance.

Examples:

  1. functions that return an instance: replace(), slice()
  2. functions that change data in place and don't return an instance: sort()
user_2668520

Try it, you might like it

As others have pointed out, you're looking at the difference between code that mutates your data and code that doesn't mutate it. I'd suggest trying your best to only work with things that don't mutate it. Code without mutation is usually much easier to understand.

Here's a little story:

Your team has a small system that maintains a queue of work to be done. You have a script that finds the most important unassigned task which matches the skills of the worker asking for a new assignment and assigns it to her. This has been working great, but this year you decide to bring in some interns. While these interns may be wonderful, you have no way of judging their skills. So you decide that when an intern asks for a new assignment, she gets the lowest priority task in the queue, on the assumption that she might clear off some useful work, but won't slow down your overall velocity.

This requires a change to your assignment-handling code, and you assign this... to an intern. (Of course!) This intern sets immediately to work. She sees that there is a function called sortByPriority. Rather than writing her own version that sorts in lowest priority up front, she figures that she can reuse that, adding only tasks.reverse() at the end. (She studied algorithms in college, and knows that sorting a list is O(n log n) whereas reversing should just be O(n), so this seems reasonable.) She writes a few unit tests, and the code that gets them to pass, and in record time, she has completed her first assignment. A harried tech lead looks at the code, watches these tests pass, and immediately deploys it to your internal system.

It's a few days later when you realize that your staff has been hard at work on ... the least important problems! Somehow when an assignment was given to an intern, the next people in line were also getting things off the bottom of your priority list.

What happened? It's simple really. The function sortByPriority updated the actual data in place, using Array.prototype.sort. Whoever coded this originally (and we won't mention Frank by name, ok?) found this simpler than reassigning with tasks = sortByPriority (tasks). You intern just added a reverse onto this code in order to take the lowest priorty task for that intern. Fixing this is easy, but it has cost you three days slippage in getting your next big feature out the door.

How did this happen? (And no, it's not a true story. This didn't happen to any team I've ever seen. Really. And his actual name is not Frank.) It happened because of the junior nature of the intern who changed the code. It happened because this was the tech lead's 17th code review of the day. It happened for numerous reasons.

But none of it would have happened if the original code did not mutate the user data. If instead of directly using Array.prototype.sort it first did a shallow clone of the data (e.g. doing tasks.slice(0).sort(...)) then this would not have been an issue. If the user of the function did not assign the result to where it was useful, it would have been immediately noticed. And the intern would have had a better model to follow for her own code.

You might want to consider writing your own code so as to avoid such problems. That means cloning before sorting or reversing, using concat instead of push, passing an empty object first to Object.assign and/or using rest/spread patterns. Most people I've seen try this very quickly find they prefer it.

It is not a panacea. And it can occasionally lead to performance problems. When they are serious and there is no obvious alternate solution, I will add in some mutation. But I've found that this is very rare in my work.

user_12436410
Related