Уникальные значения свойств между экземплярами классов в JavaScript/TypeScript

Я вижу единственное решение с использованием Set для отслеживания уникальных имен

let usedNames = new Set<string>();
class ThingOne implements IThing {
    name: string;
    constructor(name: string) {
        if (usedNames.has(name)) {
            throw new Error(`Name "${name}" has already been used.`);
        }
        usedNames.add(name);
        this.name = name;
    }
}

TypeScript на самом деле не имеет встроенного способа гарантировать уникальность свойств в разных классах и даже не отслеживает, какие классы расширяют/реализуют другие классы/интерфейсы таким образом, чтобы разработчик мог запросить (структурный тип система означает, что класс может реализовать интерфейс, даже если вы не объявляете его как таковой, и поэтому набор вещей, реализующих интерфейс, потенциально бесконечен, в отличие от систем номинальных типов).

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

Один из возможных подходов состоит в том, чтобы хранить ваши классы в объекте реестра и добавлять каждый класс к объекту, вызывая функцию утверждения, которая проверяет новый класс на соответствие существующим на предмет правильности/уникальности, а также записывает эту информацию в тип объекта реестра через сужение. Может быть так:

interface IThing {
    name: string;
    prop: string;
    generate(): string;
}

type ValidateUniqueThing<TS extends IThing, T extends IThing> = {
    [K in "name" | "prop"]:
    string extends T[K] ? [Error, "Make", K, "readonly PLEASE"] :
    T[K] extends TS[K] ? [Error, "Conflicting ", K, "Property with class named ",
        Extract<TS, { [P in K]: T[K] }>["name"]] :
    T[K]
}

function registerThing<R extends Record<keyof R, IThing>, T extends IThing>(
    registry: { [K in keyof R]: new () => R[K] },
    name: T['name'],
    newThing: new () => (
        T extends ValidateUniqueThing<R[keyof R], T> ? T : ValidateUniqueThing<R[keyof R], T>
    )
): asserts registry is Extract<
    { [K in keyof R | T['name']]: new () => K extends keyof R ? R[K] : T },
    typeof registry
> {
    Object.assign(registry, { [name]: newThing });
}

Итак, служебный тип ValidateUniqueThing<TS, T> принимает объединение существующих Thing типов TS и кандидата на новое добавление T. Если T допустимое дополнение, то ValidateUniqueThing<TS, T> оценивается как T. В противном случае свойство T, которое нарушает правило, будет сопоставлено с несовместимым типом, отображаемая информация которого, как мы надеемся, даст разработчику некоторую информацию о том, как решить проблему.

Здесь возможны два основных возможных нарушения:

• Если свойство имеет тип string, а не литеральный тип , то компилятор понятия не имеет, каким на самом деле будет значение, и не сможет гарантировать уникальность. Обычно это происходит, когда вы инициализируете свойство строковым литералом, не помечая свойство как только для чтения, поэтому несовместимый тип упоминает readonly (но вы можете изменить это на что хотите).

• Если свойство уже существует в объединении существующих литеральных типов для того же свойства в других зарегистрированных классах, компилятор обнаружил нарушение уникальности. Несовместимый тип пытается выяснить, какой класс уже использовал это имя, используя служебный тип Extract<T, U>.

Функция registerThing() принимает объект registry в качестве первого аргумента, свойство name экземпляров нового класса в качестве второго аргумента и регистрируемый класс newThing в качестве третьего аргумента. Это общий в R, сопоставление классов name с их типами экземпляров и T тип экземпляра нового класса. Типы registry и name представляют собой прямые отображения и индексации в R и T. Тип newThing зависит от ValidateUniqueThing<R[keyof R], T> (где R[keyof R] — это объединение уже зарегистрированных типов экземпляров IThing) таким образом, что если newThing допустим, то тип соответствует ему (он просто становится new () => T), но если он недействителен, тогда тип не соответствует (он становится new () => X, где X — несовместимый тип из ValidateUniqueThing выше), и вы получаете сообщение об ошибке.

А поскольку registerThing() является функцией утверждения, ее тип возвращаемого значения asserts registry is ... приведет к сужению типа объекта реестра после вызова функции. Тип, к которому он сужается, — это просто существующий тип объекта реестра с добавленным новым свойством, соответствующим аргументу newThing.

Ладно, посмотрим в действии.

Сначала мы создаем пустой объект реестра:

const _Things = {};
// const _Things: {}

Я начал это имя с _, потому что, как только все будет сделано, мы скопируем его в новый const, чтобы быть уверенными, что оно готово для использования везде. Зарегистрируем класс:

registerThing(_Things, "ThingOne", class ThingOne {
    readonly name = "ThingOne";
    readonly prop = "Prop";
    generate() {
        return this.name + " " + this.prop
    }
}); // okay

_Things;
/* const _Things: {
    ThingOne: new () => ThingOne;
} */

Это удалось, и теперь мы видим, что тип _Things был изменен, чтобы отразить добавление. Давайте сделаем это снова:

registerThing(_Things, "ThingTwo", class ThingTwo {
    readonly name = "ThingTwo";
    readonly prop = "PropTwo";
    generate() {
        return this.name + " " + this.prop
    }
}); // okay

_Things;
/* const _Things: {
    ThingOne: new () => ThingOne;
    ThingTwo: new () => ThingTwo;
} */

Все еще хорошо выглядит. Хорошо, а теперь давайте ошибемся:

registerThing(_Things, "ThingThree", class ThingThree { // error!
    // '[Error, "Conflicting ", "prop", "Property with class named ", "ThingTwo"]
    readonly name = "ThingThree";
    readonly prop = "PropTwo";
    generate() {
        return "wha"
    }
});

Ой, у нас ошибка. Если вы прищуритесь на сообщение об ошибке, то увидите, что prop конфликтует с ThingTwo. Давайте исправим это:

registerThing(_Things, "ThingThree", class ThingThree {
    readonly name = "ThingThree";
    readonly prop = "PropThree";
    generate() {
        return "wha"
    }
}); // okay

И совершим еще одну ошибку:

registerThing(_Things, "ThingFour", class ThingFour { // error!
    // [Error, "Make", "name", "readonly PLEASE"]
    name = "ThingFour";
    readonly prop = "PropFour";
    generate() {
        return ""
    }
});

Ой, у нас ошибка. Прищуривание показывает, что name не является readonly и, следовательно, имеет тип string, а не "ThingFour". Давайте исправим это:

registerThing(_Things, "ThingFour", class ThingFour {    
    readonly name = "ThingFour";
    readonly prop = "PropFour";
    generate() {
        return ""
    }
}); // okay

Большой. Теперь копируем заполненный _Things в Things:

const Things = _Things;
/*
const Things: {
    ThingOne: new () => ThingOne;
    ThingTwo: new () => ThingTwo;
    ThingThree: new () => ThingThree;
    ThingFour: new () => ThingFour;
}*/

который имеет все реквизиты, которые мы хотим. И чтобы использовать классы, мы просто индексируем в Things:

function foo() {
    const thing2 = new Things.ThingTwo();
    // const thing2: ThingTwo
    console.info(thing2.generate())
}

Итак, это работает! Причина, по которой я скопировал _Things в Things, заключается в том, что, как и все эффекты анализа потока управления, сужение, сделанное в функциях утверждений, не сохраняется за границами функций. Итак, внутри foo() вы обнаружите, что _Things выглядит совершенно пустым:

function foo() {
    const thing2 = new _Things.ThingTwo(); // error!
    // Property 'ThingTwo' does not exist on type '{}'.
}

Это прискорбно, но чтобы предотвратить это, компилятору пришлось бы приложить много дополнительных усилий, чтобы попытаться выяснить, когда был вызван foo() относительно того, когда _Things был сконфигурирован, а это невозможно (см. microsoft/TypeScript#9998 для обсуждение общего вопроса). Достаточно легко добраться до места, где компилятор знает, что суженный тип действителен, а затем скопировать в const, тип которого одинаков независимо от того, где вы его используете.

Итак, ура, все работает. Это сложно, и, возможно, слишком сложно, чтобы быть полезным для вас. Возможно, вам больше понравится какой-то другой подход, но все, что я могу придумать (включая этот подход), будет включать какую-то цикличность, избыточность, уродство или «нелокальность» ошибок.

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

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

Площадка ссылка на код