我们可以在 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

我正在为同样的事情进行谷歌搜索。

– 一个关于 @david 的附加问题，虽然目前无法通过插件使用，但如果我们是自托管的话，我们能否在核心中添加一个插件，然后在一个插件中使用它？如果可以，该怎么做？（尝试在 app/assets/javascripts/discourse 的 package.json 中添加但没有成功加载，我想是因为我遗漏了什么简单的事情。）

1 个赞
10

是的，但你真的不想分叉 Discourse 然后尝试合并所有提交。所有这样做过的人都非常后悔。

嗯。但如果只有那一个文件，你可以在克隆 Discourse 后，让你的 app.yml 将该文件从某处复制到 /var/www/discourse。我想我以前这样做过，以更改站点设置中的限制。

2 个赞
11

正如 @pfaffman 所提到的，你或许可以通过修改 app.yml 来实现。你必须确保在 yarn install 和 assets:precompile 步骤之前完成修改。

但这完全不受支持，并且可能会导致意外问题。我不推荐这样做。

顺便问一下，你希望使用哪个插件？

2 个赞
12

我还没有深入研究，但我发现大多数流行的插件都具有 Discourse 本身已有的功能。插件的吸引力在于，它们的文档通常更好一些，而且当你遇到困难时，可用的资源也相当完善。例如，关于 ember-concurrency 有大量的文档和已“解决”的问题，所以如果你是一名新开发者，拥有该插件通常意味着你可以更容易地开始工作。

但正如我所说，这更多的是一种好奇，而不是一种需求。

1 个赞
13

所以你这是在自找麻烦。我建议在发现现有资源不能满足你的需求之前，不要考虑任何插件。

但是你不知道它是否会与 Discourse 今天或将来解决该问题的方式兼容。如果你想为 Discourse 开发，那么查看 Discourse 中事物工作方式的示例将是最佳选择。

不要成为那种在灯下找钥匙而不是在掉落钥匙的汽车下面找钥匙的人，因为你在灯下看得更清楚。