DEV Community

Writing modern JavaScript code

Sebastien Castiel on May 20, 2017

Remember when JavaScript was a language used to make elements change on the page when the cursor was over them? These days are over, every language...

Read full post

Guillermo Maiolo • Aug 23 '17 • Edited

You're confusing functional programming with extreme immutability, which is an anti-pattern by itself, generating an incredible amount of overhead.
You're literally advocating to loop three times instead of one just to force yourself to use map, filter and reduce.

I understand these are examples, but they're extremely bad examples for any apprentice dev so this needs to be clarified.

While the post correctly encourages having immutable data, the idea is to keep that data updated with pure functions. Now, pure functions must avoid shared state, mutable data, and side-effects outside of their bounds but not necessarily inside, this simple concept may be hard to grasp at first, so let me try to show it with the examples you used:

// Instead of:
const res = arr
  .map(elem => ({ name: elem.name, calculatedValue: elem.value * 10 }))
  .filter(elem => elem.calculatedValue > 100)
  .reduce((acc, elem) => ({
    [elem.name]: calculatedValue,
    ...acc
  }), {})

// Prefer:
const res = (() => {
  let obj = {}
  for (let i = 0; i < arr.length; i++) {
    const calculatedValue = arr[i].value * 10
    if (calculatedValue > 100) {
      obj[arr[i].name] = calculatedValue
    }
  }
  return obj
})()

Of course it may or may not be better to use Object.keys().forEach() or even Object.keys().map() and still loop once doing all the needed calculations on the fly as well, but the point is that yes, pure functions and functional programming should be used, but we must always have in mind that both of them can use and abuse of mutable data correctly contained and that's not bad, it's actually one of the beauties of Javascript.

tiff • Aug 24 '17

Can you give a better example without chaining together map, filter, and reduce but still keeping it functional? Why is it an anti-pattern?

TQ White II • May 20 '17 • Edited

Prettier lints like crazy. It enforces an absolute coding standard. It's main virtue is that it only has two configuration options, tabs vs spaces and quotes vs apostrophes. Otherwise, everyone who uses it gets standard, well-formatted code. I am a huge fan.

Eric B • May 22 '17

If you map, then filter, then reduce an array in code that I manage, you're not getting your code in.

relativityboy • May 21 '17

A nice little article but your first code example for functional programming is misleading.

The array declaration used for both // Instead of: and // Prefer: is shown visually to be a part of the // Instead of: block.

This might suggest to the user at a glance "oh, the new way is prettier". But it's a misrepresentation of what's going on.

Sorry to be a neg, but you're going to sell an idea, you gotta sell the truth.

Sebastien Castiel • May 21 '17

You're absolutely right, my bad. It's fixed 😉

Matt Leathes • May 21 '17

whilst array.map and array.forEach are unarguably more readable than for loops, aren't for loops still considerably faster in most browsers?

Galdin Raphael • Aug 6 '17

I was thinking of the same. Found this relevant reddit discussion.

I think this is something browsers could optimize. Or probably they already do.
I wonder if there are any benchmarks around.

Adrián Norte • May 22 '17

"The reason? It makes the code more predictible, safer, deterministic, and a lot easier to maintain when you're used to it."

Can you elaborate why? I have never programmed in a functional way in a serious project so I would like to know the reason behind those affirmations.

Thanks.

Mitchell • Aug 24 '17

One of the keys to functional programming is no side effects. So code inside the function shouldn't affect things outside of the function.

Another key of functional programming is that functions should not be affected by things outside of it's scope. (ie: For any given set of parameters the function will always have the same return for that set of parameters).

Keeping these in mind will make code more predictable and safer.

bruno jennrich • Aug 6 '17

what a great advice to replace == by ===... NOT!

this will render a lot of code as unfunctional.

Ethan Stewart • Dec 9 '17

I would argue that in a lot of cases, code that breaks from changing == with === probably stands in need of some improvement anyway. Just IMHO

bruno jennrich • Dec 9 '17

legacy code?

Ethan Stewart • Dec 12 '17

Valid exception to the rule, but unless you're going to update and change it, you probably don't need to lint legacy code, which was the context in which the original post mentioned replacing == with ===