Können wir Ember Add-ons zu einem Discourse-Plugin hinzufügen? (wie Ember Power Select)

Entwickler
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
5

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

6 „Gefällt mir“
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

Ich frage mich nur, ob das heutzutage möglich ist? (Und wenn ja, wie?)

2 „Gefällt mir“
8

Das fürchte ich nicht. Ember-Add-ons können zu Discourse Core hinzugefügt werden, aber nicht über Plugins. Wir werden möglicherweise irgendwann eine Möglichkeit hinzufügen, damit Plugins/Themes npm-Abhängigkeiten angeben können, aber das steht nicht auf der unmittelbaren Roadmap.

2 „Gefällt mir“
9

Ich habe buchstäblich nach demselben gesucht.

– Nebenfrage an @david: Könnten wir theoretisch ein Plugin zu Core hinzufügen und es dann in einem Plugin verwenden, wenn wir selbst hosten? Wenn ja, wie? (Habe versucht, es in package.json unter app/assets/javascripts/discourse hinzuzufügen, aber es wurde nicht geladen, wahrscheinlich weil mir etwas Einfaches fehlt.)

1 „Gefällt mir“
10

Ja, aber Sie wollen Discourse wirklich nicht forken und dann versuchen, alle Commits zu übernehmen. Jeder, der das getan hat, bedauert es sehr.

Hmm. Aber wenn es nur diese eine Datei ist, könnten Sie sich vorstellen, dass Ihre app.yml die Datei von irgendwo in /var/www/discourse kopiert, direkt nachdem sie Discourse geklont wurde. Ich glaube, das habe ich schon einmal gemacht, um die Limits in den Site-Einstellungen zu ändern.

2 „Gefällt mir“
11

Ja, wie @pfaffman erwähnte, könnten Sie es möglicherweise durch einige Änderungen an der app.yml zum Laufen bringen. Sie müssten sicherstellen, dass die Änderung vor den Schritten yarn install und assets:precompile vorgenommen wurde.

Aber das ist absolut nicht unterstützt und kann unerwartete Dinge kaputt machen. Ich würde es nicht empfehlen.

Interessenshalber, welchen Addon wollten Sie hoffen zu verwenden?

2 „Gefällt mir“
12

Ich war noch nicht wirklich so weit, aber ich habe festgestellt, dass die meisten beliebten Add-ons Funktionalitäten bieten, die in Discourse selbst bereits vorhanden sind. Der Reiz von Add-ons liegt darin, dass die Dokumentation im Allgemeinen etwas besser ist und die verfügbaren Ressourcen, wenn man nicht weiterkommt, ziemlich gut ausgearbeitet sind. Zum Beispiel gibt es eine Fülle von Dokumentationen und gelösten Problemen für ember-concurrency, so dass es für einen neuen Entwickler normalerweise einfacher ist, mit diesem Add-on loszulegen.

Aber wie gesagt, es war mehr ein Staunen als ein Wunsch.

1 „Gefällt mir“
13

Sie suchen also buchstäblich Ärger. Ich würde empfehlen, kein Add-on in Betracht zu ziehen, bis Sie feststellen, dass die vorhandenen Ressourcen Ihre Bedürfnisse nicht erfüllen.

Aber Sie wissen nicht, ob es mit der Art und Weise kompatibel sein wird, wie Discourse dieses Problem heute oder in Zukunft löst. Wenn Sie für Discourse entwickeln möchten, ist es am besten, sich Beispiele anzusehen, wie Dinge in Discourse funktionieren.

Seien Sie nicht der Typ, der unter der Lampe nach seinen Schlüsseln sucht, anstatt unter dem Auto, wo er sie fallen gelassen hat, nur weil man unter der Lampe besser sehen kann.