Как обязать typescript допускать выполнения кода только в том случае, если два типа строго равны друг другу?

Question

[Никита]

Допустим, есть код такого вида:

class UserModel {
    // Все те поля, что есть у UserDTO 
    password: string;
} // Модель User в БД. 

class UserDTO {
    email: string;
}

const getUser = async (email: string): Promise<UserDTO> => {
     const user = await db.find(email); // Тип возращаемого объекта является UserModel

      return user; // UserModel не эквивалентен UserDTO, но TypeScript не считает это ошибкой.
}

Как не допустить того, чтобы typescript позволял возвращать в качестве UserDTO эквивалентный этому типу объект, за исключением того, что у этого объекта есть так же дополнительные поля, не описанные в UserDTO.

Answer 1

[Aetae]

Ответ: не использовать typescript.
Структурная типизация - суть typescript. Ты можешь нагугуглить всякие мерзкие костыли, но они не панацея и подведут в самый ответственный момент.

Comments

[Никита]

Предлагаете мне из Angular typescript вытащить?

[Aetae]

Никита, предлагаю мыслить в рамках структурной типизации. Тогда таких проблем не возникнет в принципе.

P.S. Ещё можно angular выкинуть нахрен, это оверинжинирнутое воплощение enterprise bullshit. // holywar

[Никита]

Aetae, вы не могли бы на моем примере продемонстрировать подобный тип мышления?

[Aetae]

Никита, легко: всё в вашем примере в порядке.

Если полностью совпадают типы всех полей - значит структура может использоваться именно таким образом. Если эти структуры разные - то они должны быть разными, одинаковые имена полей с одинаковым типами не должны описывать разные сущности.
Возможно нужно что-то уточнить использовав строковые литералы или enum'ы, возможно не стоит делать пустые классы состоящие только из полей...

[Никита]

Aetae, данный класс, состоящий только из полей, заменяет собой interface(или тип). Он мне нужен для того, чтобы шарить типы между клиентской и серверной частью, я не могу от него отказаться.

[WbICHA]

Никита, так а что мешает использовать интерфейс?

[WbICHA]

А вообще Aetae всё верно расписал. Я ещё добавлю, что ТСа в рантайме нету, соответственно сделать проверку на типы и не получится.
Единственное, что могу предложить, это делать проверку на отсутствующие в нужном объекте поля и кидать ошибку, если они есть.

[Никита]

WbICHA, а какая разница использовать interface или class при данной проблеме? Классы, подобные UserDTO, я использую в runtime для валидации входных данных.

[Никита]

WbICHA, мне и не нужен TS в runtime.

[Никита]

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

[Aetae]

Никита, то что так делать нельзя из-за самой сути языка - тебе сказали. Что ты мыслишь неправильно, а потому натыкаешься на такие задачи в принципе - тоже. Что можно попробовать сделать - посоветовали. Ссылку на говно и костыли - и ту дали.
Чего ты хочешь то ещё? Чтоб кто-то слетал на машине времени и изменил саму концепцию typescript'a до начала разработки или заставил разработчиков angular выбрать flow?

[Никита]

Aetae, я вам лишь дал уточнение, что класс выступает в качестве типа.
Мне очень интересно, как вы сможете проявить "правильное" мышление, чтобы не возникло подобной задачи и проблем с типизацией, дерзайте:

router.get('/', (req, res) => {
  const user = await db.find(email);
  return user;
});

[Aetae]

Никита, ещё раз. Я не считаю это проблемой. Вообще.
Конструкция

const getUser = async (email: string): Promise<UserDTO>

говорит нам что из функции придёт объект обладающий полями UserDTO. UserModel обладает полями UserDTO? Обладает. Значит всё верно. Типы совместимы. Наличие всех полей UserDTO в UserModel гарантирует, что дальнейшая передача объекта в любые функции работающие с UserDTO не приведёт ни к каким ошибкам исполнения. В чём и есть задача typescript.
Если UserModel не эквивалентен UserDTO - это должны быть отражено в типе.

Answer 2

[Lynn «Кофеман»]

Самый простой способ — сделать типы неравными. Например так:

class UserModel {
    email: string;
    password: string;
}

class UserDTO {
    protected __guard: never; // добавляем фиктивное поле
    email: string;
}

const getUser = async (email: string): Promise<UserDTO> => {
  const user = await db.find(email);
  return user; // Ошибка, как заказывали
}

Comments

[Никита]

Спасибо за ответ, но проблема остается.
Мне нужно не допустить выполнение кода в случае, если есть лишние поля:

const user = await db.find(email);
return user; // Ошибка

Но допустить, если объект будет полностью эквивалентен типу:

const {  ...password, email } = await db.find(emai);
return user; // Ошибки нет.

[Lynn «Кофеман»]

Никита, Ну, как уже сказано выше, в общем случае задача не решаема.
Один из костылей, например если нас на самом деле волнует только что бы пароль случайно не утёк, явно запретить поле password в ответе функции.

https://www.typescriptlang.org/play?strictProperty...

Но вообще, я согласен с оратором выше, это просто плохой код и не нужно так писать.

[Никита]

Lynn «Кофеман», проблема в том, что код выше - это абстрактный пример, и писать код в другом виде, чем тот, что представлен ниже, я не могу:

router.get('/', (req, res) => {
  const user = await db.find(email);
  return user;
});

[Lynn «Кофеман»]

Никита,
Никто не мешает написать return convertUserToDTO(user);