Maybe also have `groupByMap`?

[bakkot]

In the interest of having both the convenience of regular objects and the additional utility of Maps available, albeit not in the same object, perhaps we can have a method which returns a plain object (coalescing return values with ToPropertyKey) as well as a method which returns a Map (coalescing only 0 and -0, and otherwise by identity).

[jridgewell]

My other thought is that we could have a 3rd argument similar to reduce, which acts as the init value. During the setting phase, we would check if this is a Map/WeakMap, and perform the appropriate set operations. Else, we would treat it as an object. If it's empty, we would initialize to a prototype-less object.

[ljharb]

That opens up a bunch of questions - what if the init value is a Set, or a TypedArray (on the array method), or a Tuple, or a Record?

[bakkot]

Interesting thought. To me I think that adds a lot of conceptual complexity for not much value, vs just having two methods.

[theScottyJam]

One option (similar to what @jridgewell was proposing) is to have the extra parameter expect an object with an "emplace" function (emplace for Map/WeakMap is proposed here). All update operations will happen through the provided emplace function. If this extra parameter is not provided, it'll default to special behavior for grouping into a plain object.

const getParity = i => i % 2 === 0 ? 'even': 'odd'
const mapOfResults = array.groupBy(getParity, new Map());
const weakMapOfResults = array.groupBy(getParity, new WeakMap());

Alternatively, we could create an "emplace" or "groupBy" protocol (via a new well-known symbol) that Map and WeakMap simply implement using their public emplace function, but others may implement through other means.

My preference might be to make this parameter expect an options object, to open up the possibility of customizing other aspects of the groupBy algorithm in the future.

const mapOfResults = array.groupBy(getParity, { into: new Map() });

[zloirock]

I'm against adding a reducer argument since it makes the signature of this method more complex and less readable. Also, objects and maps / weakmaps haven't a common interface for adding new entries.

.groupByMap LGTM and, since maps are iterable and could store any keys, it could be used for converting results to anything:

const weakmap = new WeakMap(array.groupByMap(fn));

[bmeck]

I actually think only 1 method would be enough at least for the initial proposal, then you can manage your identity side table rather than spec having nits about things like -0 and 0.

[theScottyJam]

I agree @bmeck - honestly, I'm not sure how many people would want a map as an output (maybe a lot - maybe my assumptions are wrong, but I would assume the majority just need an object output). People who need map support can build their own groupByMap() function, like they already have to do today. If there seems to be a lot of community need for such functionality, a follow-on proposal can be discussed to provide this functionality, either through an extra parameter or through a separate function.

[bmeck]

I'd personally love a Map rather than an object, but I use Maps a lot to associate data.

[zloirock]

@bmeck null prototype object good for object destructuring, maps for iteration with any keys.

const { foo, bar, baz } = array.groupBy(fn);
// ...
for (const [name, subarray] of array.groupByMap(fn)) { /* ... */ }

Both of those cases are useful, map can't be simply used in the first case, object in the second.

[bmeck]

Object is usable in the second with Object.entries(arr.groupBy(fn))

[ljharb]

The only thing that's not usable in the second case is if you want the "group by" key to be something other than a string or symbol.

Personally, i think this will be an extreme minority case, but it still seems reasonable to find a way to satisfy it.

[zloirock]

@bmeck

with any keys

@ljharb I just agreed with your opinion written here -)

[bakkot]

I want this quite frequently, personally. The most common case is when you want to bucket things which have two attributes which match - for example, you have a list of addresses and want to bucket those which have both the same city and country. If your cities and countries are represented as strings, you can come up with an awkward solution which creates a single string from both of those, but that's ugly and error-prone (if you just join with ,, what if your city or country has a , in it?), and you have to parse the values back afterwards. It would be much, much nicer to just group by a record containing both attributes.

(Also, it's pretty common to have attributes which are not strings which you want to match on. For example, even if you just care about grouping addresses by city, if your cities are represented as objects with identity you really need a Map.)