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

Question

[Antowa Kartowa]

Занимаюсь постепенным переписыванием legacy кода на проекте с JavaScript на TypeScript и дошло дело до API класса. На данный момент варианта переписать его с нуля не рассматриваю так как опасаюсь завязнуть.

Класс объявляет методы (размещаемые в прототипе) _readMany, _create, _read, _update, _delete. В конструкторе на основе строкового параметра type создаются динамические имена новых свойств экземпляра и им присваиваются ссылки на методы класса. Например, значением type является 'User', то для него будут сгенерированы имена свойств 'getUsers', 'createUser', 'getUser', 'updateUser', 'deleteUser'. Опущу несколько методов в коде для простоты.

class API {
  _url;

  constructor(type, url) {
    this._url = url;

    this[`get${type}s`] = this._readMany;
    this['create' + type] = this._create;
    this['get' + type] = this._read;
  }

  _readMany(params = {}) {
    const options = getApiOptions(Method.GET);
    const url = new URL(this._url);
    url.search = new URLSearchParams(params);
    
    return fetch(url.toString(), options);
  }

  _create(body) {
    const options = getApiOptions(Method.POST, body);
    
    return fetch(this._url, options);
  }

  _read(id) {
    const options = getApiOptions(Method.GET);
    
    return fetch(`${this._url}/{id}`, options);
  }
}

Как можно и возможно ли вообще типизировать такие динамические методы? Спасибо.

PS. Во время редактирования случайно нажал Tab и Space, после чего вопрос опубликовался раньше времени и я не успел отредактировать сложность вопроса. А после публикации её, видимо, нельзя изменить.

Comments

[WbICHA]

Да, по сути, никак, что логично, почему у класса вообще динамические свойства?
Имхо, тебе будет на порядок легче и быстрее дать им нормальные статичные имены (прим.: getAll, create, getOne) и через глобальный поиск заменить все "уникальные" использования со старыми генерируемыми именами.

Answer 1

[Aetae]

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

Однако в целях поддержки лекаси ты можешь просто подменить тип, что-то вроде:

type MethodNames<T extends string> = `get${T}s` | `create${T}` | `get${T}`;

interface IAPI {
  new <T extends string>(type: T, url: string): {
    [K in MethodNames<T>]: Function
  }
}

export default API as unknown as IAPI;

сработает как надо. Естественно ты можешь доработать интерфейс IAPI до полного совпадения.

При декларации самого класса ты максимум можешь добавить неспецифичную index signuture, условно:

type MethodNames<T extends string> = `get${T}s` | `create${T}` | `get${T}`;
class API {
  [key: MethodNames<string>]: Function

  _url;

  constructor(type: string, url: string) {
    this._url = url;

    this[`get${type}s`] = this._readMany;
    this[`create${type}`] = this._create;
    this[`get${type}`] = this._read;
  }

  _readMany(params = {}) {
    const options = getApiOptions(Method.GET);
    const url = new URL(this._url);
    url.search = new URLSearchParams(params);
    
    return fetch(url.toString(), options);
  }

  _create(body) {
    const options = getApiOptions(Method.POST, body);
    
    return fetch(this._url, options);
  }

  _read(id) {
    const options = getApiOptions(Method.GET);
    
    return fetch(`${this._url}/{id}`, options);
  }
}

Но это уже будет не так удобно и чётко.

Comments

[WbICHA]

В таком решении теряется тип функций. Там уже тип вручную разве что прописывать каждому ключу.

[Aetae]

WbICHA, само собой, это чисто пример технической возможности.
Всё что надо - руками придётся подставить, можно напрямую из типа класса API.

Так например:

type Methods<T extends string> = {
  [_ in `get${T}s`]: API['_readMany'];
} & {
  [_ in `create${T}`]: API['_create'];
} & {
  [_ in `get${T}`]: API['_read'];
}

interface TAPI {
  new <T extends string>(type: T): Methods<T> & {
    [K in Exclude<keyof API, `_${string}`>]: API[K]
  }
}

export default API as unknown as TAPI;

[Antowa Kartowa]

Большое спасибо. Осмелюсь еще два встречных вопроса задать.

Вместо Function пытаюсь использовать union type из типов описывающих каждый метод. Поскольку у _update 2 обязательных аргумента id и body, а у _readMany один необязательный аргумент, то при попытке вызова api.getUsers() тайпскрипт ругается на недостаток 2 аргументов. Это можно как-то побороть?

Не посоветуете книгу или курсы чтоб начать нормально и глубоко разбираться в тайпскрипте? Я вроде бы не вчера начал с ним работать и несколько курсов успел посмотреть, но он всё равно остаётся моей основной головной болью.

[Aetae]

Antowa Kartowa, если ты используешь union-тип, то без явного уточнения(narrowing) типа через if он и остаётся union, Как задать каждому методу свой тип, я указал в комменте выше.

По поводу что почитать - не могу сказать, я изучаю всё на практике: есть проблема - есть документация, гугл и исходники.)