Я ценю гибкость, которую даёт полный доступ к API компонентов. Мне нравится синтаксис компонентов Glimmer в целом, и я понимаю, почему он может снизить сложность кодовой базы.
Однако для базовых сценариев (например, когда нужно добавить кнопку и иконку) старые методы API были объективно более лаконичными и понятными (меньше импортов, меньше операций, меньше экспонируемого API). Есть ли причина, по которой старые методы не могли бы оставаться поддерживаемыми? Я представляю себе, что их можно было бы использовать как служебные функции, реализуя их внутреннюю логику на основе новых компонентов Glimmer, а сами методы API могли бы выполнять проверку совместимости версий.
Это было бы гораздо менее разрушительным для тех, кто использует эти методы, и предотвратило бы взрывной рост условной логики в экосистеме плагинов.
Моя главная претензия к существующим виджетам — отсутствие документации. Этот пост, объявляющий об их удалении, является одним из самых чётких документов, где упоминается существование этих конкретных методов и способы их использования. На самом деле я пришёл сюда именно потому, что пытался разобраться, как использовать старый API.
Мне нравится, что трансформеры регистрируются в одном месте с помощью строковых литералов. Это значительно упрощает работу по документации и разработку плагинов.
Что касается виджетов, то все они, похоже, регистрируются через метод createWidget, который затем вызывает createWidgetFrom. Проблема здесь в том, что _registry — это глобальная переменная в пределах файла, защищённая API, и этот API не позволяет выполнять итерацию. Если бы мы могли получить функцию итерации для реестра виджетов, то могли бы в реальном времени обнаруживать зарегистрированные виджеты. Должно быть документировано: «запустите эту строку JavaScript в консоли браузера, чтобы вызвать API и вывести реестр». Тогда мы получили бы утилиту, очень похожую на ту, что предоставляет реестр трансформеров.
Ещё одна вещь, которая помогла бы в разработке плагинов, — это наличие атрибута на любом корневом DOM-элементе, рендеримом компонентом или виджетом, который указывает, какой именно компонент или виджет вы просматриваете. Например, «data-widget=foo». Это может быть функцией отладки или просто включённой по умолчанию. Поскольку проект с открытым исходным кодом (OSS), речь не идёт о безопасности через неясность.
Я приветствую переход к компонентам Glimmer. Но это потребует времени, и в течение этого периода людям всё ещё придётся работать со множеством виджетов. Поэтому я считаю, что улучшение видимости виджетов, как описано выше, скорее всего, облегчит переходный период для всех.
Что касается этих методов API… Похоже, что кто-то потрудился добавить подробные комментарии к JavaScript API, но сайт документации для него так и не был сгенерирован. Почему?
Я с радостью подготовлю pull request для реализации итерации по реестру виджетов, если это приемлемо.