Typescript - тип безопасный глубокий пропуск, или: как перечислить допустимые пути к объектам

Хорошо, это длинный и очень конкретный. Был бы очень признателен за любой вклад.

Я написал рекурсивный тип Omit, который принимает тип T и кортеж строк («путь») и индексирует в T, удаляя последний элемент на пути и возвращая этот тип.

Я уже смотрел Deep Omit With Typescript, но это касается рекурсивного пропуска одного и того же ключа вместо того, чтобы идти по пути.

Я также просмотрел функцию безопасного пропуска типа, но это касается времени выполнения и это об одноуровневом опускании.

Моя реализация:

// for going along the tuple that is the path
type Tail<T extends any[]> = ((...args: T) => void) extends ((head: unknown, ...rest: infer U) => void) ? U : never;

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

Я хочу сделать так, чтобы Path был ограничен допустимым обходом T, например:

Path = [K1, K2, K3, ..., K_n] such that:
K1 extends keyof T, K2 extends keyof T[K1], ... Kn extends keyof[T][K1]...[K_(n-1)]

Первая попытка

Я написал тип, который принимает тип T и путь P и возвращает P, если он действителен, или never в противном случае:

type ExistingPathInObject<T, P extends any[]> = P extends [] ? P : {
    0: ExistingPathInObject<T[P[0]], Tail<P>> extends never ? never : P;
    1: never;
}[P[0] extends keyof T ? 0 : 1]

Однако в подписи DeepOmit я не могу применить Path extends ExistingPathInObject<T,Path>, поскольку это циклическая зависимость. Я упоминаю об этой попытке, потому что может быть способ обойти замкнутость и использовать этот тип для проверки Path как действительного обхода T.

Вторая попытка

Поскольку я не могу использовать Path для ограничения себя, я вместо этого попытался сгенерировать объединение всех существующих путей в типе, а затем потребовал Path для его расширения. Лучшее, что я мог придумать, это следующее:

type Paths<T> = {
    0: { [K in keyof T]: T[K] extends object ? [K, Paths<T[K]>[keyof Paths<T[K]>]] : [K] }
    1: []
}[T extends object ? 0 : 1];

// an example type to test on
type HasNested = { a: string; b: { c: number; d: string } };

type pathTest = Paths<HasNested>;
//{
//  a: ["a"];
//  b: ["b", ["d"] | ["c"]];
//}

type pathTestUnion = Paths<HasNested>[keyof Paths<HasNested>]
// ["a"] | ["b", ["d"] | ["c"]]

Это позволяет мне сопоставить путь, записанный в виде дерева: ['a'] extends pathTestUnion и ['b', ['d']] extends pathTestUnion оба истинны. Мне нужно добавить [keyof T], чтобы получить объединение, и я не могу поместить его в сам тип Paths, потому что он не распознается как действительный.

После всего этого у меня возникли трудности с переписыванием DeepOmit, чтобы использовать это ограничение. Вот что я пробовал:

type Types<T> = T[keyof T];

type TypeSafeDeepOmit<T, Path extends Types<Paths<T>>, K extends keyof T> =
    Path extends any[] ?
    T extends object ?
    { // T is object and Path is any[]
        0: Omit<T, K>;
        1: { [P in keyof T]: P extends Path[0] ? TypeSafeDeepOmit<T[P], Path[1], Path[1][0]> : T[P] }
    }[Path['length'] extends 1 ? 0 : 1] :
    T : // if T is not object
    never; // if Path is not any[]

type TSDO_Helper<T, P extends Types<Paths<T>>> = P extends any[] ? P[0] extends keyof T ? TypeSafeDeepOmit<T, P, P[0]> : never : never;

Это уродливо, и на самом деле он использует вспомогательный тип. Я также должен сообщить компилятору, что P extends any[] и P[0] extends keyof T, хотя это именно то, что Paths должно гарантировать. Я также получаю сообщение об ошибке при рекурсивном вызове TypeSafeDeepOmit с использованием Path[1] -

Type 'any[] & Path' is not assignable to type '[]'.
        Types of property 'length' are incompatible.
          Type 'number' is not assignable to type '0'

Я исправил это, установив Path extends Types<Paths<T>> | [], но я не уверен, что это правильный способ.

Вкратце

Итак, есть ли лучший способ обеспечить правильный путь? Можно ли также поддерживать объединение путей, чтобы исключить их все? Прямо сейчас результат, который я получаю, представляет собой объединение результатов различных пропусков.


person Ran Lottem    schedule 13.05.2019    source источник
comment
хех, это беспорядок ????. Обычно в таких случаях я просто выбираю максимальную глубину (4 или 5 уровней) и разворачиваю свои рекурсивные типы до этой глубины, а затем выхожу из игры. В настоящее время не существует поддерживаемого метода для таких рекурсивных типов. В настоящее время официальное слово - не делать то, что вы делаете с type R<T> = { 0: X, 1: F<R<T>> }[T extends Y ? 0 : 1]. Не знаю, мог ли я придумать что-нибудь менее уродливое, чем то, что есть у вас.   -  person jcalz    schedule 13.05.2019
comment
24 часа с момента обнаружения этого рекурсивного «взлома» до выяснения того, что это не рекомендуется. Ну, по крайней мере, это был интересный эксперимент! Спасибо за ссылки и ваш вклад :)   -  person Ran Lottem    schedule 13.05.2019


Ответы (1)


Это слишком долго для комментария, но я не знаю, считается ли он ответом.

Вот действительно неприятное преобразование (со многими возможными крайними случаями) от объединения опусканий к множественному опусканию:

type NestedId<T, Z extends keyof any = keyof T> = (
  [T] extends [object] ? { [K in Z]: K extends keyof T ? NestedId<T[K]> : never } : T
) extends infer P ? { [K in keyof P]: P[K] } : never;

type MultiDeepOmit<T, P extends string[]> = NestedId<P extends any ? DeepOmit<T, P> : never>

Способ его работы (если он действительно работает) состоит в том, чтобы взять объединение, подобное {a: string, b: number} | {b: number, c: boolean}, и использовать только те ключи, которые существуют во всех составляющих объединения: {b: number}. Это сложно сделать, и это нарушает необязательные свойства и неизвестно что еще.

Удачи, извините за отличный ответ.

person jcalz    schedule 13.05.2019
comment
Это интересно, мне нужно пройтись по различным частям и убедиться, что я их понимаю. Похоже, что в конце вы делаете вывод P только для того, чтобы восстановить его, я полагаю, это еще не все. Обратите внимание, что в этой версии путь представляет собой строковый кортеж, а не вложенные пути, которые я смог сгенерировать. - person Ran Lottem; 13.05.2019
comment
Что ж, вы можете изменить ограничение на P в MultiDeepOmit, не влияя на его работу. В NestedId грузовик вывода и восстановления предлагает компилятору вывести конкретный тип объекта, если это возможно, вместо группы псевдонимов типов. - person jcalz; 14.05.2019
comment
Я заменил NestedId на extends infer P ? P ... и не увидел других результатов для нескольких базовых типов, которые я создал для игры. Можете ли вы объяснить, как будут выглядеть псевдонимы типов, сгенерированные в противном случае? К сожалению, я пока не могу это проверить. - person Ran Lottem; 14.05.2019
comment
Если вы собираетесь это сделать, вы можете просто заменить (XXX) extends infer P ? P : never на XXX. Это тоже нормально. Кажется, действительно зависит от среды, которую я использую, показывает ли IntelliSense что-то вроде {a: NestedId<{c: string}>, b: NestedId<{d: number}>} или {a: {c: string}, b: {d: number}}. Уловка (XXX) extends infer P ? {[K in keyof P]: P[K]} : never-map обычно заставляет меня использовать последнее во всех случаях, но если в вашей среде это не нужно, я бы не стал об этом беспокоиться. - person jcalz; 14.05.2019
comment
Да, очевидно, нет необходимости делать вывод P, если я не манипулирую им, это был просто тест, чтобы увидеть, как эти псевдонимы будут выглядеть в отличие от конкретного типа. Я думаю, что столкнулся с этой проблемой (например, увидел Pick<{...},'c'> вместо результирующего типа), так что это полезный трюк, который нужно знать! - person Ran Lottem; 14.05.2019