Proposal: support pathof along with current keyof

[agalazis]

Problem - What are users having difficulty with?

While using popular libraries for their day to day development needs, developers can find them disjoint from typesafe philosophy even if they do have the needed typings. This is true for frequently used libraries such as lodash and immutablejs that access or set properties via paths. It is up to the developers to to preserve typesafety by expressing complex types using the amazing power that typescript gives them. The only obstacle is the absence of a way to express the type that represnts legit object paths for a specific type.

Current state

We can currently do this only for shallow objects where paths can be simply expressed as the keys of a specific type.

Example Issue

In an effort to play with stricter typings for immutablejs map I created this tiny project :
https://github.com/agalazis/typed-map/
(as a side note my personal view is that immutable js map is not a conventional map that should be represented with map<keyType, valueType> since it represents a map that matches a specific type rather than just a key,value data structure as demonstarated in src/examples)

The type I created was just this (only playing with get and set):

export type TypedMap<T> = {
  get: <K extends keyof T >(k:K) => T[K];
  set: <K extends keyof T >(k:K, v:T[K]) => TypedMap<T>;
}

Simple enough, leveraging all the expressiveness of typescript.

Example usage of the proposed solution:

If I could replace keyof with pathof in order to express possible path strings and also used T[P] as the path type I would be able to completely cover this use-case :

export type TypedMap<T> = {
  get: <P extends pathof T >(p:P) => T[P];
  set: <P extends pathof T>(p:P, v:T[P]) => TypedMap<T>;
}

Possible usage in the following libraries:

• lodash
• immutable
• ramda
• anything built on top of them

Why bother since this does not involve facilitating any feature of ES standard?(and is somewhat an unconventional feature)

1. We will be able to perform type-safe updates using existing js immutability libraries similar to what you can achieve in other languages (eg. skala lense).
2. This feature complies with typescript goals:

• Statically identify constructs that are likely to be errors.
• Provide a structuring mechanism for larger pieces of code (the above-mentioned libraries are used every day in big projects imagine the chaos that can be created. Despite exhaustive unit testing, intellisense is a must ;) ).
• Strike a balance between correctness and productivity.

4. This feature improves compile time checks and sticks to the mindset of not having to deal with any runtime functionality
5. There are no side effects in the generated js code

Alternatives

While digging further into the issue an alternative solution is to be able to spread keyof recursively. This will allow us to be creative and build our own solution as per:
#20423 (comment)
The drawbacks of the alternative solution if doable are:

• performance
• lack of cyclic reference support

Implementation Suggestions

The optimal (if implemented in the language) would be to not compute the full nested object paths but only the paths used via pathof ie when declaring something as path of x just accept it as pathof x then when a value is assigned just validate it is pathOf x( the compiler could also have some sort of caching so that it doesn't recalculate paths).
This will also solve the issue with cyclic references since paths will be finite anw.

[noppa]

So, if I understand correctly, the idea is that you could have something like

var m: TypedMap<{ a: { b: number } }>;
var m2 = m.set('a.b', 42);

where 'a.b' would be of type pathof { a: { b: number } }.

You can already have type safety for a similar function

m.set('a', 'b', 42);

with the following type definition for TypedMap:

interface TypedMap<T> {
  get<K extends keyof T>(k: K): T[K];
  get<K extends keyof T, K2 extends keyof T[K]>(k: K, k2: K2): T[K][K2];
  get<K extends keyof T, K2 extends keyof T[K], K3 extends keyof T[K][K2]>(k: K, k2: K2, k3: K3): T[K][K2][K3];

  set<K extends keyof T>(k:K, v:T[K]): TypedMap<T>;
  set<K extends keyof T, K2 extends keyof T[K]>(k:K, k2: K2, v:T[K][K2]): TypedMap<T>;
  set<K extends keyof T, K2 extends keyof T[K], K3 extends keyof T[K][K2]>(k:K, k2: K2, v:T[K][K2][K3]): TypedMap<T>;
}

Now, this approach does have a few drawbacks, of course; the API isn't quite as neat and the supported depth of the objects is limited by the number of overloaded function definitions you are willing to write.

Still, most of the use cases you mention could be achieved with the current state of the type system.

Playground link.

[dmichon-msft]

One problem is that the following is completely legal:

interface A {
    a: boolean;
    b: 2;
    'a.b': string;
    '"a.b"': number;
}

type T1 = A['a']; // boolean
type T2 = A['a.b']; // string
type T3 = A["'a.b'"]; // string[]
type T4 = A['"a.b"']; // number

In fact, any path string you can possibly come up with is a fully legal keyof T for some T, so you'll run into collisions between the two.

[agalazis]

@noppa Thank you for contributing your thoughts yes the above is another way to approach this issue but as you mentioned, it has the depth limitation but also a productivity* issue(if we manually have to do all the overloading or rewrite typings for every type since depth is variable).
*TS goals: Strike a balance between correctness and productivity
You just demonstrated another way that cannot be used for shipping plug and play typings for the mentioned use case/libraries and confirmed my suspicion that this is not currently doable( a strong indication is also that none of the above-mentioned libraries supports such strict checks).
On the other hand, based on the comments, I started looking into a way of expressing the path as an array since path as array of keys is something commonly used:

type PathSetter<T, K extends keyof T ,P=K,M=TypedMap<T>> =  ( p:P, t: T[keyof T]) => M | PathSetter<T[K], keyof T[K], [P, ...keyof T[K]], M>
export type TypedMap<T> = {
  get: <K extends keyof T >(k:K) => T[K];
  set: <K extends keyof T >(k:K, v:T[K]) => TypedMap<T>;
  setIn: PathedSetter<T, keyof T>;
  
}

which won't work since I can't use spread operator on keys

[noppa]

My example would also work with tuple types, which might be closer to what you are looking for

interface TypedMap<T> {
  set<K extends keyof T>(k:K, v:T[K]): TypedMap<T>;
  set<K extends keyof T, K2 extends keyof T[K]>(k: [K, K2], v:T[K][K2]): TypedMap<T>;
  set<K extends keyof T, K2 extends keyof T[K], K3 extends keyof T[K][K2]>(k: [K, K2, K3], v:T[K][K2][K3]): TypedMap<T>;
}

declare var m: TypedMap<{ a: { b: number } }>;

var m2 = m.set(['a', 'b'], 42);

[agalazis]

Yes that's true but it should happen in a recursive way that's what I tried in my example above but since we cannot have spread operator on the array, it's not doable I guess.

[agalazis]

I think a possible solution could be blocked by:
#17884

[marshall007]

In addition to the libraries mentioned in the initial comment, something like this proposal is absolutely necessary in order to provide any sort of type checking on queries in the elasticsearch.js client driver.

The other very common use case I keep stumbling on is dot notation in query string parameters.

[Nimelrian]

This is an eagerly awaited feature for me! It would allow for much less headaches when dealing with utility functions designed to pull nested properties out of other types!

[Morglod]

Just implemented this feature
https://github.com/Morglod/ts-pathof

const c = { z: { y: { bb: 123 }}};
const path = pathOf(c, 'z', 'y', 'bb');
// path now is typeof [ 'z', 'y', 'bb' ]

const path2 = pathOf(c, 'z', 'y', 'gg'); // error, because no 'gg' field in c.z.y

Also types only approach:

let path: pathOf3<typeof c, 'z', 'y', 'bb'>;
path = pathOf(c, 'z', 'y', 'bb');

[KiaraGrouwstra]

Thanks for posting in the other thread, @Morglod. For reference to others, #12290 also discusses tackling similar functions.

fwiw, tackling m.set('a.b', 42) is far off currently -- the only operation we can do using string literal types is pretty much direct object navigation. for type-safety, it may currently be more realistic to stick with tuple-based variants (-> ['a', 'b']) like in e.g. Ramda.

I feel this problem is more general than just path-based navigation though -- similar challenges exist for lenses/traversals as well. Given that, I would advocate a more generic approach based on recursion, which I hope will gain further support.

@agalazis: I think #17884 actually ended up superseded by a recently merged PR by ahejlsberg! :)

[agalazis]

@tycho01 was it released? looking forward to giving it a shot