Disallow for-of

[aboyton]

The style guide 11.1 says that you shouldn't use for-of and instead should use forEach (which I completely agree with).

That said, the ESLint rule no-iterator doesn't seem to enforce this, and the entry for no-restricted-syntax contains ForInStatement but not ForOfStatement.

Can we add ForOfStatement to no-restricted-syntax (or is the a better way of restricting for-of statements?

[ljharb]

Absolutely, thanks! Want to make a PR? it will be semver-major, so i won't be able to merge it immediately, but having it queued up would be great.

[aboyton]

Looks like I was beat to the punch by mere hours. Thanks @SimenB.

[dplusic]

What should I do in this case:

async function foo(args) {
  for (const arg of args) {
    await bar(arg);
  }
}

[ljharb]

@dplusic in nice, simple ES6:

function foo(args) {
  return args.reduce((prev, arg) => prev.then(() => bar(arg), Promise.resolve());
}

[dplusic]

It works. Thanks!

[leebenson]

@ljharb - what about generators?

I have a function like this that flattens objects recursively, so { user { name: "Lee", location: { city: 'London' } } } becomes {'user.name': 'Lee', 'user.location.city': 'London'}:

function* flatten(obj, str = '') {
  if (obj) {
    for (const name of Object.getOwnPropertyNames(obj)) {
      if (!Array.isArray(obj) && typeof obj[name] === 'object') {
        yield* flatten(obj[name], str ? `${str}.${name}` : name);
      } else {
        yield {
          [`${str}.${name}`]: obj[name],
        };
      }
    }
  }
}

Which is turned into a 'flat' object with Object.assign({}, ...flatten(obj));

I'm probably overlooking an obvious equivalent with map, but a generator solves this quite neatly...

[ljharb]

@leebenson generators are not allowed in our guide.

As for an alternative, I'm not sure if this actually works, but perhaps something like:

function flattenObject(obj, prefix = '') {
  return Object.entries(obj).reduce((acc, [key, val]) => {
    const prefixedKey = prefix ? `${prefix}.${key}` : key;
    if (val && !Array.isArray(val) && typeof val === 'object') {
      return Object.assign(acc, flattenObject(val, prefixedKey));
    }
    return Object.assign(acc, { [prefixedKey]: val });
  }, {});
}

[leebenson]

Thanks @ljharb. This minor tweak works perfectly:

function flattenObject(obj, prefix = '') {
  return Object.entries(obj).reduce((acc, [key, val]) => {
    const prefixedKey = prefix ? `${prefix}.${key}` : key;
    if (val && !Array.isArray(val) && typeof val === 'object') {
      return Object.assign(acc, flattenObject(val, prefixedKey));
    }
    return Object.assign(acc, { [prefixedKey]: val });
  }, {});
}

[minexew]

@dplusic @ljharb
I don't understand. Where's the advantage in making your code totally unreadable?
Purity is nice, but not when it takes 30 minutes to decipher a simple function.

[ljharb]

Of course readability is subjective, but I find loops far more unreadable than a functional alternative.

[minexew]

That's interesting. Of course I don't have any empirical evidence for this, but I bet it'd take the average programer an order of magnitude more time to understand your snippet vs what @dplusic posted.

I hope this fad of functional-at-all-cost is over soon. There's a reason why Haskell hasn't gone mainstream.

[leebenson]

I do think @minexew has a point.

With native async/await landing in V8, I think it's going to be pretty common pattern to 'unwind' functional logic like this. for...of and generators often make the code more readable, and easier to follow. I'm not sure effectively banning swaths of valid JS is the way to go.

Personal preference, of course.

[flying-sheep]

i’d actually argue that for..of should be used because of functional style:

.forEach() isn’t functional. it exists for its side effects. so if anything, .forEach() should be banned and for..of allowed in order to make clear that side effects are happening here (which isn’t as apparent from a filter → map → forEach pipeline)

[ljharb]

@flying-sheep it's a functional evolutionary step to map and friends. for..of does not lend itself towards evolving to be a proper map, filter, etc. In addition, .forEach forces side effects (or else nothing really happens) - for..of can also be used not for side effects.

[flying-sheep]

behold:

function* map(callable) {
	for (const element of this) {
		yield callable(element)
	}
}
function* filter(predicate) {
	for (const element of this) {
		if (predicate(element)) yield element
	}
}

const odd = '12345'
	::map(parseFloat)
	::filter(e => e % 2)

In addition, .forEach forces side effects (or else nothing really happens) - for..of can also be used not for side effects.

both only have side effects (if anything, .forEach returns undefined). what do you mean with “not for side effects”

[ljharb]

@flying-sheep lol fair point, both are for side effects since for..of isn't an expression. forget that part.

The :: operator is stage 1, and Airbnb only recommends using stage 3 proposals and above. Similarly, transpiling generators requires regenerator-runtime, which is way too heavyweight to ship to production, so our config also forbids generators at this time.

[SimenB]

Similarly, transpiling generators requires regenerator-runtime, which is way too heavyweight to ship to production, so our config also forbids generators at this time.

Kinda tangentially related: would you be interested in a config for server-side only projects? I've used airbnb-base at it works fairly fine, but e.g. trailing commas in functions has to be disabled, and generators could be allowed, etc. There's not a lot of rules that needs tweaking, but maybe you could also include https://github.com/mysticatea/eslint-plugin-node.

If you're interested at all, I can create a new issue for it to discuss its merits there? 😄

[ljharb]

Server-side only projects should be using babel also.

[SimenB]

Why? With async/await landing, the only syntax I care about is object spread, and it's OK to use Object.assign. Waiting for trailing function commas until support lands isn't an issue either. Adding the overhead of a build step seems unnecessary.

[ljharb]

For one, old syntax is generally faster than new syntax, since it's had time to be optimized. Additionally, there'll always be new syntax you want to use, and if your build process is already in place, it's trivial to add that.

A build step shouldn't add overhead, since you should be running your linter and your tests prior to code going to production anyways - just add the build step into there.

[flying-sheep]

@ljharb maybe i didn’t understand you: you argued that it’s an evolutionary step towards functional array methods. i showed that this isn’t the case. my use of generators is irrelevant. e.g. here’s a map implementation without anything you mentioned:

Array.prototype.map = function map(callback) {
	const mapped = []
	for (const element of this) {
		mapped.push(callback(element))
	}
	return mapped
}

[ljharb]

The given implementation of map - or any other abstraction - is entirely irrelevant. forEach is an array prototype method, just like the functional array prototype methods.

[leebenson]

I use my babel-preset-node7 for server side use of the airbnb preset. It adds the (very few) missing pieces -- trailing function commas, etc -- and avoids transpiling native features like generators, async/await, etc.

The extra build step makes sense in my case, because I'm writing universal code that targets both the server and the browser, so a build step is necessary anyway. I use generators, async/await, etc freely, and provide a different babel config to each target in webpack. In my use case, adding browser polyfills/runtimes has a negligible effect on the bundle size. My total app is less than 200kb gzipped, with React, Mobx, es2015 polyfills, all app code, etc.

For the most part, I find the airbnb preset to match my own personal stylistic preferences, but I do agree that eliminating for...of is a step too far. I find generators to be very useful for lazy evaluation and for..of (especially coupled with generators and await) makes the code path very easy for others in my team to follow.

In my case, adding a custom rule for no-restricted-syntax fixes my one irritation.

[flying-sheep]

yeah, for..of and generators can be used e.g. for efficient parsers (you delegate to sub parsers via yield*). some languages run on those features extensively, e.g. python and rust.

JS is always the slow kid on the block. maybe in a year or so, we’ll see “map considered harmful” posts that praise how much awesomer generators and comprehensions are.

[ljharb]

Comprehensions are never coming to JS, so I doubt you'll ever see that post :-)

[fleksin]

Just found this thread. Hope I'm not too late to ask questions.
Say I have a function

someFunc = (array) => {
    for (const item of array) {
       if (someCondition) return false;
    }
    return true;
}

What's the equivalent solution if not using for-of loop ?

[ljharb]

@fleksin
Assuming someCondition can better be represented as somePredicate(item), the existing logic gets true if "every item produces false", so:

someFunc = array => array.every(item => !somePredicate(item));

Alternatively, if "any item produces true":

someFunc = array => array.some(item => somePredicate(item));

but you'll want to confirm that the behavior matches your expectations for an empty array.

[maple3142]

@hmagdy No, they are not same.
The former executes the promises sequentially, while the latter executes them at them same time.

[ljharb]

Indeed, you'd need the (not weird - a normal part of JS and functional programming) reduce instead.

[flying-sheep]

The former executes the promises sequentially, while the latter executes them at them same time.

The former actually results in a “SyntaxError: await is only valid in async function” as expected.

The arrow function isn’t async, and await needs to be in an async function directly. If we make it async, you’re of course right, but that’s not a surprise: Just calling async functions (as forEach does) runs them parallely.

---

I don’t think this discussion is helpful anymore. Everything’s been said on why the rule is there:

• The AirBnB JS style is tailored for AirBnB’s use
• AirBnB targets older browsers without iterator support: Disallow for-of #1122 (comment)
• The AirBnB guide recommends forEach because for..of relies on iterators, and polyfill support for old browsers here is slow.
• It’s easy to create your own derived style guide that is tailored to your preferences.

I think the only thing left to discuss is what I said in #1122 (comment), and I filed #2019 for that.

[ljharb]

To clarify; we recommend forEach because loops should basically always be avoided.

[flying-sheep]

People don’t agree with you here, see the discussion in #2019

[Ghost---Shadow]

I want to process an iterator. Is there a functional way of doing this?

let result = iterator.next();
  while (!result.done) {
    console.log(result.value);
    result = iterator.next();
  }

[ljharb]

@Ghost---Shadow Array.from(iterator, item => process(item))? There's also https://npmjs.com/iterate-value / https://npmjs.com/iterate-iterator if that's useful for you.

[jakobrosenberg]

I'm much faster and far less prone to errors if I can understand the code I'm looking at.

All things equal, readability and clarity should be first priority.

for (const person of queue)
  await person.ready()

queue.reduce((prev, person) => prev.then(() => person.ready(), Promise.resolve());

How fast can you decipher what the function does and spot the error?

---

Furthermore, how would you handle this logic in a readable way?

for (const person of queue){
    await person.isReady()
    queue.push(...person.expectedGuests)
}

or this

for (const [i, person] of queue.entries()){
    await person.isReady()
    queue.push(...person.expectedGuests)
    queue.splice(i, person.accompanyingGuests.length)
}

And what if we decide to add a timer that bumps people to the back if they're too slow? I can add extra logic while keeping things readable and easy to reason about.

[ljharb]

@jakobrosenberg quite fast, but obv that's subjective. However, it's pretty easy to make an abstraction around that reduce like serialize(queue, (person) => person.ready()), which is much more readable since it explicitly declares what it's for.

Same feedback on the others - using a loop requires someone to infer your intention, using a named abstraction doesn't.

[jakobrosenberg]

using a loop requires someone to infer your intention, using a named abstraction doesn't.

You can abstract a for .. of loop into a named function and then you're even on intention.

As Capone said: You can get much further with clear intentions and readable code than you can with clear intentions alone.

[ljharb]

@jakobrosenberg that's totally true! and if you do that, and you don't transpile such that you'd include regenerator-runtime when using for..of, then you can use an eslint override comment inside that abstraction. The goal is to make most of your code clean - there's nothing wrong with using overrides to paper over well-hidden warts that live inside clear abstractions.

[DominicTobias-b1]

for..of is supported in all browsers except IE without compilation so I doubt there's much if any perf gain in other browsers by not using it (untested). I think it's much easier to understand than reduce, in fact I find for loops are almost always easier to understand than something recursive (and sometimes much more efficient on the stack if the VM doesn't support tail recursion optimisation).

Also if the accumulator is an array or object you might tend to spread the next item in, which is vastly less efficient than writing some more lines of code and mutating accumulator. At that point you haven't really saved any code compared to a loop, just written more opaque and slow code because someone said it's more "FP". So I use reduce if I'm actually reducing stuff or it's really cleaner, in this case I agree with @jakobrosenberg that his code is a lot easier to understand, which is much like try/catch/await being easier to understand than Promise then/catch 🤷‍♂️

[ljharb]

@DominicTobias-b1 in the latest version of all browsers. Despite marketing, no browsers are "evergreen" according to the google analytics of major websites I've been able to review over the last couple years. (Nothing but safari will likely ever support PTC - which is not an optimization - so that's not really relevant to discuss)

Performance isn't important, readability is.