Можно ли отрицать прямое использование javascript свойств в машинописи? - PullRequest
3 голосов
/ 17 февраля 2020

У нас часто есть объекты, расширяющие kendo.data.ObservableObject.

Можно определить / переопределить 'get' и 'set', чтобы иметь более строгие типы, гарантируя, что ключ существует в свойстве перед использованием set или получить (следовательно, получить информацию о типе того, что вы получите).

get<T extends ObservableObject, K extends keyof T>(this: T, name: K): T[K];
set<T extends ObservableObject, K extends keyof T>(this: T, name: K, value: T[K]): void;

Однако, если что-то полагается на динамическую c природу get / set, это приведет к ошибке, хорошему или плохо в зависимости от контекста.

set приведет к тому, что kendo отправит событие, чтобы обновить любых подписчиков наблюдаемого объекта.

Однако люди имеют привычку устанавливать их напрямую, используя

class X extends ObservableObject { s:string = "";}

X.s = "set a string";

Который (насколько мне известно) преднамеренно не создает событие.

Однако использование переменной прямой поддержки является привычкой, которую трудно сломать.

Можно ли с помощью Typescript создать тип / класс, который делает невозможным непосредственное задание значений? вместо этого полагаясь на метод setNoEmit вместо этого? таким образом, для младших разработчиков больше невозможно совершить ошибку обновления наблюдаемого без запуска события, и им приходится принимать сознательное решение между set и setNoEmit?

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

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