Дэвид, есть ли планы прекратить поддержку «разделённых» компонентов и файлов без расширения .gjs на каком-то этапе?
Скорее всего, да. Похоже, что Ember будет поддерживать отдельные файлы js/hbs в обозримом будущем, но нам может иметь смысл перейти на новый формат раньше, чтобы упростить системы сборки тем и плагинов.
Если мы решим отказаться от hbs, мы пройдем весь обычный цикл устаревания и сделаем соответствующие объявления, так что это не станет неожиданностью.
Для тем и плагинов, использующих нашу стандартную конфигурацию линтинга, файлы .hbs уже запрещены, и у нас есть автоматизированный инструмент для перехода на gjs. Мы почти завершили обновление всех тем и плагинов, принадлежащих CDCK, с помощью этого инструмента.
Итак, просто для подтверждения (чтобы я мог отредактировать свои компоненты js/hbs): компоненты hbs не поддерживаются в скелетоне темы, и настоятельно рекомендуется перенести их в gjs?
Файлы Hbs продолжают «поддерживаться» (то есть они будут работать, и мы не будем этого менять без цикла устаревания)
Но да, настоятельно рекомендуется использовать .gjs для нового кода и начать миграцию существующих тем и плагинов. Наиболее актуальная конфигурация линтинга в шаблонах будет обеспечивать выполнение этой рекомендации, если вы явно не откажетесь от правила require-strict-mode линтера ember-template-lint.
А, теперь понятно. Спасибо за уточнение!
Я считаю, что в любом случае Glimmer Components могут быть в 3–5 раз быстрее, так что это определённо хорошая практика? (при условии, что вы не перегружаете их множеством дополнительных отслеживаний)
Компоненты Glimmer значительно быстрее классических компонентов, да!
Но формат файлов .gjs не обязательно означает, что это компонент Glimmer. У нас всё ещё есть сотни классических компонентов в ядре, которые теперь все конвертированы в формат файлов .gjs (название сбивает с толку, я знаю 
).
Кодмод, который мы выполняем, только конвертирует формат файлов из js/hbs в .gjs. Он не меняет тип компонента — это было бы почти невозможно полностью автоматизировать.
Справедливо, но часто стоит приложить усилия, если вы как раз занимаетесь ручной рефакторизацией.
О боже. Я только подумал, что начинаю понимать.
Значит, это не только у меня! 
Делает ли это его компонентом Glimmer?
И если так, то даже если это просто шаблон, добавление класса ускоряет его работу по сравнению с .gjs, содержащим только <template>Мои важные слова</template>?
export default class MyCoolComponent extends Component {
Вот это:
import Component from "@glimmer/component";
(и последующее соблюдение стандартов Glimmer, таких как геттеры)
Это, как я полагаю, просто «объявление нативного класса».
Ага! Значит, чтобы использовать импортированную часть компонента, всё ещё нужно объявить класс.
Огромное спасибо!
Моя главная проблема здесь заключается в том, что в hbs я могу просто обратиться к компоненту из другого тематического компонента, так как мне не нужен явный импорт. Однако в gjs мне необходимо его импортировать, и я не знаю, как обратиться к компоненту, определенному в другом тематическом компоненте.
Все существующие реализации, которые я изучил, либо a) всё ещё используют hbs, либо b) используют инъекцию на основе JavaScript.
Как это сделать?
В этом случае я получаю рекомендацию eslint:
В ней предлагается добавлять класс только тогда, когда он действительно нужен, иначе это может даже замедлить работу.
В порядке возрастания производительности:
-
Классический компонент:
import Component from "@ember/component"; export default class Blah extends Component { -
Компонент Glimmer:
import Component from "@glimmer/component"; export default class Blah extends Component { -
Компонент Glimmer только с шаблоном:
export default <template> ... </template>
точно
В настоящее время темы не могут импортировать из других тем. Тот факт, что были возможны межтемовые зависимости через магическое разрешение по имени, не было задумано специально
Могли бы вы подробнее описать ваш случай использования, возможно, в другой теме? Это то, с чем мы ещё не сталкивались (пока) ни в одной из наших собственных тем.
Кажется, у вас это уже есть… (right-sidebar-blocks).
На прошлой неделе мой основной кейс заключался в принудительном упорядочивании нескольких компонентов темы, использующих один и тот же плагин-оутлет. Хотя CSS-файлы загружаются в алфавитном порядке, JS-файлы компонентов темы загружаются в числовом порядке. В итоге мне пришлось удалять компоненты темы и добавлять их заново в нужном мне порядке, одновременно пытаясь избежать всех проблем с CSS, которые это вызывало.
Затем я понял, что могу просто удалить коннектор в каждом из них и создать новый компонент темы, который будет содержать всё это в едином коннекторе для этого плагина-оутлета:
<ComponentFromTC1 />
<ComponentFromTC4 />
<ComponentFromTC3 />
<ComponentFromTC2 />
Это работает очень хорошо. А потом я подумал: «О, мне нужно сделать это gjs, чтобы не переделывать всё через несколько месяцев». И тут 
У вас был клиент, который хотел сделать это при переходе к вам. Я не помню деталей.
Я только что сделал форк этого решения для текущего клиента, который только что запустил свой проект. Они хотели добавить несколько других типов блоков. Я пробовал создать сестринскую тему, которая решала бы задачу только с помощью CSS, но в итоге пришлось отказаться и сделать форк. Не совсем уверен, мог ли быть найден другой путь.
Но…
Это отличные новости, кроме того, что я не понял этого раньше. Я вроде бы помню, что видел это, и также помню обсуждение этой проблемы, когда кто-то предложил мне сделать форк, но теперь я уверен, что мне это не нужно.
Хм… Discourse Bars 🍻 🍸 (a sidebar framework) … использует ту же систему, и у меня не возникало проблем.
Смысл всего этого в том, что вы можете использовать компоненты из других тем или плагинов (и это работает).
right-sidebar-blocks и discourse-tc-bars используют резолвер Ember для поиска компонентов по имени. В данный момент это работает и не устарело.
В .hbs это делается так: {{component "some-name"}}, а в (g)js можно сделать так: resolveRegistration("component:some-name").
Однако, если мы говорим о долгосрочной перспективе, то нам следует стремиться избегать поиска компонентов через резолвер Ember. Как только мы в конечном итоге включим флаг «static invokables» в Embroider, резолвер станет пустым.
Это направление, которое, как я считаю, необходимо принять для right-sidebar-blocks и других подобных случаев совместного использования компонентов между темами/плагинами: