feat request: allow preserving keys (+ types by key) to map over objects

[KiaraGrouwstra]

I'm hoping to be able to properly type functions like Ramda's R.map (for objects) or Lodash's _.mapValues -- in such a way as to acknowledge that mapped over values (which may have been of different types) may give results of different types, dependent on both their respective input type as well as on the mapper function.

Code

let arrayify = <T> (v: T) => [v];
declare function mapObject<T, V, M extends {[k: string]: T}>(func: (v: T) => V, m: M): {[K in keyof M]: V}
// ... or Lodash's _.mapValues, Ramda's R.map / R.mapObjIndexed / R.project...
mapObject({ a: 1, b: 'foo' }, arrayify)

Desired behavior:
{ a: number[], b: string[] }

Actual behavior:
{ a: any[], b: any[] }

I apologize for the use of libraries for this example. Probably more verbose without, but the concept is common in FP libraries.

[aluanhaddad]

This is an issue with the declaration files for ramda as they are specified in the linked repo. The new Mapped Types feature #12114 allows this pattern to be expressed very elegantly.

[KiaraGrouwstra]

I hadn't been aware, thank you for pointing this out! :)

[HerringtonDarkholme]

Hi, I think this might be relevant usage of delayed index access type for generic. More info here #11929 (comment).

Rambda's API is a perfect usage of that.

[KiaraGrouwstra]

If you'd forgive a follow-up question (which I can take to SO if deemed inappropriate here), I'm trying to figure out how to generalize the mapObj example of aluanhaddad's Mapped Types link:

function mapObject<K extends string | number, T, U>(obj: Record<K, T>, f: (x: T) => U): Record<K, U>;

... to enable types separated by key, while in this example we seem to have a single T/U for the whole (multi-key) function call.
So I get that this kind of separation could be achieved along the lines of example type T5 = { [P in keyof Item]: Item[P] };, but what's getting me stumped here is how to combine this with the generic function f: (x: T) => U. As in, I suppose U and T would at that point no longer have a single instance, but rather one per key. Would that still be possible?

[HerringtonDarkholme]

As in, I suppose U and T would at that point no longer have a single instance, but rather one per key.

I don't know whether it is possible in the long term. But it is impossible for now.

declare function mapObject<T, V, M extends {[k: string]: T}>(func: (v: T) => V, m: M): {[K in keyof M]: V} 

You can try this for now. It's the best of status quo.

[KiaraGrouwstra]

Thanks! That'll do for now then. :D
@mhegazy, if this could still be considered an open feature request, would you perhaps reconsider the question tag?

[mhegazy]

@mhegazy, if this could still be considered an open feature request, would you perhaps reconsider the question tag?

Mapped types should enable these scenarios. The change needed is to update the declaration files. if there are other ones that are not covered please provide more information about why mapped types is not sufficient.

[KiaraGrouwstra]

@mhegazy: I apologize, I'll admit my original example ended up not covering the breadth of my intended result. I've tried to update it accordingly.
The essence here is covered by the

U and T would no longer have a single instance, but rather one per key

.. which HerringtonDarkHolme stated is not presently possible.

Note that this becomes relevant in my (updated) example as different keys end up with different value types, dependent on both the transforming function (e.g. arrayify but could be anything) and the types of the input values.
Presently, input values are assumed to share the same type, and thus result types are only evaluated once (rather than per key) as well.