Rule proposal: `no-reduce-spread`

[bschlenk]

Using spread inside a reduce call can turn a O(n) algorithm into O(n**2). See https://www.richsnapp.com/article/2019/06-09-reduce-spread-anti-pattern

Fail

const result = items.reduce((acc, item) => ({
  ...acc,
  [item.name]: item.value,
}, {});

Pass

const result = items.reduce((acc, item) => {
  acc[item.name] = item.value;
  return acc;
}, {})

[fisker]

I think this already covered by #1260, I need more time to finish that rule.

[bschlenk]

Would that rule be smart enough to recognize when the item would need to be mapped? This failure example wouldn't translate directly without mapping the object to an array first

const result = Object.fromEntries(items.map(item => [item.name, item.value]));

[fisker]

Yes, actually you can check #1308. not finish yet.

[fregante]

Isn't this already covered by no-reduce? Both examples are IMHO pretty bad compared to a plain loop:

const result = {};
for (const {name, value} of items) {
  result[name] = value;
}

[manovotny]

I get there is no-array-reduce, but I still thing there merit to this rule. It'd be for those who still want to allow reduce, but want to avoid the hidden O's from the syntactic spread sugar.

I was actually working on my own rule for this same thing this weekend, but thought I'd check here before committing and found this issue.

@sindresorhus I've got a lot of the code figured out for this already and would be willing to submit a PR with some guidance.

1. Are you at all interested in adding this as a rule?
2. Do you want to disallow spread usage in just reduce or are there other array iterator functions (ie. map, filter, etc.) you'd like to include as well and change the rule name to something like no-iterator-spread?

[sindresorhus]

I think this already covered by #1260, I need more time to finish that rule.

@manovotny Any comments on that? ^

[manovotny]

@sindresorhus actually, in looking over the use cases in our company's org, reduce usage is used more for outputting arrays than objects, which is making me rethink things a bit.

Based on that analysis, I'd say using the no-array-reduce in favor of map, etc. makes more sense.

@fisker's PR attempt does seem to be a good solve outputting objects.

For beyond just reduce though, I still wonder if there's anything left to solve about spread in iterators and hidden O's.

[fisker]

We've added prefer-object-from-entries, can we close this?