Блог

Главная - Вопросы по программированию - Шаблон TS для библиотечных плагинов

Шаблон TS для библиотечных плагинов

#typescript

#typescript

Вопрос:

Я поддерживаю несколько плагинов для различных библиотек JS, которые содержат ссылку на экземпляр библиотеки. Я предпочитаю писать их с помощью JSDoc, чтобы получить преимущества проверки типов TS в обычном JS. Я ищу лучший шаблон для структурирования таких плагинов, чтобы он хорошо работал с проверкой типов TS. Этот вопрос не относится к какой-либо библиотеке, Cytoscape.js используется только в качестве примера. Рассмотрим следующий код:

 class CytoscapePlugin {
  /** @type cytoscape.Core */
  cy;

  /** @type boolean */
  originalZoomEnabled;

  constructor(cy) {
    this.cy = cy;

    this.originalZoomEnabled = this.cy.zoomEnabled();
    this.cy.zoomEnabled(false);
  }

  fit() {
    this.cy.fit();
  }

  destroy() {
    this.cy.zoomEnabled(this.originalZoomEnabled);
    
    this.cy = undefined;
  }
}

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

Когда плагин больше не нужен, нужно вызвать destroy метод. Он возвращает поведение библиотеки к исходному состоянию и очищает ссылку на библиотеку, чтобы сделать экземпляр плагина непригодным для использования, в случае, если пользователь-разработчик использует плагин по ошибке после его уничтожения.

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

Однако, очевидно, что установка ссылки на библиотеку undefined не позволяет выполнить проверку типа TS, поскольку она не объявлена разрешающей undefined . Если я разрешу это с cytoscape.Core | undefined помощью, мне придется проверять его значение, прежде чем использовать его в любом другом методе ( fit ) . Технически undefined это недопустимое состояние, поэтому я бы хотел избежать его в определении типа.

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

Ссылки на некоторые из моих затронутых пакетов:

Комментарии:

1. Вместо этого можно getInstance использовать частный метод this.cy , который выдает ошибку при попытке вызова fit after destroy . Таким образом, устраняется риск вызова cy , когда он не определен, что делает компилятор счастливым и в то же время сообщает разработчикам, что они случайно сделали что-то не так.