Некоторое время назад кто-то поднимал тему разработки в теме против разработки в плагине. Часть Rails на https://www.pfaffmanager.com/ начинает становиться довольно стабильной, и я хотел бы перенести разработку части Rails в компонент темы. Это работает довольно хорошо: изменения в шаблонах и инициализаторах в компоненте темы переопределяют плагин, как и ожидалось. Однако изменения в javascripts/discourse/components/server-item.js.es6 в теме не переопределяют те же файлы в плагине.
Думаю, я мог бы полностью убрать всё, связанное с Ember, из плагина и оставить это только в теме, но это звучит как работа на целый день, чтобы переместить все эти части, протестировать их и выгрузить на сервер. Не упускаю ли я что-то очевидное? Стоит ли мне перетерпеть и полностью удалить из плагина то, что я хотел бы видеть в компоненте темы? Или просто оставить всё в плагине?
Наличие одного и того же кода и в компоненте темы, и в плагине кажется мне немного странным. На мой взгляд, лучше выбрать либо компонент темы, либо плагин и следовать этому выбору последовательно. Переопределение целых файлов — это не то, что мы делаем сами, и не то, что мы рекомендуем. Чтобы переопределить поведение ядра или плагина, ваш компонент темы должен использовать такие методы, как api.modifyClass.
Я подозреваю, что коренная причина здесь в том, что ES6-модули плагинов имеют другой префикс, чем модули ядра или темы. Запустив это на вашем сайте, я вижу, что модули имеют префикс plugin. Я полагаю, что если бы вы включили компонент темы, мы бы увидели ещё одну запись, но с другим префиксом.
В целом я согласен, однако есть некоторые пограничные случаи:
Когда объем изменений в JavaScript значительно превышает изменения в бэкенде, в таких случаях компоненты тем — отличный способ быстро развернуть и протестировать код.
Когда основная функциональность может быть реализована в базовом компоненте темы, но добавление дополнительного плагина позволяет получить функции, недоступные только с помощью JavaScript. Я использую этот подход в предпросмотрах списков тем: компонент выполняет 90% того, на что способен плагин, но если добавить и сам плагин, вы получаете дополнительные крутые возможности.
Тем не менее, упаковка всего в плагин имеет смысл, так как это снижает путаницу при настройке и установке, и всё всегда остаётся синхронизированным.
Но даже в вашей сценарии с плагином и темой я бы не стал дублировать код Ember и в плагине, и в теме. Поэтому мне пришлось бы вынести хотя бы большую часть шаблонов, инициализаторов и компонентов из плагина и оставить их только в компоненте темы.
Поскольку запутаться в конфигурации буду только я, это не такая уж большая проблема. Мне очень нравится идея возможности тестировать новые элементы фронтенда на живом сайте, переключившись на бета-версию темы.
Другая проблема, которую я вижу, — это написание тестов QUnit. (Я буду делать вид, что смогу разобраться, как их добавить, хотя это отдельная проблема; думаю, дело в том, что я не знаю, как наполнять тесты данными для отображения…). Мне кажется, что если в моём плагине есть тесты QUnit, то они будут запускаться при отправке в GitHub (потому что я почти уверен, что видел, как мои нерабочие тесты проваливались).
Технически это должно быть возможно, но, насколько я знаю, у нас пока нет готовых рабочих процессов GitHub Actions для тем. В настоящее время тестирование тем проходит значительную переработку (в связи с переходом на ember-cli), но после этого, возможно, мы сможем добавить несколько шаблонов рабочих процессов тестирования тем в GitHub - discourse/.github · GitHub
Сценарий: я хочу переопределить шаблон, развернутый в плагине, но сделать это управляемым через код способом.
Поэтому я попытался включить новый шаблон в компонент темы. Тот же самый файл существует в плагине (но отличается).
Это, похоже, работает в моей тестовой облачной установке, но не в стандартной продакшн-среде.
Так можно ли сказать, что нельзя предсказать, будет ли это успешно для шаблонов? То есть конвейер активов устроен так, что невозможно предсказать, какой «шаблон» применится, поскольку нет заранее определённого или предсказуемого порядка приоритетов?
Я работал с довольно странным предположением, что существует иерархия, что-то вроде:
ядро
плагин
компонент темы
локальные изменения сайта
И если разместить «файл» с тем же путём и именем на более высоком уровне этой иерархии, он переопределит любое «предыдущее» определение.
Но моё предположение, вероятно, ненадёжно?
Является ли единственным «упакованным» решением (исключая локальные изменения сайта) форк плагина и внесение изменений непосредственно в него?
В каком-то смысле это было бы жаль, так как это увеличило бы усилия по обслуживанию кастомизаций, поскольку пришлось бы периодически слиять изменения из основного репозитория плагина…
Лучшим решением было бы обновление существующего плагина и предоставление ему точки расширения плагина и/или API кастомизации, которые мог бы использовать компонент темы.
Мой комментарий выше касался конкретно переопределения целых JS-файлов (то есть модулей ES6). Это невозможно. Конвейер ассетов автоматически добавляет префикс с именем/идентификатором плагина или темы к модулям плагина или темы, поэтому конфликт с ядром невозможен.
Что касается шаблонов, мы знаем, что люди (включая нас в некоторых ситуациях) их переопределяют, поэтому мы, скорее всего, продолжим поддерживать работу этой системы. Но помните, что это является хаком. Если поведение оригинального компонента или контроллера изменится, ваш переопределённый шаблон, вероятно, приведёт к сбою сайта.
В целом, я считаю, что иерархия, которую вы упомянули (ядро, плагин, тема), должна соблюдаться — поэтому, если вы наблюдаете что-то другое, пожалуйста, поделитесь подробностями путей к файлам в плагине и теме.
