Using 'ForOfStatement' is not allowed (no-restricted-syntax)

[mrtl-srn]

Hi,
Since everybody tell us to not use forEach() but use for loop instead because it is much faster (https://jsperf.com/test-if-using-forofstatement-is-not-allowed-makes-sens), I would like to know why this is not allowed by airbnb ?

[ljharb]

a) microbenchmarks (ie, jsperfs) are not accurate reflections of real-world performance
b) performance isn't important. It's easy to make clean code fast; it's hard to make fast code clean.

[AKST]

While I get this is an opinionated linter, the readability of forEach over for of is pretty debatable. But more importantly for of is actually more polymorphic as you can add the iterator property to any data type.

techinically you can add a forEach method to any data type, but 🤷‍♂️

Plus It's also more consistent, as the jQuery implementation of forEach orders parameters differently (yes some people still have to interact with jQuery), that and nodeLists's implementation of forEach is not present on all browsers, where as using for of works once you start using the babel polyfill.

for of is simply a more powerful feature.

---

For people landing here via google, here's the original definition if you want to over load it.

[ljharb]

Array.prototype.forEach.call(nodeList) works in every ES5+ browser.

Separately, jQuery iteration methods should only be used for element collections, so I'm not sure why its element ordering really applies.

You can't yet add the iterator property to any data type, because Symbol is not polyfillable nor available in every browser we support. This guide does not allow using symbols currently.

[AKST]

Array.prototype.forEach.call(nodeList) works in every ES5+ browser.

True, but if the original argument against for of is that it isn't readability, then this isn't a strong argument in favour of forEach.

I'm not sure why its element ordering really applies.

It's less the ordering of the elements and more the ordering ordering of the parameters on invocation, the function you pass to jQuery forEach each passes the index through the first argument and the actual element in the second. 

However if the readability of Array.prototype.forEach.call isn't an issue for you, then this may be a non issue.

There's also the fact you can't yield from a forEach for an outer function the same way you can with a for of, or you use await in an async function (unless this rule accommodates for this).

Symbol is not polyfillable nor available in every browser we support.

Doesn't core-js (used by bable I believe) polyfillSymbol's, as well as well known symbols like the iterator symbol?

---

edit: Just so I don't waste your time, is there a link to previous discussion on what decisions led to for of being disabled? Because surely stuff like iterating in a generator or async function is something that's been considered.

[petertrotman]

I'd just like to chime in and say that I would also like a justification for why ForOfStatement is restricted. I would like to use for (let element of array) { ... } in places where I am producing side effects in the iteration.

for(let i = 0; i < array.length; i ++) { ... } is antiquated syntax, and while I know everyone understands what it means, we should be leaving it behind.

array.map has functional connotations and we shouldn't be producing side effects in the closure.

array.forEach is an option, but I personally don't like it for this sort of imperative work.

So I think the ForOfStatement should be removed from the restricted syntax for the above reasons - anyone with any conflicting viewpoints? Do we know what the original justification is?

[ljharb]

The primary argument against for..of is that loops are awful, and should always be avoided. forEach is not a loop, it's an iteration.

The primary reason it's disabled in this guide is that Symbols can not be polyfilled, thus we forbid Symbols, thus Symbol.iterator is unavailable, thus for..of is useless in a generic sense.

[AKST]

The primary reason it's disabled in this guide is that Symbols can not be polyfilled, thus we forbid Symbols, thus Symbol.iterator is unavailable, thus for..of is useless in a generic sense.

This thing is though, they are polyfilled... Just look at this bable output of typeof Symbol.iterator, it's pretty clear their not using typeof right out of the box...

[ljharb]

@AKST Symbol semantics can not be fully polyfilled, and typeof foo in dependencies will never print out "symbol". It's not a shim, it's a sham.

[AKST]

`typeof foo` in dependencies

Okay true, fair point. Why this is baked in makes more sense now, cheers

[kouhin]

@ljharb I wonder without ForOfStatement, how to loop Map.prototype.keys() and Map.prototype.values(),
e.g.

const map1 = new Map();
// map1.set(someKey, someValue);

for (let key of map1.keys()) {
  console.info(key);
}

map1.keys() and map1.values() are MapIterator. They are non-array and we can't use forEach or map1.keys().length.

Should we convert MapIterator to Array for loop?

[ljharb]

@kouhin Array.from(mapOrSet, mapperFunction),Array.from(mapOrSet.keys(), mapperFunction), same for values/entries

in other words, yes - convert it to an array.

[johannpinson]

@ljharb for...of allow us to use break and continue statement (which can be usefull) but not a Array.map or Array.forEach

What's the solution to simulate this two behavior? (only encapsulate part of code in an if...else and so force to complete the iteration?)

Thanks for your advice

[ljharb]

@johannpinson yes, you shouldn't need break or continue ever, that's GOTO. Can you provide a code example with a loop, and I'll try to provide a non-loop example?