Ist es möglich, eine In-Repo-Addon-Struktur zu erstellen, die optional ein Basis-Addon erweitert, aber die App davon nichts weiß?

Question

Ich versuche, ein Base-In-Repo-Addon zu machen, das Funktionalität über Namespace wie platform/services/whatever bietet.

Zusätzlich zu, dass ich will, wenn ein anderes Addon isEnabled(), die oder öffnet wieder den gleichen Service erstreckt (in irgendeiner Weise) Ich will es alle zusammengeführt werden, ohne dass das zweite Addon Dienst wie platform-second/services/whatever beim Namen zu nennen, die

Ich möchte nur eine schöne, saubere Abstraktion. Der Grund, warum ich es so mache, ist, dass ich basierend auf einer ENV-Variablen verschiedene Inhalte in index.html und verschiedene app.imports erstellen/einfügen muss.

und ich möchte, dass es vollständig in einzelne kleine In-Repo-Addons getrennt wird, um es sauber zu halten.

Ich möchte die App nicht wissen, die platform, sondern nur in der Lage, Methoden der allgemeinen platform Addon zu verwenden.

So könnte zum Beispiel platform.services.whatever.myMethod() standardmäßig ein noOp sein, aber wenn das zweite Addon das erweitert und das implementiert, wird stattdessen diese Version ausgelöst.

Frage mich, ob ich mache keinen Sinn überhaupt LOL

Wenn Sie irgendwelche Tipps oder Ratschläge auf, wie man dieses Setup implementieren könnte, lassen Sie es mich wissen.

Im Moment habe ich die in-Repo-Addons gebaut, aber im Idealfall würde ich die Basis platform Addon derjenige sein, der tatsächlich hat die app Ordnerinhalte und die anderen Addons, dass „verlängern“ oder „überschreiben“ die Methoden/Eigenschaften Die Objekte dieses Addons wären nur isEnabled() basierend auf dieser ENV-Variable.

Ich sollte hinzufügen, dass ich nicht einfach Baum zusammenführen und die ursprüngliche Datei überschreiben kann, weil ich die Basisfunktionalität dieser Dateien benötige.

Also, wenn ich eine Methode der Basis platform.services.whatever.myMethod() erweitern, dann brauche ich noch den Rest dieser Dienste Methoden und Eigenschaften.

Answer 1

Also ist es schwer für mich, zu spezifisch zu sein, weil Ihre Frage ein wenig vage bezüglich der Details war, aber keine Sorgen. Ich werfe ein paar Ideen auf und wir können hoffentlich einige nützliche Schlussfolgerungen daraus ziehen :)

Wenn Sie zur Laufzeit verschiedene Objekte benötigen, besteht der Trick darin, je nach Konfiguration unterschiedliche Versionen Ihres Dienstes im Abhängigkeitsinjektionscontainer zu registrieren ist üblich bei DI-basierter Programmierung). Also haben Sie Ihren Basisdienst in Ihrem Addon und sogar einige konkrete Implementierungen, die die Basis mit verschiedenen Implementierungen bestimmter Methoden erweitern. Und dann haben Sie in Ihrer App einen Initialisierer, der die verschiedenen ENV-Variablen betrachtet und festlegt, welche der Dienste injiziert werden sollen. Sie injizieren immer unter dem gleichen Schlüssel service:some-service. So können Sie mit baseClass = Ember.Object.extend() und impl1 = baseClass.extend({methodToOverride: ...} alle baseClass-Methoden außer den überschriebenen Methoden beibehalten. So haben Sie erfolgreich die Anrufer zu vermeiden, die wissen, ob einiger Elternteil oder Kind ist der Umgang mit service.someMethod

Nun, wenn es nur zum Zeitpunkt der Erstellung ist, dann in node.js Land (require() und module.exports. Mit POJOs oder es6 Sie eine Nummer haben Möglichkeiten zur Vererbung (Prototyp Vererbung, $ .Extend zum hierarchischen Verschmelzen von Pojos, es6 extends) ... wählen Sie.Aber gerade aus der Sicht eines Entwurfsmusters für Programmierungen scheint es, als müsste Ihr Addon eine Factory verfügbar machen, die die Erstellung eines Objekts abstrahiert, das einer Schnittstelle entspricht. Exportieren Sie also ein Modul, das über eine create-Methode verfügt, die ein options-Objekt aufnimmt und das korrekte impl zurückgibt.