Я думаю, что нам нужен общий способ сделать это, который был бы независим от конкретной темы компонента — как у нас сейчас.
У меня есть ещё один компонент темы, использующий эту технику:
Таким образом, это уже как минимум два примера с моей стороны, а может быть, и больше.
Я согласен. Я создал набор компонентов блоков, каждый из которых работает автономно, а не объединён в один пакет: Blocks · GitLab.
В настоящее время я могу размещать эти блоки на выделенной главной странице с помощью компонента «Блоки главной страницы», а также использовать их в «Блоках правой боковой панели» или на панелях.
Недавно я экспериментировал с темой Central, где требовалась пользовательская раскладка боковой панели. Я легко мог создать фреймворк блоков для кастомной боковой панели и разместить на ней компоненты блоков: https://central.kostka.studio (а также добавить компонент Powered-by-discourse в боковую панель, просто указав его по имени).
Автономные компоненты блоков — это на данный момент самый полезный инструмент, который у меня есть, для создания кастомизаций клиентов гибким и поддерживаемым способом. Было бы здорово иметь общий путь вперёд для поддержки этого подхода.
Хочу поднять этот вопрос, так как пытаюсь найти лучший способ работы с моими компонентами. Сейчас вижу два варианта, у обоих есть серьёзные недостатки: я мог бы создать реестр для каждого компонента темы, который рендерит блоки, но это как бы перечёркивает саму идею модульности. Или добавить один глобальный реестр через плагин, но тогда мои компоненты станут зависимыми от наличия этого плагина.
Похоже, что наличие в ядре глобального API для регистрации блоков действительно помогло бы. Что-то, что компоненты тем могли бы использовать для вызова рендеринга блоков, а также для регистрации новых блоков.
Мне нравится работать с подходом на основе блоков, потому что он позволяет разделить ответственность между макетом приложения и содержимым компонентов. Компонент блока просто отвечает за рендеринг своего содержимого, а затем рендерится другим компонентом приложения. Я могу убрать всю логику маршрутов и выходных точек из компонента блока и легко переиспользовать один и тот же блок несколько раз на макете и даже по всему приложению.
Это делает всё более лёгким и переиспользуемым, и в целом это элегантный подход. Было бы здорово, если бы в Discourse была надёжная поддержка этого паттерна.
Дэвид, возможно ли создать API с дискреционными настройками для регистрации компонентов «между темами/плагинами», чтобы использовать их в другом плагине или компоненте?
Это позволило бы избежать регистрации всего подряд, но при этом сохранить гибкость и возможность явно разрешать такие действия.
Я не уверен насчёт универсального API для этого. Существует слишком много способов использования компонентов, и у всех них разные требования к аргументам и времени загрузки.
Для вашего случая подойдёт ли реестр, специфичный для темы или плагина? Например, как в макете выше для блоков правой боковой панели?
Если нет, предоставление конкретных примеров может помочь нам точно определить, какой API необходим. Все темы и плагины, поддерживаемые CDCK, уже переведены на gjs, и мы не сталкивались с этой проблемой (за исключением конкретных случаев, таких как блоки правой боковой панели).
Да, на самом деле, перечитав внимательнее то, что вы написали в черновике PR, я пришёл к выводу, что это достаточно хорошее решение, а именно:
«Этот коммит вводит отдельный список компонентов блоков правой боковой панели и позволяет другим темам и плагинам регистрировать дополнительные».
Я считаю, что это ключевой момент — возможность удалённо регистрироваться как совместимый с другой темой, а затем позволять «основной» теме включать элементы, зарегистрированные удалённо, — это именно то, что мне нужно, поэтому я считаю, что вы уже показали, что это возможно.
Круто!
В очень простых случаях вы даже можете обойтись добавлением PluginOutlet в «основную» тему, после чего другие темы смогут использовать renderInOutlet (или поместить файл в connectors/...).
Это тоже верно. Мне очень нравится ваш паттерн регистрации — просто отлично. Было бы неплохо сохранить совместимость с RSB (Bars уже использует ту же систему параметров), чтобы вся система стала интероперабельной. Идеальным вариантом было бы, если бы стандартные блоки входили в тематический пакет, а «материнский корабль» — в отдельный TC. Тогда Bars можно было бы подменить на роль «материнского корабля» с его расширенной функциональностью компоновки, при этом пакет оставался бы переиспользуемым. Однако я понимаю, что это может оказаться слишком сложным для конечных пользователей в плане администрирования и для поддержки CDCK!