Designations for removing an item at a targeted subdirectory location

Question

Designations for removing an item at a targeted subdirectory location

type Taillet<T extends any[]> = ((...t: T) => void) extends ((
  h: any,
  ...r: infer R
) => void)
  ? R
  : never;

type NestedOmit<T, Path extends string[]> = T extends object
  ? {
      0: Omit<T, Path[0]>;
      1: {
        [K in keyof T]: K extends Path[0] ? NestedOmit<T[K], Taillet<Path>> : T[K];
      };
    }[Path['length'] extends 1 ? 0 : 1]
  : T;

The defined type above functions properly. I have validated it using the following method:

type Test = NestedOmit<{ a: { b: { c: 1 } } }, ['a', 'b', 'c']>;

// {
//    a: {
//        b: Pick<{
//            c: 1;
//        }, never>;
//    };
// }

However, when implementing this within a function, the expected result is not obtained.

const remove = <T extends object, K extends string[]>(src: T, path: K) => {
  // custom logic omitted. only constructing the result below.
  const outcome = {
    a: {
      b: {}
    }
  }
  return result as NestedOmit<T, K>
};

const modifiedObject = remove({a:{b:{c:1}}},["a","b","c"]);
// modifiedObject.a.b.c <========== still works
// desired output is modifiedObject.a.b

Could anyone identify the issue in this scenario?

typescript typescript-generics

Answer 1

Answer №1

The issue you're encountering is due to the compiler's tendency to transform tuples into arrays and literals into nonliterals unless specific hints are provided. The caller of del() has the option to utilize an as const assertion on the path parameter in order to achieve this effect (although it requires accepting readonly string[] instead of just string[]), but ideally, the caller shouldn't have to worry about this. I've submitted a request on microsoft/TypeScript#30680 for something like as const on the call signature to handle this. Without such a feature, using unconventional hints becomes necessary.

If you want an array type to be inferred as a tuple whenever possible, it's advisable to include a tuple type in its context, such as within a union. Thus, T extends Foo[] would become T extends Foo[] | []. Similarly, if you prefer a type to be inferred as a string literal when feasible, incorporating a string literal or another hint resembling a string is recommended. As a result, T extends string[] can be modified to

T extends (string | (""&{__:0}))[]

, or preferably, T extends N[] where N serves as another generic parameter defined as N extends string. Here's how it looks:

declare const del: <T extends object, K extends N[] | [], N extends string>(
    src: T, path: K
) => DeepOmit<T, K>;

You can observe it functioning as intended:

const deletedObj = del({ a: { b: { c: 1 } } }, ["a", "b", "c"]);
deletedObj.a.b; // valid
deletedObj.a.b.c; // error

Furthermore, it's worth noting that the implementation of your DeepOmit could be simplified; the technique involving

{0: X, 1: Y}[T extends U ? 0 : 1]

is used to bypass circular errors with T extends U ? X : Y, even though this workaround is not officially supported. However, creating DeepOmit directly does not violate these rules: a recursive type with recursion occurring within an object property is acceptable:

type DeepOmit<T, Path extends string[]> = T extends object ?
    Path['length'] extends 1 ? Omit<T, Path[0]> : {
        [K in keyof T]: K extends Path[0] ? DeepOmit<T[K], Tail<Path>> : T[K];
    } : T; // no error, still works

Hopefully, this information proves helpful; best of luck!

Link to Playground Code

Answer 2

The issue you're encountering is due to the compiler's tendency to transform tuples into arrays and literals into nonliterals unless specific hints are provided. The caller of del() has the option to utilize an as const assertion on the path parameter in order to achieve this effect (although it requires accepting readonly string[] instead of just string[]), but ideally, the caller shouldn't have to worry about this. I've submitted a request on microsoft/TypeScript#30680 for something like as const on the call signature to handle this. Without such a feature, using unconventional hints becomes necessary.

If you want an array type to be inferred as a tuple whenever possible, it's advisable to include a tuple type in its context, such as within a union. Thus, T extends Foo[] would become T extends Foo[] | []. Similarly, if you prefer a type to be inferred as a string literal when feasible, incorporating a string literal or another hint resembling a string is recommended. As a result, T extends string[] can be modified to

T extends (string | (""&{__:0}))[]

, or preferably, T extends N[] where N serves as another generic parameter defined as N extends string. Here's how it looks:

declare const del: <T extends object, K extends N[] | [], N extends string>(
    src: T, path: K
) => DeepOmit<T, K>;

You can observe it functioning as intended:

const deletedObj = del({ a: { b: { c: 1 } } }, ["a", "b", "c"]);
deletedObj.a.b; // valid
deletedObj.a.b.c; // error

Furthermore, it's worth noting that the implementation of your DeepOmit could be simplified; the technique involving

{0: X, 1: Y}[T extends U ? 0 : 1]

is used to bypass circular errors with T extends U ? X : Y, even though this workaround is not officially supported. However, creating DeepOmit directly does not violate these rules: a recursive type with recursion occurring within an object property is acceptable:

type DeepOmit<T, Path extends string[]> = T extends object ?
    Path['length'] extends 1 ? Omit<T, Path[0]> : {
        [K in keyof T]: K extends Path[0] ? DeepOmit<T[K], Tail<Path>> : T[K];
    } : T; // no error, still works

Hopefully, this information proves helpful; best of luck!

Link to Playground Code

Answer 3

Answer №2

The issue arises from the type inference of the second argument. While the type example is defined as strict like ['a','b','c'], during function execution, the argument is inferred as string[]. This results in your type level function DeepOmit being called with string[] instead of ['a','b','c']. The outcome remains the same:

type Result = DeepOmit<{ a: { b: { c: 1 } } }, string[]>;

To resolve this issue, we can either strictly type the variable by specifying ['a','b','c'] as ['a','b','c'], which can be verbose, or enhance the function to treat each argument separately (using spread syntax) for stricter checking. While this may slightly alter the function's API (possibly for the better 👍), it ensures that inference works as intended. Here's an example:

const del = <T extends object, K extends string[]>(src: T, ...path: K) => {
  // custom logic removed. just creating the result below.
  const result = {
    a: {
      b: {}
    }
  }
  return result as DeepOmit<T, K>
};

const deletedObj = del({ a: { b: { c: 1 } } }, 'a', 'b', 'c');
deletedObj.a.b.c // error no c !

Answer 4

The issue arises from the type inference of the second argument. While the type example is defined as strict like ['a','b','c'], during function execution, the argument is inferred as string[]. This results in your type level function DeepOmit being called with string[] instead of ['a','b','c']. The outcome remains the same:

type Result = DeepOmit<{ a: { b: { c: 1 } } }, string[]>;

To resolve this issue, we can either strictly type the variable by specifying ['a','b','c'] as ['a','b','c'], which can be verbose, or enhance the function to treat each argument separately (using spread syntax) for stricter checking. While this may slightly alter the function's API (possibly for the better 👍), it ensures that inference works as intended. Here's an example:

const del = <T extends object, K extends string[]>(src: T, ...path: K) => {
  // custom logic removed. just creating the result below.
  const result = {
    a: {
      b: {}
    }
  }
  return result as DeepOmit<T, K>
};

const deletedObj = del({ a: { b: { c: 1 } } }, 'a', 'b', 'c');
deletedObj.a.b.c // error no c !

Designations for removing an item at a targeted subdirectory location

Answer №1

Answer №2

Similar questions

Determine the type of a function to assign to the parent object's property

Troubleshooting the creation of migration paths in NestJS with TypeORM

Some files are missing when performing an npm install for a local package

What is preventing my function from retrieving user input from an ngForm?

Is it possible for TypeScript to automatically determine the type of an imported module based on its path?

Troubleshooting React/Jest issues with updating values in Select elements on onChange event

Attempting to utilize the setInterval function in Ionic 4 to invoke a specific function every second, unfortunately, the function fails to execute

Commit to choosing an option from a dropdown menu using TypeScript

Create a series of actions that do not depend on using only one occurrence of the WriteBatch class

What is the best way to hand off this object to the concatMap mapping function?

Efficiently search and filter items across multiple tabs using a single search bar in the Ionic 2

"Perform an upsert operation with TypeORM to create a new entry if it

Learn how to enhance a Vue component by adding extra properties while having Typescript support in Vue 3

Do TypeScript project references provide value when noEmit is used?

Enabling non-declarative namespaces in React using Typescript: A beginner's guide

Having trouble with Vue i18n and TypeScript: "The '$t' property is not recognized on the 'VueConstructor' type." Any suggestions on how to resolve this issue?

Why is the return type for the always true conditional not passing the type check in this scenario?

Angular firebase Error: The parameter 'result' is missing a specified type and is implicitly assigned the 'any' type

Enabling or disabling a button dynamically in Ionic based on a conditional statement

Transforming an ordinary JavaScript object into a class instance