Typing for object deep paths

[wclr]

Recently introduces keyof operator will work well for typing functions that accept properties directly on target type.

interface Some {
 a: number,
 b: string
}

type oneOfTheSomeKeys = keyof Some // restricts value to "a", "b"

What do you think, is it possible in theory to type deeply nested paths, so that for type:

interface Some {
 a: number,
 b: {
 c: number
 d: {
 e: number
 }
 }
}

so that it would be possible to restrict possible path values to:

["a"]
["b"]
["b", "c"]
["b", "d"]
["b", "d, "e"]

This actual for such methods like ramda's path:

R.path(['a', 'b'], {a: {b: 2}}); //=> 2
R.path(['a', 'b'], {c: {b: 2}}); //=> undefined

?

[HerringtonDarkholme]

You can already do that with manual overloading.

// overload more type parameter arity here
function path<A extends string, B extends string, C extends string, D>(path: [A, B, C], d: {
 [K1 in A]: {[K2 in B]: {[K3 in C]: D}}
}) {
 let ret = d
 for (let k of path) {
 ret = ret[k as string]
 }
}

path(['a', 'b', 'c'], {a: {b: 2}}) // error
path(['a', 'b', 'c'], {a: {b: {c: 2}}})

[wclr]

Herrington Darkholme (@HerringtonDarkholme) oh that is really really nice, thanks for the example!

[aluanhaddad]

Herrington Darkholme (@HerringtonDarkholme) very slick

[KiaraGrouwstra]

Herrington Darkholme (@HerringtonDarkholme): thank you, that's pretty cool! I generated variants for different path lengths for Ramda, so if you'd like to use it, feel free. 😄
I tried to see if I could make your definition work with arrays as well, but so far I haven't had much luck.
Cases I'm hoping will work (or at least one of the two):

path(['a', '0', 'c'], {a: [{c: 2}] })
path(['a', 0, 'c'], {a: [{c: 2}] })

I tried to see if adjusting the definition might help to make this work out.

function path<A extends string, B extends number, C extends string, D>(path: [A, B, C], d: { // <- changed B to number
 [K1 in A]: {[K2 in B]: {[K3 in C]: D}} // <- `K2 in B` now errors: "Type 'number' is not assignable to type 'string'"
}) {
 // implementation detail
}

I suppose with {[K2 in B]: ...} this is being considered an object using a string-based index, making numerical indices (as used by arrays) fail. Perhaps this is implied by the in notation?

[wclr]

@tycho01

To make this:

path(['a', '0', 'c'], { a: [{ c: 2 }] })
path(['a', 0, 'c'], { a: [{ c: 2 }] })

work, typings should be something like that:

// for level 1 array
function path<A extends string, B extends string | number, C extends string, D>
 (path: [A, B, C],
 d: {[K1 in A]: {[K2 in C]: D}[]}
 ): D

// for object
function path<A extends string, B extends string | number, C extends string, D>
 (path: [A, B, C],
 d: {[K1 in A]: {[K2 in B]: {[K3 in C]: D}}}
 ): D


function path(path: any, d: any): any {
 let ret = d
 for (let k of path) {
 ret = ret[k]
 }
}

The problem that it is not possible to do it withing a single signature for example like:

 d: {[K1 in A]: {[K2 in B]: {[K3 in C]: D}}} | {[K1 in A]: {[K2 in C]: D}[]}

So if to still implement it there would be a need to have multiple combinations:

A: O : O : O 
A: A : O : O 
...
O: A : O : O 
...

You get it. But it is not impossible though.

[KiaraGrouwstra]

Yeah, the exploding number of variants is a tad unfortunate, but for the moment should do if I can try to generate them.
I guess technically the [] approach still presents an asymmetry between the objects and array versions, by constraining the arrays to be homogeneous lists, as opposed to say tuples, while the objects do not appear bound that way.
That said, this progress is pretty great! I'll try to incorporate your idea for the Ramda function. :D

[wclr]

Yes it seem that is also case with tuples which makes typing issue unsolvable for general case.

[KiaraGrouwstra]

Renamed in favour of (@whitecolor): made a commit for path lengths 1~7 (-> index.d.ts). Lotta code to get one extra test to pass, with still dozens others failing (not to mention the ones silently 'failing' with any types). Worth it!
Can't wait to see what it'd look like if it is to handle tuples as well!

[wclr]

Herrington Darkholme (@HerringtonDarkholme) or somebody

any advice how this can be typed, function that gets two key names and object and checks if first key is string, and second is number:

function checkTypesOfKeys<
 KeyS extends string, KeyN extends string>
 (keyS: KeyS, keyN: KeyN,
 obj: {[K in KeyS]: string} & {[K in KeyN ]: number}): boolean // this doesn't work
{
 return typeof (<any>obj)[keyS] === 'string'
 && typeof (<any>obj)[keyN] === 'number'
}

checkTypesOfKeys('str', 'num', {str: 'stringValue', num: 1}) // error

 Type '{ str: string; num: number; }' is not assignable to type '{ str: string; num: string; }'.

[KiaraGrouwstra]

Renamed in favour of (@whitecolor): what if you make that KeyN into number?

On that path definition I generated for Ramda based on the overloading suggestion given here, I've come to the conclusion this not only brings monstrous typings that are still inadequate (ignoring tuples), but also brings along performance issues, grinding TS to a halt after adding a significant number of overloads. Evidently, just following the original reduce logic is O(n), so I hope they'll consider my proposal to implement that as a solution...

[wclr]

KeyN in my question I assume to correspond to second key name (key name is a string anyway) argument.

I hope they'll consider my proposal to implement that as a solution...

In 10 years maybe =)

[HerringtonDarkholme]

Renamed in favour of (@whitecolor)

The problem here is how TypeScript infer type argument. The KeyN and KeyM will be inferred against { str: string; num: number; } so that compiler will infer types compatible both with extends string and keyof typeof obj.

In such condition, KeyN is inferred as str | num. So the error.

One solution is using curry to help compiler infer type argument.

https://www.typescriptlang.org/play/index.html#src=function%20checkTypesOfKeys%3C%0D%0A%20%20KeyS%20extends%20string%2C%20KeyN%20extends%20string%3E%0D%0A%20%20(keyS%3A%20KeyS%2C%20keyN%3A%20KeyN)%3A%20(obj%3A%20%7B%5BK%20in%20KeyS%5D%3A%20string%7D%20%26%20%7B%5BK%20in%20KeyN%20%5D%3A%20number%7D)%20%3D%3E%20boolean%20%2F%2F%20this%20doesn%27t%20work%0D%0A%7B%0D%0A%20%20return%20(obj)%20%3D%3E%20typeof%20(%3Cany%3Eobj)%5BkeyS%5D%20%3D%3D%3D%20%27string%27%0D%0A%20%20%20%20%26%26%20typeof%20(%3Cany%3Eobj)%5BkeyN%5D%20%3D%3D%3D%20%27number%27%0D%0A%7D%0D%0A%0D%0AcheckTypesOfKeys(%27str%27%2C%20%27num%27)(%7Bstr%3A%20%27stringValue%27%2C%20num%3A%201%7D)