Как в TS задать интерфейс объекта, в котором key === value?

Question

[Return Me Void]

Дан такой тип, в котором указано, что ключ в объекте и его значение должны быть равны:

type MyType<T extends string> = {
  [K in T]: K;
};

Как преобразовать такой тип в интерфейс? Подойдёт даже без дженерика, главное чтоб соблюдалось правило равности key === value

Answer 1

[Alexandroppolus]

С генериком, похоже, нельзя. Без генерика можно через наследование:

type MyType<T extends string> = {
  [K in T]: K;
};

interface IMyInt extends MyType<'qq' | 'aa'> {}

Comments

[Return Me Void]

Перепрокинуть дженерик тоже не получается

имею ввиду сделать

interface IMyInt<T extends string> extends MyType<T> {}

[Alexandroppolus]

Return Me Void, никак. Интерфейсы любят полную определенность в наборе своих ключей)

кстати, почему понадобился именно интерфейс?

[Return Me Void]

Alexandroppolus, класс делаю, в вопросе упростил до интерфейса)

[WbICHA]

Return Me Void, если я всё правильно помню, то тс в классах только статические свойства допускает. С другой стороны, а зачем в классе вообще динамические свойства? Если так нужны, можно просто отдельное свойство добавить, в котором и будет объект с нужными свойствами.
Есть, конечно, костыльный вариант через статический метод создания инстанса, тогда можно тип подправить, но... Опять же, зачем, ты всё равно к этим свойствам даже обратиться нормально не сможешь.
В целом, какую задачу ты решаешь?

[Return Me Void]

WbICHA, объект, в котором значения равны ключам. Пишу класс для этого. Есть реализация через функцию создания объекта, но я хочу полноценный класс

[Alexandroppolus]

WbICHA,

можно просто отдельное свойство добавить, в котором и будет объект с нужными свойствами

я бы даже сказал, это единственный разумный вариант в данной задаче.

насыпать неизвестно каких ключей прямо в класс, где дополнительно могут быть ещё свои поля и методы - путь к анархии.

[WbICHA]

Return Me Void, я не буду спрашивать зачем тебе в целом такой объект, но я не понимаю, зачем тебе класс, в теле которого всякий мусор лежит? Для чего? Ты даже свои свойства и методы в него добавить не сможешь, потому что в любой момент они могут перезаписаться.
Откровенно говоря, всё это выглядит как костыль для костыля. А решение очень простое: просто сделать нормально.

[Return Me Void]

WbICHA, типизация для тебя мусор? ты странный.

представь объект { one: "one", two: "two", three: "three" }

это по сути обычный объект, но со своими правилами и жесткой типизацией. При чем в его задании легко ошибиться, поэтому делаю задание new MirrorObject(["one", "two", "three"])

Функция задания такого объекта и тип отдельно есть, но т.к. это структура данных, хочу объединить их в класс, а для этого нужно тип привести в интерфейс класса

[Alexandroppolus]

Return Me Void,

new MirrorObject(["one", "two", "three"])

почему тебе надо именно экземпляр класса, через new?
просто сделай функцию, которая по массиву сотворяет объект:

function createObj<const A extends string[]>(a: A): {[K in A[number]]: K} {
    return Object.fromEntries(a.map((v) => [v, v])) as {[K in A[number]]: K};
}

const obj = createObj(["one", "two", "three"]); // см. по ховеру

[WbICHA]

Return Me Void, ты так и не написал зачем тебе хранить динамические свойства в теле экземпляра класса.

[WbICHA]

Return Me Void,

типизация для тебя мусор? ты странный.

И да, я, может и странный, но я точно менее странный, чем человек, который находит в тексте то, на что даже намёка нет.

[Return Me Void]

Alexandroppolus, я же сказал, такая функция у меня уже есть, я и хотел её использовать в качестве конструктора. И в прошлом комменте я объяснил, зачем захотел сделать это в классе

[Return Me Void]

WbICHA, видимо мы друг друга не понимаем, объясни другими словами.

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

[WbICHA]

Return Me Void, ничего. Ещё раз повторю вопрос: зачем тебе динамические значение в экземпляре класса? Назови хотя бы одну причину, по которой ты не можешь запихнуть их в отдельное свойство класса.
На данный момент, исходя из описания, ты хочешь получить объект, но объект != класс и класс != объект. Инстанс класса — да, по факту объект, но если использовать инстансы класса как объекты, то... Можно, но это как микроскопом гвозди забивать. И из-за этого (имхо) в тс и сделали это ограничение.

И, всё же, утоли моё любопытство, пожалуйста, для чего тебе такой объект (ключ = значение)?

[Return Me Void]

WbICHA, предложи своё решение в таком случае.

И, всё же, утоли моё любопытство, пожалуйста, для чего тебе такой объект (ключ = значение)?

на работе в проекте такие объекты вместо enum'ов (видимо, чтобы можно было итерироваться по ним), хочу сделать побольше контроля над ними - часто опечатки делаются при их задании

[WbICHA]

Return Me Void,

на работе в проекте такие объекты вместо enum'ов

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

export const SomeEnum = {
  HOME: 'home',
  CAR: 'car'
} as const satisfies Record<string, string> 
export type SomeEnum = typeof SomeEnum[keyof typeof SomeEnum]

Привязывать строго название свойств к значениям не стоит, энумы подразумевают свои правила. Впрочем, это, конечно, не является обязательным. Ключевое тут другое: возможность использовать энум как тип напрямую используя имя энума.
Что-то тут автоматизировать смысла мало (или вы каждую неделю новый энум создаёте?), тем более, что создание типа всё равно особо не автоматизируешь, НО функцию-генератор сделать всё же можно (класс тут вот вообще никаким боком не подходит, откровенно говоря, он просто не предназначен для этого).

часто опечатки делаются при их задании

Но вот этот момент я вообще не понял. Если функция-генератор у тебя уже есть, то откуда опечатки? Если в значениях, то тут в любом случае от них не защититься никак вне зависимости от реализации. А где ещё она может быть — непонятно, ведь ты передаёшь только значения в функцию (во всяком случае должен, если правильная реализация). А массив значений тебе в любом случае вручную составлять.

Так что лучше скинь текущую реализацию сюда (или возьми решение Alexandroppolus выше), поскольку, судя по всему, ты борешься со следствием, а не с причиной.

[Return Me Void]

WbICHA,

Но вот этот момент я вообще не понял. Если функция-генератор у тебя уже есть, то откуда опечатки?

я её сделал, пытаясь решить эту проблему, в проекте такие объекты прописывались везде вручную

[Return Me Void]

WbICHA, слушай, а я думал что ts будет ругаться, если сделать тип таким же именем, как имя константы

потому что когда делал тип по имени класса, он ругался

это решает одну из проблем - за это респект

[Alexandroppolus]

Return Me Void,

потому что когда делал тип по имени класса, он ругался

тут ругается из-за того, что класс сам по себе ещё и тип, в отличии от константы, и в итоге два типа конфликтуют

[Return Me Void]

Alexandroppolus, да, я так и понял