谢谢大家。
我之前就注意到过这一点，但很高兴得到确认：在该升级完成之前，无法添加 Ember 插件。听起来，一旦升级完成，添加 Ember 插件很快就会成为可能。这听起来很棒。
我认为这是一个有趣的问题。以下是我的两点看法：
关于使用 Discourse 的“抽象内容”与 Ember 插件：我可能错了，但在某些情况下，如果你想在插件中实现与 Discourse 现有功能不同的特定任务，使用 Ember 插件可能会更容易维护。我的思路如下：
这里的例子是想要在插件中添加一个全新的下拉菜单。这个区别可能很重要——我指的是在插件中尝试实现 Discourse 代码库中尚未实现的新功能，问题在于是应该从 Discourse 的方法入手，还是使用独立的插件。
很多时候你确实没有选择。例如，如果我想为话题添加一个自定义字段，我肯定会基于 Discourse 的预建方法和代码进行定制。
但如果是一个有针对性的功能模块——比如用于新目的的下拉菜单——那么情况就不同了：如果我使用 Discourse 的方法，我就得将它们适配到原本并非针对这些用途的场景中。
选项 1：我可以尝试从 category-chooser 等组件中看到的 select-kit 代码，将其插入到一个新的位置（与类别无关），然后尝试将其定制为我想要的下拉菜单内容，而不是类别。这就是我前面提到的那个棘手的任务。
而且这可能难以维护——因为如果 Discourse 团队改变了 category-chooser 中 select-kit 代码的工作方式，那可能会以意想不到的方式影响我新定制的下拉菜单（因为我已将其定制得与实际的 category-chooser 下拉菜单略有不同）。
选项 2：我可以插入一个来自 Ember 的组件，它既稳健又易于定制，并且我能相对清楚地看到代码的实际运作方式。在这种情况下，我可能会错过 Discourse 为其下拉菜单添加的新功能，但我能更容易地掌控我的下拉菜单的运作方式。因此，如果可行的话，我认为这可能是最佳选择。
选项 3：完全从头编写代码。这正是我目前倾向于采用的方式。代码完成后，拥有我完全理解并可自由定制的代码确实令人满意。但当然，这需要更长时间，而且（至少在初始版本中）不太可能像 Discourse 团队或 Ember 团队构建的功能那样强大和稳健。