DEV Community

Cover image for The Most POWERFUL [JavaScript] Function

The Most POWERFUL [JavaScript] Function

Clean Code Studio on July 28, 2021

Clean Code StudioFollow Clean Code Clean Life ~ Simplify Did you know I have a...
Read full post
Collapse
 
insidewhy profile image
insidewhy • • Edited

For the join case, you can do it much more simply since if you omit the first value, then the first entry in the array is used (reduce is even more powerful than you realise 😛). For some you don't need the ternary or ===, you can just use condition || ....

Collapse
 
cleancodestudio profile image
Clean Code Studio •

Hey @insidewhy , thanks for taking the time to drop your coding tips for reduce. Can you show me a quick coding example of what you mean by omitting the first value and automatically using the first entry in the array?

I'm familiar with using || instead of the ternary operator. I usually opt for the ternary operator because it provides better debugging support by default when errors arise.

That first tip you dropped sounds interesting though, I'd love to see an example of what you're specifically referring to!

Collapse
 
val_baca profile image
Valentin Baca • • Edited

You can just do:

['truck', 'car', 'people'].reduce((text, word) => `${text}-${word}`)

> "truck-car-people"
Enter fullscreen mode Exit fullscreen mode

If no initial variable is given (your first example had '') then it just pulls from the input, in this case, 'truck'

You (obviously) need an initial value if the array is empty or you get a very descriptive error:

[3, 2.1, 5, 8].reduce((total, number) => total + number, 0)
> 18.1

[3, 2.1, 5, 8].reduce((total, number) => total + number)
> 18.1

[].reduce((total, number) => total + number, 0)
> 0

[].reduce((total, number) => total + number)
> VM158:1 Uncaught TypeError: Reduce of empty array with no initial value
Enter fullscreen mode Exit fullscreen mode
Collapse
 
insidewhy profile image
insidewhy • • Edited

I usually opt for the ternary operator because it provides better debugging support by default when errors arise.

What debugger are you using? I've never seen this. You always prefer ternary over logical operators because of your debugger? I'm a little scared now. If you're willing to accept code verbosity because of this belief then I hope you're not mistaken.

In situations where one side of the operator is a boolean, I don't see how there can be any ambiguity.

Thread Thread
 
cleancodestudio profile image
Clean Code Studio •

Hey insidewhy, I went back and tried to replicate the situation that inspired me to begin using the ternary instead of or.

I wasn't able to replicate it, so I'm thinking it may have been something to do with how ternary/or operators work within the scope of a reactive front-end framework, or how ternary/or operators work on undefined objects (Ex: person.address.street_t - if address doesn't exist), or javascript has simply been updated to correct the issue.

I appreciate you bringing this up in the comments though, I'm headed off for the day - but once I get back on I'm going to try to see if I'm missing something.

If I find something I'll let you know and if I don't then I owe you a big thanks because your boy is about to be using or operators instead of ternaries again :)

Here's to not finding whatever had me spooked when it comes to the or operator

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀 •

Clearly math.pow is the most powerful function haha, okay il read it now

Collapse
 
cleancodestudio profile image
Clean Code Studio •

Literally lol'd at this one 😁

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀 •

Exponentially? 😆 Sorry, I'll stop now

Collapse
 
siddharthshyniben profile image
Siddharth •

You really shouldn't use Array.reduce

Collapse
 
cleancodestudio profile image
Clean Code Studio •

A "4 Reasons to avoid using Array.reduce" blog post - nope! Not happening, not while I've got air in my lungs and life in my limbs.

I owe you Siddharth, I'm headed in right now to wage war in the comments section to rise up against the mis-guided non-sense that such an article would have you believe.

Catch you on the flip side, me and my overly opinionated beliefs are about to post up and make an impassioned comment responding to such non-sense.

Reduce is the most powerful and absolutely amazing mother f***** function on the planet, this is my stance, I've chosen my hill - I'm willing to die on it.

Collapse
 
siddharthshyniben profile image
Siddharth •

Not saying that reduce is bad – It's just harder to read. When I was a newbie, it took me a day to understand what it did. That's why I said not to use it. If you care about others being able to read your code, then you should use it less.

Thread Thread
 
cleancodestudio profile image
Clean Code Studio •

Okkkay, was that your article post that I commented on @siddharth ? Were you the actual author of the post? If so, I hadn't put two and two together.

I absolutely get where you're coming from from a professional stand point. I'm sharing my highly opinionated view point in a very strong way just to have some fun with it and push reduce forward a bit because I think it gets a bad wrap for readability when my take is that it has less to do with readability and more to do with capability of developers using it.

In a real project you should always take into account your team, and if it is not something that will be ubiquously understood then you should either take the responsibility on to teach it to your team personally or drop it all together.

I figured if we were to start a comment war on each others posts then it would just up kick the conversation and provide both posts with more traffic. Truth be told, I love having the countering perspective directly linked to in this post.

I don't want anyone to think - hey, Zak said it, so it must be true. I try to encourage the challenge of differing perspectives and in cases where it's my personal blog or YouTube channel's brand I'll push the emotion to see what kind of conversations we can spark up.

Collapse
 
snickdx profile image
Nicholas Mendez •

Indeed JavaScript has enough syntax to implement a solution in multiple ways. However, in writing clean code the solution that is readable and optimal is most preferred. For loops would work fine for most if not all of these use cases.

Relevant Video: youtube.com/watch?v=qaGjS7-qWzg

Collapse
 
insidewhy profile image
insidewhy •

Verbose code is not only boring to write, it can hamper understanding. I think most teams will opt to balance verbosity and ease of understanding. I haven't worked with developers who would favour loops over a functional approach in many years. Although it is necessary when you're writing a framework due to v8's poor optimisation of closures, in other cases performance doesn't matter so much.

Collapse
 
cleancodestudio profile image
Clean Code Studio •

I've actually seen this video before. These developers are probably pretty descent developers if they come from Google (I'm at Amazon and will personally tell you that FAANG developers are not always spectacular - they won't be bad, but it's still not common to see spectacular at FAANG. You'll run into great ones more often, but on average, most FAANG developers are simply pretty good and very few are spectacularly good).

The next thought I'd bring up is that for loops in general leave a lot of room for unintended mutations to occur. One of the many benefits of reduce is that it is pure in form (given you don't use an implicit return and intentionally or unintentionally pull in extraneous state that then neglects this point).

One of, if not the, number one cause of JavaScript bugs is unintended mutations.

I do like there idea that the callback should be the second parameter.

As far as readability goes, I'm not onboard with the idea that reduce is less readable. I will say it takes experience using reduce for it to come across as clean as it is to those who are familiar with functional programming.

Once you are familiar with the syntax, I'd say reduce is as readable if not more readable than loops.

const flatArr = []

for (const elem of arr) {
    if (Array.isArray(elem)) 
       flatArr.push(...elem)
    else
       flatArr.push(elem)
}
Enter fullscreen mode Exit fullscreen mode

This example they show, as they pointed out, has a mutation. I agree that within a given modularized block, mutations aren't the most tragic thing in the world.

On the other hand, it is a negative - but it's a trade off for improved readability. If the readability is the same then you don't want to make that trade off.

const flatArr = []

flatArr.reduce((flattened, elem) => [
           ...flattened,  
           ...(Array.isArray(elem) ? elem : [elem])
        ]
, [])
Enter fullscreen mode Exit fullscreen mode

I'd argue by simply implementing a cleaner reduce implementation that we are able to have the best of both worlds.

All we're doing is inversing how we handle the element if it is an array. If the elem is not an array we wrap it in brackets making it an array otherwise we leave it be. Then we call the spread operator knowing that we'll have an array either way.

We don't have to make the trade off of potential mutations for increased readability.

Additionally, we could take this a step further and abstract away the functionality of arrayifying an element if it isn't already an array into it's own one line pure function.

const flatArr = []
const toArray = item => Array.isArray(item) ? item : [item]
flatArr.reduce((flatten, elem) => [...flatten, ...toArray(element)],  [])
Enter fullscreen mode Exit fullscreen mode

Now, using a simple one liner toArray function that is pure, we have removed all of our indentations and made the lines visually appealing by proceeding the length of each next line by more characters.

If you personally ask me which is more readable between

const flatArr = []

for (const elem of arr) {
    if (Array.isArray(elem)) 
       flatArr.push(...elem)
    else
       flatArr.push(elem)
}
Enter fullscreen mode Exit fullscreen mode

and

const flatArr = []
const toArray = item => Array.isArray(item) ? item : [item]

flatArr.reduce((flatten, elem) => [
   ...flatten, ...toArray(element)
],  [])
Enter fullscreen mode Exit fullscreen mode

I'm going with the ladder.

In the ladder example we have variables, functions, parameters, and output.

In the first example we have language keywords like of which is often confused with in or simply not used and instead a longer form implementation is used to get the for loop working properly.

In the first examples we have two paths that tree out, that's an extra dependency - if else.

If this then mutate this variable into this, else mutate this variable into that.

In our second example, we are mapping each element of our array using the toArray function. That's not if this, else that. We are saying this will happen. Next this will happen.

We don't have to worry about accidentally treeing out the wrong direction and unintentionally mutating our variable which would not necessarily throw an error letting us know we messed up.

In our second example, if we don't map the item correctly, we'll immediately get an error - you can't spread a non spreadable thing in JS. If we don't properly map our element into the toArray function, then we don't have an array. Error immediately - we fix the bug, no treeing out, no unintended mutations, and once you spend the time to understand what's going on I would argue it IS much more readable to use reduce than the for loop.

Collapse
 
cleancodestudio profile image
Clean Code Studio • • Edited

Oooo, also an after point, this example above is a great show case of why the ternary should be used in place of if else when possible.

If else trees out the possible states. Ternaries do not. This was an interesting one - thanks for your comment @nicholasmenez , it has me thinking deep into the details.

Collapse
 
csirolli profile image
Christian Sirolli •

Now which way of doing each of these things is the best for performance?

Collapse
 
grantdotdev profile image
Grant Riordan •

This was my question all the way through this article. Yes it can do it but which is more performant. That would have been a better comparison or key selling point for me.

Collapse
 
cleancodestudio profile image
Clean Code Studio •

You can use big-o-notation to determine the performance of reduce at scale just like with any other traditional looping function.

It's linear time O(n) if you just run through each element in the array one time which is the default behavior of reduce.

Collapse
 
johnt_f807e8f581 profile image
JohnT •

Great way of combining this article with a related YouTube video.

Feels like the video is meant to go right along with this post. Much appreciated!

The screencast does a great job at covering some of the harder to write about topics.

I was lost when you were writing about using parentheses to return an object implicitly returned but it was stupid easy to understand via your youtube video and the follow along coding examples.

This article, I don’t think, talked about using brackets to set object keys names based on variable values.

Your reduce screencast covers it quickly, but through the video example of quickly was enough. Felt concise and to the point. Thanks for this one!!🙏 Really solid stuff!!

Collapse
 
cleancodestudio profile image
Clean Code Studio •

Thanks @johnt - glad the Clean Code Studio screencast went hand in hand with this dev to post to help improve the learning process!

Collapse
 
ozqu profile image
Oskari Ruutiainen •

In section 10, third code snippet has an error. Fifth row should have [student] instead of plain student

Collapse
 
cleancodestudio profile image
Clean Code Studio •

Thanks @ozqu !

Nice eye, fix made in that section for this post :)

Collapse
 
val_baca profile image
Valentin Baca •

Don't forget the really powerful use: using reduce to implement map :D

Love reduce, it really is the Uberfunction

Collapse
 
jankapunkt profile image
Jan Küster •

This is why I'm on dev.to

Collapse
 
cleancodestudio profile image
Clean Code Studio •

Collapse
 
cleancodestudio profile image
Clean Code Studio •