Add Array.prototype.groupBy[toMap] to JS lib definitions.

[Pokute]

The proposal for Array.prototype.groupBy and Array.prototype.groupByToMap reached stage 3 recently.

Search terms: proposal-array-grouping array groupBy ernest

lib Update Request

With advancement into stage 3, it's time for JS engines, transpilers and toolings to start implementing support for new features and provide feedback for the proposal's advancement into stage 4.

Configuration Check

This is so new that it needs to go into ESNext target.

Missing / Incorrect Definition

Missing Array.prototype.groupBy and Array.prototype.groupByToMap.

Sample Code

const array = [1, 2, 3, 4, 5];

// groupBy groups items by arbitrary key.
// In this case, we're grouping by even/odd keys
array.groupBy((num, index, array) => {
  return num % 2 === 0 ? 'even': 'odd';
});

// =>  { odd: [1, 3, 5], even: [2, 4] }

// groupByToMap returns items in a Map, and is useful for grouping using
// an object key.
const odd  = { odd: true };
const even = { even: true };
array.groupByToMap((num, index, array) => {
  return num % 2 === 0 ? even: odd;
});

// =>  Map { {odd: true}: [1, 3, 5], {even: true}: [2, 4] }

Sample code from https://github.com/es-shims/Array.prototype.groupBy

Documentation Link

Proposal: proposal-array-grouping

Shim implementation that can the code can be tested against: es-shims/Array.prototype.groupBy

[orta]

Open for someone to take a look. I'm not quite sure off the bat what this should look like FWIW.

I think we probably need to make the same assumptions as we do with Object.entries where we can't use keyof #38520

[orta]

I asked, and we generally think this might be ok to have the more accurate typing accurately reflecting the source object. Will need a bit of testing out when there's a PR

[DanielRosenwasser]

Yeah, I think we could think of this as closer to fromEntries; however, fromEntries doesn't try to preserve keys at all (and I don't think it even (cleanly) could).

[DanielRosenwasser]

I feel like there is something close you can get with reversed mapped types - we discussed this in a recent design meeting about correlated unions.

#47109 for some description of this.

[Hanaffi]

@orta @DanielRosenwasser Can you assign this to me?

[orta]

We don't assign issues to external folks, you're welcome to make the PR as long as there isn't an existing one (which you would see in this issue's timeline above) - so go for it

[Hanaffi]

@orta Thanks. Its my first time to contribute to TypeScript. So can you give me some tips and how to get started on this issue?
I feel lost in the codebase :D

[yessGlory17]

@DanielRosenwasser I want to work on this issue. It's my first time to contribute to Typescript. Is it possible for you to give me some information?

[SamB]

@DanielRosenwasser

Yeah, I think we could think of this as closer to fromEntries; however, fromEntries doesn't try to preserve keys at all (and I don't think it even (cleanly) could).

You mean there would be a problem with the following overload, or have I misunderstood?

interface ObjectConstructor {
    fromEntries<K extends PropertyKey, T = any>(entries: Iterable<readonly [K, T]>): Record<K, T>;
}

[DanielRosenwasser]

Well, I don't know if you can have multiple overloads, but that fails in the case of heterogenous property types:

interface ObjectConstructor {
    fromEntries<K extends PropertyKey, T = any>(entries: Iterable<readonly [K, T]>): Record<K, T>;
}

Object.fromEntries([["a", 42], ["b", "hello"]]); // errors

@niieani has a PR at #50203 but it fails once the value is not as const'd or contextually typed.

interface ObjectConstructor {
    fromEntries<KeyValue extends readonly [PropertyKey, any]>(
        entries: Iterable<KeyValue>,
    ): [KeyValue] extends [[PropertyKey, any]]
        ? { [k: string]: KeyValue[1] }
        : { [K in KeyValue[0]]: KeyValue extends readonly [K, infer V] ? V : never };
}

const a = [["a", 42], ["b", "hello"]];
Object.fromEntries(a)
//                 ~ error

(CC @sandersn)

[SamB]

Oh, back on-topic, it looks like there were web-compatibility problems with the name Array.prototype.groupBy (issue: tc39/proposal-array-grouping#37) and with the next name they tried, Array.prototype.group (issue: tc39/proposal-array-grouping#44).

It looks like people are now thinking that the next thing to try is adding groupBy/groupToMap functionality as static factory methods on Object and Map, (PR tc39/proposal-array-grouping#47), with no particular provision for subclasses.

We didn't need provision for subclasses anyway …

which makes sense to me because:

• For the ArrayLike to object version, you'll basically always want a null prototype to avoid key collisions.
• For the ArrayLike to Map version, this keeps the engine devs' jobs relatively simple (there's no way for user code to observe any of the steps between "7. Let map be ! Construct(%Map%)." and "9. Return map.", so they can optimize the heck out of it as long as the entries end up in the correct order, without needing to worry about fallback to a "slow" version) but you can easily override the method on a subclass constructor if you want.

Anyway, the functions on Array.prototype didn't make any specific provision for subclasses, either.

[niieani]

@DanielRosenwasser Just FYI, I've addressed these failure cases, though the overall complexity has increased. The strict and sound typing for Object.fromEntries is published in an NPM package nesity-types.