Add spread rule for iterable objects

[tmlayton]

Reasons:

• Somewhat defensible: mostly better performance, not Safari (a test with NodeList, a test with jQuery object, and a chart) but we are talking high operations a second so not sure it is a noticeable difference
• Brevity
• Subjective: easier to read, I prefer it

Also updated mentions of spread operator to spread syntax, as it is not an operator.

@Shopify/javascript

[gf3]

not seeing much of a difference in safari, although generally i tend to prefer functions over language syntax due to flexibility and composability

[tmlayton]

yeah looks like Safari is the only one marginally slower, but both desktop and mobile which applies to web views so Chrome on iOS

[lemonmade]

I could mostly go either way on this one, personally. I think I visually prefer Array.from(something), but prefer [...some, more, ...elements], so I dunno. This definitely matches much better to how we do shallow clones of objects (typically, {...otherObject}, although we don't often do it without having more keys to add), but matches slightly worse to other functions that take iterables and convert them to a data structure (new Map(), new Set()). If others feel good about this, I'm on board too ⛵️

[clauderic]

I also personally prefer Array.from() in certain specific cases, for instance when converting a NodeList to an Array, I find Array.from() to be a bit more expressive.

I definitely prefer const clonedArray = [...originalArray] over slice to shallow clone an array.

[amrocha]

I like the spread syntax a lot, but I don't like the inconsistency in using both spread and Array.from for different kinds of conversions

Since Array.from() covers all cases and spread doesn't I lean towards using Array.from

That being said, if cases where spread doesn't work are fairly rare for us then I'd prefer using spread

[TzviPM]

👍

[lemonmade]

I'm cool with this 👍 can we also add an issue to make this into a linting rule?

[lemonmade]

Can we just ditch this? I don't think it's particularly relevant advice and it makes the rule feel harder to understand than it really is (just use spread)

[tmlayton]

I'm in favor of ditching this, although spread throws in this example because it has no iteration protocol, e.g.

const arrayLikeObject = {
  0: 'a',
  1: 'b',
  length: 2,

  [Symbol.iterator]() {
    let index = 0;

    return {
      next: () => {
        return this[index]
          ? {value: this[index++], done: false} 
          : {done: true};
      },
    };
  },
};

[perrupa]

I much prefer Array.from() because it is more explicit in what it does. Also, I feel that distinguishing between array-like objects and iterables is going to make this rule much more difficult to understand/follow.

I think the only case I'd favor spread over Array.from() would be when I also want to use a spread anyways.

const newArray= [
  ...nodeList,
  el,
  ...otherArrayLike,
];

Personally, I think spread is for de-structuring and joining arrays, not converting things into them

[tmlayton]

I removed the Array.from rule for array-like objects and added a comment, similar to 8.4 for Array#slice, to the end of the spread rule:

For objects without an iteration protocol, continue to use Array.from.

And opened #265 to add a linting rule