Prefer the spread operator over `Array.from()`

[sindresorhus]

Fail

const set = new Set([1, 2]);
Array.from(set).map(() => {});

Pass

const set = new Set([1, 2]);
[...set].map(() => {});

The only difference between them is that Array.from() also works on array-like objects, while spread requires something to implement the iterator protocol, but we don't care about that, as it's what you should do anyway.

Should be easy to make this auto-fixable.

There's already a built-in ESLint rule called prefer-spread, but it's only concerned about .apply().

[bdougherty]

@sindresorhus working on this. Should the name be prefer-spread or something different?

Also, there is one potential use case for Array.from and that is if you are using a map function along with it (Array.from(obj, mapFn, thisArg)). I've never used it, but I'm thinking that it shouldn't be marked as an error if you're using that since according to MDN it avoids creating an intermediate array. What do you think? edit: that really only applies to TypedArray.from which I guess we won't check in this rule.

[sindresorhus]

Cool. Yes, prefer-spread.

[fregante]

Why though? [...var] isn't better looking nor it does exactly the same thing. Array.from works on Array-likes while ... only works on iterables.

[sindresorhus]

Array.from works on Array-likes while ... only works on iterables.

I would call that a benefit. Array-like is IMHO just a legacy quirk. Iterables is a better way to define things that can be iterated. If you truly want to imitate array, you can just subclass it.

[sindresorhus]

[...var] isn't better looking nor it does exactly the same thing.

It's better in that it's more consistent. You use spreading for many other things now too, even objects. Also makes it easier to spread from multiple things if you decide to change it, like [...set].map(() => {}); => [...set, ...set2].map(() => {});.

[sindresorhus]

There should be one-- and preferably only one --obvious way to do it.
- https://www.python.org/dev/peps/pep-0020/

[buschtoens]

I enabled this rule by default as I extend unicorn:recommended, but I found a quite annoying edge-case, due to:

Array.from works on Array-likes while ... only works on iterables.

It is true that:

Array-like is IMHO just a legacy quirk. Iterables is a better way to define things that can be iterated.

However, all DOM APIs (to my knowledge) don't implement the [Symbol.iterator] protocol.

// This works
for (const element of Array.from(document.querySelectorAll('.foo'))) {
  console.log(element);
}

// This doesn't
for (const element of [...document.querySelectorAll('.foo')]) {
  console.log(element);
}

I've enabled ESLint auto-fixing in my editor and marked unicorn/prefer-spread as an error, and more often than I'd like to admit I trolled myself with this pretty hard.

I'll probably just demote the rule to be a warning, because I don't want to monkey-patch the [Symbol.iterator] protocol into the DOM API, even though that'd be even better, since then you could just do:

for (const element of document.querySelectorAll('.foo')) {
  console.log(element);
}

[papb]

Hmm, interesting point @buschtoens - Perhaps this rule can be updated to allow Array.from with DOM APIs, and disallow it otherwise?

[fisker]

@buschtoens This issue is quite old, can you open a new one about this?

[buschtoens]

I thought about that too, but it wouldn't be a reliable fix. We can detect if a DOM API is directly used inside the expression that is passed to Array.from(), but everything else would require more static analysis and basically TypeScript.

const nodeList = document.querySelectorAll('.foo');
for (const element of Array.from(nodeList)) { // would get auto-"fixed" incorrectly
  console.log(element);
}