DiscourseプラグインにEmberアドオン（Ember Power Selectなど）を追加できますか？

開発
1

I’d like to add some ember add-ons to a plugin.

Here’s an example: Ember’s Power Select.

(This helps with drop-downs. Discourse uses select-kit, which I know is also powerful, but I find it hard to customize because its heavily abstracted in the code base. So I’d like to try power select).

In a normal Rails/Ember app, I think I would just add the add-on with:

$ ember install ember-power-select

Then I’d add stuff like the following:

hbs template:

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

javascript file that goes along with it:

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

But a Discourse plugin is not a standard Rails app. Is there something special I need to do to get it working?

「いいね！」 3
2

Well, I watched this wondering if you’d get any hints, but here we are 4 days later.

I’m pretty novice at Ember, but I’m fairly certain that you’ll be much better off if you manage to deal with the “heavily abstracted” stuff and play by those rules. Not only is pulling in other add-ons hard to figure out, but it’s also going to be hard to maintain.

「いいね！」 1
3

We are upgrading Discourse over to EmberCLI, and we are pretty close to it now:

4

Thanks, all.

I’d seen that before, but am glad to have the confirmation that it is not possible to add Ember add-ons until that upgrade is done. So it sounds like adding ember add-ons will be possible soon–once the upgrade is complete. And that sounds great.

I think that’s an interesting question. Here’s my two cents:

In terms of using the discourse “abstracted stuff” v ember add-ons: I could be wrong, but I think that using ember add-ons for specific tasks in plugins might be easier to maintain, in the cases where you are trying to do something different than what Discourse is doing already. This is my thinking:

Example here is wanting to add a brand new drop-down in a plugin. That distinction is probably important–I’m talking here about trying to do new things in a plugin that are not done in the discourse code-base, and the question is whether to start with discourse methods or a separate add-on.

A lot of times you really don’t have a choice. For example, if I wanted to add a custom field to topics, I’d always customize on top of discourse’s pre-built methods and code.

But If its a targeted piece of functionality–like a drop-down for a new purpose–I’d already be in the case where, if I use the discourse methods, I’d be adapting them to things they weren’t targeted towards.

Option 1: I could try to take the select-kit code I see in, say, category-chooser, and insert it in a new spot (that’s not about categories), and then try to customize it to be about what I want the dropdown to be about, instead of categories. This is the task that I described earlier as being tricky.

And it could be difficult to maintain–because if the discourse team changes something in how the category-chooser select-kit code works, then that could change my new customized drop-down, but in ways that could be surprising (bc I had customized it so it works slightly differently than the actual category-choose dropdown).

Option 2: I could insert something from ember that is robust but that is also made to be customized, where I can see fairly clearly how the code actually works. In that case, I might miss out cool new features that discourse might add to its drop-downs, but I would be able to stay on top of how my drop-down works more easily. So this is probably the best option, I think, if it is possible.

Option 3: Code it entirely from scratch. That’s where I’ve been tending to end up. When the coding is done, it’s nice to have code that I fully understand and can customize. But of course it takes longer, and (the initial versions at least) are unlikely to be as powerful and robust as what the discourse team or the ember team have built.

「いいね！」 3
5

Bump, and to add it would be great to add support for Ember add-ons to Theme Components …

「いいね！」 6
6

Bump.
If we add addon to discourse such
cd app/assets/javascripts/ && yarn add LIB_NAME
How will this addon be available in the plugin?

7

これは最近可能なのでしょうか？（可能であれば、どのように？）

「いいね！」 2
8

残念ながら、できません。EmberアドオンはDiscourseコアに追加できますが、プラグイン経由では追加できません。将来的には、プラグイン/テーマがnpm依存関係を指定する方法を追加するかもしれませんが、それは当面のロードマップにはありません。

「いいね！」 2
9

まさにこのことをGoogleで検索していました。

– @davidへのサイド質問ですが、プラグイン経由では利用できませんが、理論的にはコアにプラグインを追加してから、セルフホスティングしている場合にプラグイン内で使用することは可能でしょうか？もし可能なら、どのようにすればよいですか？（app/assets/javascripts/discourse で package.json に追加しようとしましたが、単純な何かを見落としているためか、ロードできませんでした。）

「いいね！」 1
10

はい、できます。しかし、Discourseをフォークして、すべてのコミットを取り込もうとするのは実際にはお勧めできません。そうした人は皆、やったことを非常に後悔しています。

うーん。しかし、それが1つのファイルだけであれば、app.ymlがDiscourseをクローンした直後に、そのファイルをどこかから/var/www/discourseにコピーするように設定できるはずです。サイト設定の制限を変更するために、以前にそのようなことをしたことがあると思います。

「いいね！」 2
11

@pfaffman が言及したように、app.yml の変更によって動作するようにハッキングできる 可能性 があります。yarn install および assets:precompile ステップの前に変更が行われたことを確認する必要があります。

しかし、これは完全にサポートされておらず、予期しない問題を引き起こす可能性があります。お勧めしません。

興味本位で、どの Дополнение (addon) を使用したいと思っていましたか？

「いいね！」 2
12

そこまで深くは調べていませんが、多くの人気アドオンには、Discourse 自体に既に存在する機能があることがわかりました。アドオンの魅力は、一般的にドキュメントが少し優れており、行き詰まった場合の利用可能なリソースがかなり充実していることです。例えば、ember-concurrency には豊富なドキュメントと「解決済み」の問題があり、新規開発者であれば、そのアドオンを利用することで、より簡単に作業を開始できるでしょう。

しかし、言ったように、それは欲求というよりも疑問でした。

「いいね！」 1
13

つまり、あなたは文字通り面倒を探しているのです。既存のリソースでニーズが満たされないことが判明するまで、アドオンを検討しないことをお勧めします。

しかし、それが Discourse が今日または将来その問題を解決する方法と互換性があるかどうかはわかりません。Discourse のために開発したいのであれば、Discourse で物事がどのように機能するかを示す例を見るのが良いでしょう。

鍵を落とした車の下ではなく、ランプの下で探している人にならないでください。ランプの下の方がよく見えるからです。