Можно ли добавлять аддоны Ember к плагину Discourse? (например, ember-power-select)

Разработка
1

Я хочу добавить несколько аддонов Ember в плагин.

Вот пример: Power Select от Ember.

(Это помогает при создании выпадающих списков. Discourse использует select-kit, который, как я знаю, тоже мощный, но мне трудно его кастомизировать, так как он сильно абстрагирован в базе кода. Поэтому я хочу попробовать Power Select).

В обычном приложении Rails/Ember, я думаю, я бы просто установил аддон командой:

$ ember install ember-power-select

Затем я бы добавил что-то вроде следующего:

hbs шаблон:

<PowerSelect @options={{this.names}} @onChange={{this.foo}} as |name|>
  {{name}}
</PowerSelect>

JavaScript-файл, связанный с ним:

    import Controller from '@ember/controller';
    export default class extends Controller {
      names = ['Stefan', 'Miguel', 'Tomster', 'Pluto']
      foo() { }
    }

Но плагин Discourse — это не стандартное приложение Rails. Нужно ли мне сделать что-то особенное, чтобы это заработало?

2

Что ж, я смотрел это, надеясь, что вы получите какие-то подсказки, но вот мы уже на четвёртый день.

Я довольно новичок в Ember, но я почти уверен, что вам будет гораздо лучше, если вы сможете разобраться с этим «сильно абстрагированным» кодом и играть по этим правилам. Не только будет сложно понять, как подключать другие дополнения, но и поддерживать их тоже будет трудно.

3

Мы обновляем Discourse до EmberCLI, и мы уже очень близки к этому:

4

Спасибо всем.

Я уже видел это раньше, но рад получить подтверждение, что добавлять плагины Ember нельзя, пока не будет завершено это обновление. Значит, скоро появится возможность добавлять плагины Ember — как только обновление будет завершено. Это звучит отлично.

Думаю, это интересный вопрос. Вот моё мнение:

Что касается использования «абстрагированных вещей» Discourse по сравнению с плагинами Ember: я могу ошибаться, но мне кажется, что использование плагинов Ember для конкретных задач в плагинах может быть проще в поддержке, особенно в случаях, когда вы пытаетесь сделать что-то отличное от того, что уже реализовано в Discourse. Вот моя логика:

Например, если вы хотите добавить новое выпадающее меню в плагин. Это различие, вероятно, важно — я говорю именно о попытках реализовать в плагине что-то новое, чего нет в исходном коде Discourse, и вопрос заключается в том, стоит ли начинать с методов Discourse или использовать отдельный плагин.

Часто у вас действительно нет выбора. Например, если я хочу добавить пользовательское поле к темам, я всегда буду дорабатывать существующие методы и код Discourse.

Но если речь идёт о целенаправленной функциональности — например, выпадающем меню для новой цели — то я уже оказываюсь в ситуации, когда использование методов Discourse потребует их адаптации к задачам, для которых они изначально не предназначались.

Вариант 1: Я мог бы попытаться взять код select-kit, который используется, например, в category-chooser, и вставить его в новое место (не связанное с категориями), а затем попытаться настроить его под то, что нужно мне, вместо категорий. Это та задача, которую я ранее описывал как сложную.

К тому же, это может быть трудно поддерживать — ведь если команда Discourse изменит что-то в том, как работает код select-kit в category-chooser, это может повлиять на моё новое настроенное выпадающее меню, причём неожиданным образом (поскольку я настроил его так, чтобы оно работало немного иначе, чем настоящее выпадающее меню для выбора категорий).

Вариант 2: Я мог бы использовать что-то из Ember — надёжное, но при этом предназначенное для кастомизации, где я могу довольно чётко видеть, как работает код. В таком случае я могу упустить новые крутые функции, которые команда Discourse может добавить в свои выпадающие меню, но зато мне будет проще контролировать работу моего выпадающего меню. Так что, думаю, это, вероятно, лучший вариант, если он возможен.

Вариант 3: Написать всё с нуля. Именно к этому я обычно и прихожу. Когда код написан, приятно иметь код, который я полностью понимаю и могу настраивать. Но, конечно, это занимает больше времени, и (по крайней мере, начальные версии) вряд ли будут такими мощными и надёжными, как решения, созданные командой Discourse или командой Ember.

5

Поднимаю тему, и было бы здорово добавить поддержку Ember-аддонов в Theme Components…

6

Поднимаю тему.
Если мы добавим аддон в Discourse, например
cd app/assets/javascripts/ && yarn add LIB_NAME,
как этот аддон станет доступен в плагине?

7

Просто интересно, возможно ли это сейчас? (И если да, то как?)

8

Боюсь, что нет. Ember-аддоны можно добавлять в ядро Discourse, но не через плагины. Возможно, в будущем мы добавим способ для плагинов и тем указывать зависимости npm, но это не входит в ближайшие планы.

9

Я буквально искал именно это в Google.

— Побочный вопрос к @david: раз это пока недоступно через плагины, можем ли мы теоретически добавить плагин в ядро, а затем использовать его в другом плагине, если мы сами хостим систему? Если да, то как? (Пытался добавить в package.json в app/assets/javascripts/discourse, но не вышло. Думаю, потому что я упускаю что-то простое.)

10

Да, но вам действительно не стоит форкать Discourse и затем пытаться подтянуть все коммиты. Все, кто это делал, очень сожалеют об этом.

Хм. Но если речь идет только об одном файле, вы теоретически могли бы настроить ваш app.yml так, чтобы он копировал файл откуда-то в /var/www/discourse сразу после клонирования Discourse. Мне кажется, я уже делал так, чтобы изменить лимиты в настройках сайта.

11

Да, как отметил @pfaffman, вы возможно сможете заставить это работать, внеся некоторые изменения в app.yml. Вам нужно будет убедиться, что эти изменения внесены до выполнения шагов yarn install и assets:precompile.

Однако это полностью не поддерживается и может привести к непредвиденным сбоям. Я бы не рекомендовал этого делать.

Из любопытства, какой аддон вы планировали использовать?

12

До этого я действительно не дошёл, однако я заметил, что у большинства популярных дополнений есть функционал, который уже встроен в сам Discourse. Привлекательность дополнений в том, что их документация обычно чуть лучше, а ресурсы, доступные в случае возникновения проблем, довольно подробно проработаны. Например, существует огромное количество документации и решений для задач, которые «решаются» с помощью ember-concurrency. Поэтому, если вы начинающий разработчик, наличие доступа к этому дополнению обычно позволяет быстрее начать работу.

Но, как я уже сказал, это было скорее любопытством, чем потребностью.

13

Так что вы буквально ищете проблемы. Я бы рекомендовал не рассматривать никакие дополнения, пока не убедитесь, что существующие ресурсы не удовлетворяют вашим потребностям.

Но вы не знаете, будет ли это совместимо с тем, как Discourse решает эту проблему сегодня или в будущем. Если вы хотите разрабатывать для Discourse, то изучение примеров того, как вещи работают в Discourse, — это правильный путь.

Не будьте тем парнем, который ищет ключи под фонарём, а не под машиной, где он их уронил, просто потому что под фонарём лучше видно.