Как типизировать созданные геттеры?

Question

[historydev]

export class User {
    private readonly props: UserProps;

    constructor(props: UserProps) {
        this.props = userSchema.parse(props);

        for (const key of Object.keys(props) as Array<keyof UserProps>) {
            Object.defineProperty(this, key, {
                get: () => this.props[key],
                enumerable: true,
            });
        }
    }
}

const user = new User({firstname: 'John', /* other fields */});
console.log(user.firstname); // TS2339: Property firstname does not exist on type User

Comments

[WbICHA]

Классы не для генерируемых свойств в рантайме. Для чего тебе тут вообще класс нужен?

[historydev]

WbICHA, Доменная сущность в слоёной архитектуре, нужно много методов с валидацией по схеме, меня самого тянет на функциях сделать т.к. это намного проще, но кажется что логичней класс использовать, однако столкнулся с дублированием, а полей 30+ и это нонсенс.

[historydev]

WbICHA, Планируется примерно следующая схема:

const user = userRepository.getById(123); // get user from db, return User
user.changeFirstname('John2'); // validate, write
userRepository.save(user); // update user in db

[WbICHA]

historydev, опять же, в классе только статика. Если хочется классы, запихни в свойство класса сгенерированные геттеры (к примеру, в value или просто v) и бери через него, там уже и типизировать всё можно.
Впрочем, зачем тебе вообще геттеры в данном случае не очень понимаю, можешь объект ридонли сделать, зафризить даже. Или же вообще ничего не делать, всё равно с базы тебе уникальный объект придёт, можешь его мутировать как душе угодно и сохранять его.
Если очень хочется, то можно в прокси обернуть и всякие changeFirstname в принципе ненужны будут.
Можно и по другому сделать, добавить общий гет и сет и через них работать (к примеру, как в цуштанде).

Вариантов море, на самом деле, это лишь то, что я сходу вспомнил.

[historydev]

WbICHA, геттеры нужны на случай если исходное имя поля изменится, чтобы ничего в публичном апи не сломалось.

Или же вообще ничего не делать, всё равно с базы тебе уникальный объект придёт,

- Это понятно, но изменяться будет он-же, он же и хранит логику для полей.

Прокси хорошо - но от дублирования не спасает, а это основная проблема сейчас.

хочется классы, запихни в свойство класса сгенерированные геттеры

- Потеряется user.field, user.v.field странно выглядит.

[WbICHA]

historydev,

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

И как тебе с этим помогут геттеры? У тебя они напрямую от имени зависят. А если ты хочешь, чтобы к новому имени свойства по старому могли обращаться, так это ещё хуже. Да и как часто у тебя имя полей меняться собрались?

Это понятно, но изменяться будет он-же, он же и хранит логику для полей.

Какая у полей логика? Это просто запись из бд, оформленная в виде объекта, там никакой логики нет. Можно, конечно, сделать свой аналог тайпорм со специальным наследуемым классом, но там свободно можно объект мутировать и никому это не мешает.

Прокси хорошо - но от дублирования не спасает, а это основная проблема сейчас.

Ммм? О каком дублировании в случае прокси идёт речь? Он как раз и создан для динамического обращения к ключам.

Потеряется user.field, user.v.field странно выглядит.

Согласен, именно поэтому я бы и не использовал здесь классы.

[historydev]

WbICHA
Alexandroppolus

Запутался. Вот подробности:

Слоёная архитектура:
presentation (1)
application (2)
domain (3)
repository (4)
model (5)

Всё кроме model, по задумке, классы с методами.

* - множество

1.method => 2.method* => 3.method* => 4.method* => model

1 - просто принимает запросы и вызывает нужный сценарий из 2 или что-то конкретное из 3.
2 - хранит сценарии где пересекаются несколько сервисов из 3, чтобы не создавать циклических зависимостей.
3 - хранит бизнес-логику, диктует интерфейс 4, вызывает 4
4 - абстракция для 5
5 - база / orm

Класс User в этом случае находится в 3, он должен инкапсулировать своё состояние и бизнес-логику.
- Возможно я изначально пошёл не туда.

const user = userRepository.getById(123);
user.changeFirstname('John2'); // проверяем вход => записываем в User.firstname
userRepository.save(user);

Что не так с классами?
- Объект поставит меня ровно в туже ситуацию, ведь класс это синтаксический сахар над ним.

[WbICHA]

historydev,

user.changeFirstname('John2'); // проверяем вход => записываем в User.firstname

И какие ты там проверки собрался добавлять и инкапуслировать?) Это же просто запись из бд, зачем тут лишнее усложнение?

[historydev]

WbICHA, И где в таком случае мне эти проверки делать?

[WbICHA]

historydev, какие именно? У тебя в примерах никаких проверок нет, да и какие ты проверки хочешь добавить, если свойства и, очевидно, методы генерируешь?

[WbICHA]

historydev, и да, любые проверки можно делать на этом этапе: userRepository.save(user);

[historydev]

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

[historydev]

WbICHA,

любые проверки можно делать на этом этапе: userRepository.save(user);

- Нарушает разделение ответственности.

[WbICHA]

historydev, зависит от проверок. Я всё ещё не понимаю что у тебя там за проверки должны быть. У тебя в любом случае должна быть валидация при сейве.

[historydev]

WbICHA, 2 типа проверок:
1. Валидация
2. Бизнес-правила

1. Баланс это число
2. Баланс не может быть меньше нуля

[WbICHA]

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

[historydev]

WbICHA, Нет. Я же по цифрам специально разделил:
Валидация - Баланс это число.
Бизнес-правило - Баланс не может быть меньше нуля.

Мне нужно чтобы части системы легко заменялись.

[WbICHA]

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

Answer 1

[Alexandroppolus]

Я тоже не совсем понял, почему нужен именно класс, но если уж приспичило, то типизировать можно так: ссылка

и поскольку у тебя фиксированный набор полей, то лучше однократно навесить геттеры на прототип этого класса. То есть на User.prototype. Будет экономичнее при создании множества экземпляров. Только функцию для геттера сделать не стрелочной

Comments

[WbICHA]

Прикольно, интересный лом.)
Забыл, что декларацию класса можно в переменную записать.

[Alexandroppolus]

WbICHA, вся стандартная библиотека именно так и типизирована, я оттуда взял идею и даже нейминг. Посмотри, например, interface Array {...}, interface ArrayConstructor {...} и declare var Array: ArrayConstructor; в файле lib.es5.d.ts

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

[WbICHA]

Alexandroppolus, прикольно.) Я, правда, уже давно перестал копаться в тсе, поднадоело как-то.

[Alexandroppolus]

WbICHA, аналогично.. Я на тайп-челленджах сто лет ничего не решал. Пробовал добавить там парочку своих паззлов, но судя по всему владельцы t-ch тоже на него забили и не публикуют новое. Художественный тайпскрипт - всё