(Dies hilft bei Dropdown-Menüs. Discourse verwendet select-kit, das zwar ebenfalls leistungsstark ist, aber ich finde es schwer anzupassen, da es in der Codebasis stark abstrahiert ist. Daher möchte ich Power Select ausprobieren).
In einer normalen Rails/Ember-Anwendung würde ich das Add-on einfach mit folgendem Befehl installieren:
$ ember install ember-power-select
Anschließend würde ich Dinge wie das folgende hinzufügen:
hbs-Template:
<PowerSelect @options={{this.names}} @onChange={{this.foo}} as |name|>
{{name}}
</PowerSelect>
JavaScript-Datei, die dazu gehört:
import Controller from '@ember/controller';
export default class extends Controller {
names = ['Stefan', 'Miguel', 'Tomster', 'Pluto']
foo() { }
}
Ein Discourse-Plugin ist jedoch keine Standard-Rails-Anwendung. Gibt es etwas Besonderes, das ich tun muss, damit es funktioniert?
Das hatte ich schon gesehen, aber es freut mich, die Bestätigung zu erhalten, dass es nicht möglich ist, Ember-Add-ons hinzuzufügen, bevor dieses Upgrade abgeschlossen ist. Es klingt also so, als ob das Hinzufügen von Ember-Add-ons bald möglich sein wird – sobald das Upgrade abgeschlossen ist. Das klingt großartig.
Ich finde das eine interessante Frage. Hier meine zwei Cent:
Im Hinblick auf die Nutzung der „abstrahierten Dinge“ von Discourse im Vergleich zu Ember-Add-ons: Ich könnte mich irren, aber ich denke, dass die Verwendung von Ember-Add-ons für bestimmte Aufgaben in Plugins in Fällen, in denen Sie etwas anderes tun möchten als das, was Discourse bereits bietet, einfacher zu warten sein könnte. So denke ich:
Ein Beispiel hierfür ist der Wunsch, in einem Plugin ein brandneues Dropdown-Menü hinzuzufügen. Dieser Unterschied ist wahrscheinlich wichtig – ich spreche hier davon, in einem Plugin neue Dinge zu tun, die im Discourse-Codebase noch nicht umgesetzt sind, und die Frage ist, ob man mit Discourse-Methoden oder einem separaten Add-on beginnen sollte.
Oft haben Sie gar keine andere Wahl. Wenn ich beispielsweise ein benutzerdefiniertes Feld für Themen hinzufügen möchte, würde ich immer auf den vorgefertigten Methoden und dem Code von Discourse aufbauen.
Aber wenn es sich um eine gezielte Funktionalität handelt – wie ein Dropdown-Menü für einen neuen Zweck – befinde ich mich bereits in einer Situation, in der ich, wenn ich die Discourse-Methoden verwende, diese an Dinge anpassen müsste, für die sie nicht vorgesehen waren.
Option 1: Ich könnte versuchen, den select-kit-Code, den ich beispielsweise im category-chooser sehe, an einer neuen Stelle einzufügen (die nichts mit Kategorien zu tun hat), und ihn dann so anzupassen, dass er das tut, was ich vom Dropdown-Menü erwarte, statt Kategorien auszuwählen. Das ist die Aufgabe, die ich zuvor als knifflig beschrieben habe.
Und es könnte schwierig zu warten sein – denn wenn das Discourse-Team etwas daran ändert, wie der select-kit-Code im category-chooser funktioniert, könnte das auch mein neu angepasstes Dropdown-Menü beeinflussen, und zwar auf unerwartete Weise (da ich es so angepasst habe, dass es sich leicht von der tatsächlichen Kategorie-Auswahl unterscheidet).
Option 2: Ich könnte etwas aus Ember einfügen, das robust ist, aber auch so gestaltet wurde, dass es sich anpassen lässt, und bei dem ich relativ klar erkennen kann, wie der Code tatsächlich funktioniert. In diesem Fall könnte ich zwar coole neue Funktionen verpassen, die Discourse möglicherweise zu seinen Dropdown-Menüs hinzufügt, aber ich könnte leichter den Überblick darüber behalten, wie mein Dropdown-Menü funktioniert. Das ist also wahrscheinlich die beste Option, meiner Meinung nach, falls dies möglich ist.
Option 3: Es komplett von Grund auf neu programmieren. Dorthin tendiere ich oft am Ende. Wenn die Programmierung abgeschlossen ist, ist es schön, Code zu haben, den ich vollständig verstehe und anpassen kann. Aber natürlich dauert es länger, und (zumindest die ersten Versionen) sind wahrscheinlich nicht so leistungsfähig und robust wie das, was das Discourse-Team oder das Ember-Team entwickelt haben.
Bump.
Wenn wir ein Addon zu Discourse hinzufügen, z. B. cd app/assets/javascripts/ && yarn add LIB_NAME
wie wird dieses Addon dann im Plugin verfügbar sein?
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.
– 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.)
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.
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?
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.
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.