Пользовательские правила проверки нокаута с помощью TypeScript

Question

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

У меня есть настраиваемое правило для проверки выбывание:

ko.validation.rules["sameAs"] = { 
    validator: function (val, otherObservable) { 
     return val === otherObservable(); 
    }, 
    message: "Value should be same as {0}, but differs" 
}; 

Сейчас в сыром JavaScript это работало хорошо, как использование будет выглядеть так:

function SomeObject() { 
    this.Email = ko.observable().extend({ required: true, email: true }); 
    this.ConfirmationEmail = ko.observable().extend({ required: true, email: true, sameAs: this.Email }); 
} 

Однако сейчас в машинописном земле, если я попытаюсь написать это:

class SomeObject { 
    public Email = ko.observable().extend({ required: true, email: true }); 
    public ConfirmationEmail = ko.observable().extend({ required: true, email: true, sameAs: this.Email }); 
} 

теперь я получаю ошибку:

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

Answer 1

Я не могу найти какой-либо недостаток письма:

class SomeObject { 
    public Email = ko.observable(); 
    public ConfirmationEmail = ko.observable(); 

    constructor() { 
     this.Email.extend({ required: true, email: true }); 
     this.ConfirmationEmail.extend({ required: true, email: true, sameAs: this.Email }) 
    } 
} 

кроме 2 дополнительных строк кода.

На мой взгляд, читаемость кода немного лучше, вам не нужно читать всю длинную строку, чтобы увидеть, какой тип переменной она есть. Выполняя это разделение, вы можете лучше показать, что происходит в вашем коде. Может быть, это эстетическая вещь, но я считаю, что объявление смешивания переменных с выражением «extend» иногда трудно читать, особенно когда «extend» довольно ошибочно ... расширено :).