Как типизировать переменную под хранение классов?

Question

[johnymkp]

У меня есть интерфейс вида
interface IStorage<T, K>
и класс, содержащий базовую реализацию
class Storage<T, K> implements IStorage<T, K>
а еще несколько классов, которые закрывают типы в этом дженерике, например
class MatchStorage extends Storage<Match, number>
У меня есть конфиг, согласно которому создаются хранилища в indexeddb. В том же конфиге я хочу сделать поле, в котором должен храниться класс, соответствующий этому хранилищу. Выглядит примерно так:

const matchStorageConfig: IStorageConfig = {
  storageName: StorageName.Matches,
  oftype: MatchStorage,  // MatchStorage - это класс из примера выше

Когда я создаю хранилища, то следом создаю экземпляры класса для работы с этими хранилищами. Т.е. это по задумке должно выглядеть примерно так: берем из поля oftype класс и создаем экземпляр:
const instance = new oftype(тут аргументы);

Вопрос в том, как мне правильно типизировать oftype, чтобы туда:
* Можно было положить только классы, реализующие IStorage.
* Типы в IStorage могли быть любые, например, IStorage<User, number>, IStorage<Player, string> и т.д.

interface IStorageConfig {
  oftype: ??????? как описать тип под такую задачу

Comments

[Василий Банников]

Покажи как интерфейс IStorage выглядит.

[johnymkp]

Василий Банников, примерно так:

export interface IStorage<T, K> {
  save(data: T | T[]): Promise<DbOperationResult<T>[]>;

там несколько методов, все выглядят так же как save по сути.

[Василий Банников]

johnymkp, покажи метод или поле, в котором фигурирует K.
И как потом будет использоваться поле oftype из IStorageConfig

[johnymkp]

Василий Банников, oftype используется примерно так:

private createStorageInstances(connection: IDBDatabase) {
  this.storages = new Map();
  this.config.storages.forEach(s => {
    if (s.oftype) {
      this.storages.set(s.storageName, new s.oftype(connection, s.storageName));  // ТУТъ
    }
  });
}

public getStorage(storageName: StorageName) {
  return this.storages.get(storageName);
}

А "К" нужен просто чтобы тип ключа задать, больше ни для чего не используется. Интерфейс IStorage имеет методы записи, чтения, удаления. Допустим, метод чтения принимает ключ типа K, а возвращает массив типа T (массив лежит внутри DbOperationResult, там массив успешно считанных данных и массив ошибок, если что-то не считалось):

public read(key?: K | K[]): Promise<DbOperationResult<T>> {

Вот так К и используется. Вся логика работы с хранилищами реализована внутри класса Storage. А "конкретные" классы вроде MatchStorage нужны просто чтобы закрыть типы в Storage:

export class MatchStorage extends Storage<Match, number> {
  public constructor(database: IDBDatabase, storageName: string) {
    super(database, storageName);
  }
}

И вот эти "конкретные" классы я хочу разместить в конфиге, в поле oftype.

export const matchStorageConfig: IStorageConfig = {
  storageName: StorageName.Matches,
  oftype: MatchStorage,  // !!!!!!!! ВОТъ
  options: {
    keyPath: "id"
  },
  indexes: [
    {
      storageIndexName: "lobby_type_index",
      keyPath: "lobbyType",
    },
    {
      storageIndexName: "start_date_index",
      keyPath: "startDateTime",
    }
  ]
};

....

export const defaultDbConfig: IDbConfig = {
  version: 1,
  dbname: 'test123',
  storages: [
    matchStorageConfig,
  ]
}

Answer 1

[Alexandroppolus]

interface IStorageConfig<T, K> {
    oftype: new () => IStorage<T, K>;
}

const matchStorageConfig: IStorageConfig<Match, number> = {
    oftype: MatchStorage
}

const s = new matchStorageConfig.oftype();

здесь предполагается, что у всех твоих стораджей есть конструктор без параметров.
Если хочешь какие-то параметры, то их надо либо делать одинаковыми для всех стораджей (и тогда указать в круглых скобках сразу после new в интерфейсе IStorageConfig), либо в этом нет смысла

Comments

[johnymkp]

Написать
IStorageConfig<T, K>
не могу, потому что у меня этот интерфейс используется в конфиге всей БД, вот так:

export interface IDbConfig {
  dbname: string;
  version: number;
  storages: IStorageConfig[];  // ЗДЕСЬ
}

Соответственно, закрыть T и K негде.
Параметры у конструкторов всех хранилищ одинаковые. Я написал вот так:

export interface IStorageConfig {
  storageName: StorageName;
  oftype: new (database: IDBDatabase, storageName: string) => IStorage<any, any>;

Нормально? В плане того, что any в данном случае это не моветон? Как раз как будто бы логично выглядит, что тип данных и ключ хранилища может быть любой.

[Alexandroppolus]

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

так себе.

если допускается любой тип данных и любой ключ, то нафига параметры в IStorage? Сделай его обычным типом, не генериком:

export interface IStorage {
  save(data: unknown): Promise<DbOperationResult<unknown>[]>;
}

[johnymkp]

P.S. Про "негде закрыть" я похоже ошибся. Могу же написать вот так:

export interface IDbConfig {
  dbname: string;
  version: number;
  storages: IStorageConfig<any, any>[];  // Закрываю типы тут
}

export interface IStorageConfig<T, K> {
  storageName: StorageName;
  oftype: new (database: IDBDatabase, storageName: StorageName) => IStorage<T, K>;

Тогда если сам объект конфига напишу вот так:

export const matchStorageConfig: IStorageConfig<Match, number> = {
  storageName: StorageName.Matches,
  oftype: MatchStorage,

то компилятор не позволит положить в oftype конструктор, который реализует, например Storage<string, number>, а только тот, что реализует Storage<Match, number>

Вопрос про any остается - в данном случае any это нормально?

[johnymkp]

Alexandroppolus, не могу сходу сказать, насколько что-то изменится, если написать unknown. Но я попробую переделать места, которых это все касается. Если окажется, что дженерики и правда не нужны, тогда отмечу решением. А если какие-нибудь проблемы по ходу возникнут из-за unknown, то еще напишу сюда.

[johnymkp]

Alexandroppolus, unknown в итоге не подходит, потому что он тянется до самого верха. Если Storage прочитает данные и вернет их как unknown, то чтобы пользоваться ими, придется явно преобразовывать к нужному типу. Делать это в клиентском коде не хочется, потому что логичнее, что если клиентский код работает с типом Match и запрашивает чтение из БД, то БД ему должна возвращать Match, а не unknown. Поэтому дженерики выглядят лучше.

[Alexandroppolus]

johnymkp, когда ты работаешь с объектом matchStorageConfig из последнего куска кода, то всё хорошо - объект типизирован. Но как только попробуешь забирать что-то из storages из "общего конфига", и проверка типов исчезнет, будет any.
Вот взяли, например, dbConfig.storages[0]. К каким типам будешь приводить (any, any) ?

[johnymkp]

Alexandroppolus, а мне эти конфиги доставать не надо. Они только в одну сторону нужны - чтобы создать экземпляры хранилищ, типизированные нужными типами данных. Основная проблема, которую я хотел решить всеми этими дженериками - это при работе с БД внести ясность - что сохраняешь, что читаешь. Вот есть сервис для работы с матчами. Он из БД загружает матчи, может там что-то по ним посчитать и т.д. Может быть еще какому-то сервису потребуются матчи. Они что, должны считать массив unknown объектов и сами трансформировать их в матчи? Я вижу это как если бы я пришел в магазин за яйцами, а мне дали курицу и сказали "Яйца из нее сам доставай". А так у меня есть условный MatchStorage класс, который типизирует Storage нужным типом данных (Match) и я этот MatchStorage передаю всем, кому нужно работать с матчами. Они вызывают read и получают массив Match, а не массив unknown.

[johnymkp]

Кажется я понял о чем вы говорите. Когда я сделал поле под хранилища

private storages: Map<StorageName, IStorage<any, any>>;

и потом попробовал из него извлечь хранилище и передать в сервис

const matchStorage = database.getStorage(StorageName.Matches);
  const ms = new MatchService(matchStorage);

то столкнулся с ошибкой что MatchStorage не совместим с Storage{any, any}.
Теперь я понял, о чем вы. Но тогда я не знаю как решить эту проблему.

Получается невозможно что ли создать типизированные хранилища, сохранить из в мапу например, а потом извлекать по имени?

[Alexandroppolus]

Можно, при определенных условиях.
Вот, например, database.getStorage(StorageName.Matches); - что такое здесь database? Это твой объект?

Если его сразу создать со всеми возможными конфигами, то вполне можно затипизировать так, чтобы на каждое StorageName.NNNN возвращался Storage своего типа.
Ну а если ты сначала создаешь пустой database, а потом в разных файлах по отдельности накидываешь в него конфиги, то конечно никаких типов сохранить не получится.

Хотя, как вариант, database можно затипизировать неким интерфейсом, а потом в этот нитерфейс надобавлять информацию о типах. Но это по сути то же самое. Т.е. должен быть файл, где в одну кучу соберутся все типы для разных StorageName

[johnymkp]

Alexandroppolus, сейчас попробую вкратце объяснить что к чему у меня там.

database это класс, изначально основная задача которого - это принять конфиг с названием\версией БД, настройками хранилищ (имя, keyPath, индексы и т.д.) и создать БД и хранилища. Ну и вернуть объект этой БД.
Потом я уже создал дженерик-класс Storage, реализовал в нем crud.

Сперва я просто создавал в начале программы хранилища и передавал в них БД.

Но потом подумал, что было бы удобнее просто у экземпляра БД попросить "дай мне хранилище для работы с Match". Поэтому я решил при создании indexeddb-хранилищ тут же создавать и экземпляры Storage, типизированные Match'ем и прочими типами данных, сохранять эти Storage в map и сделать метод получения из нее по имени. Это удобно еще и тем, что при создании Storage-экземпляра можно сразу ему передать БД.

Вот для этого я и добавил в исходный конфиг еще и классы конкретных хранилищ.

Так что да, database сразу создается со всеми возможными хранилищами.

P.S. Я вот еще подумал, мб можно хранить как any, а при извлечении приводить к нужному типу как-то через as например.

[Alexandroppolus]

johnymkp,

Я вот еще подумал, мб можно хранить как any, а при извлечении приводить к нужному типу как-то через as например.

не надо. Забудь вообще про any.

database сразу создается со всеми возможными хранилищами

набросал черновик, как это может выглядеть. Ссылка.

[johnymkp]

Alexandroppolus, спасибо, когда разберусь, напишу что вышло.

[Alexandroppolus]

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

[johnymkp]

Alexandroppolus, я вроде бы понял как работает InstanceType, но пока не получается адаптировать пример под свой код. Правильно ли я понимаю, что ваше решение базируется на том, что обязательно надо вводить дженерик на классе Database и иначе никак?

[Alexandroppolus]

johnymkp,

Правильно ли я понимаю, что ваше решение базируется на том, что обязательно надо вводить дженерик на классе Database и иначе никак?

как вариант - можно в самом классе Database зашить информацию о типах всех стораджей, тогда не придется это оформлять генериком. Но тогда уже не получится класс Database вынести в утилзы, shared или тому подобное, он теперь знает обо всех стораджах проекта.

[johnymkp]

Alexandroppolus, мне в общем-то и не надо, чтобы он был утилитой. Вполне можно сделать его полностью самостоятельным.

В вашем примере решение смотрится хорошо, т.к. он компактный. Но при адаптации у меня возникли такие проблемы:
1. В классе MyDatabase я использую синглтон паттерн. Поэтому, когда я добавил дженерик к самому классу БД, компилятор начал ругаться "Static members cannot reference class type parameters" на статическое поле private static instance: MyDatabase;
2. В конфиге находятся не только конфигурации хранилища, но и некоторые параметры самой БД, вроде имени и версии. Поэтому возникает дополнительный слой вложенности в конструкции InstanceType M[N]['oftype'], которая и так довольно трудно воспринимается.

В итоге у меня сложилось впечатление, что в этом месте от типизации как будто больше возни, чем пользы. Так если прикинуть, в коде, который извлекает хранилище, я и так знаю тип хранилища, который мне нужен. Поэтому можно сделать просто вот так:

public getStorage<T>(storageName: StorageName): T  {
    return this.storages.get(storageName) as T;
  }

а при извлечении вот так

const matchStorage = database.getStorage<MatchStorage>(StorageName.Matches);

Как думаете, норм?

[Alexandroppolus]

johnymkp,

database.getStorage<MatchStorage>(StorageName.Matches);

это просто чуть более "цивилизованная" обертка над

database.getStorage(StorageName.Matches) as MatchStorage;

, она не должна вводить в заблуждение.

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

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

В классе MyDatabase я использую синглтон паттерн

в TS для этого совершенно необязательно делать статические методы класса. Вот, для варианта из моего комментария выше - без генерика для MyDatabase: ссылка

[johnymkp]

Alexandroppolus, новый вариант подошел, спасибо!