Ich schätze die Flexibilität, die volle Komponenten-API zur Verfügung zu haben. Mir gefällt die Syntax von Glimmer-Komponenten insgesamt, und ich sehe, warum sie Vorteile bei der Reduzierung der Komplexität des Codebestands haben mag.
Für einfache Anwendungsfälle (ich möchte einen Button hinzufügen und ihm ein Icon geben) waren die alten API-Methoden jedoch objektiv kürzer und leichter verständlich (weniger Importe, weniger Operationen, weniger exponierter API-Fußabdruck). Gibt es einen Grund, warum die alten API-Methoden keine fortgesetzte Unterstützung genießen könnten? Ich stelle mir vor, wenn Sie sie als Komfortfunktionen verwenden und die zugrunde liegende Implementierung mit Ihrer neuen Glimmer-Komponente durchführen würden, dann könnte die API-Methode auch die Versionskompatibilitätsprüfung durchführen.
Dies wäre für jeden, der diese Methoden verwendet, weitaus weniger störend und würde zu weniger Code-Explosionen von bedingter Logik im Plugin-Ökosystem führen.
Meine Hauptbeschwerde über die vorhandenen Widgets ist deren mangelnde Dokumentation. Dieser Beitrag, der ihre Entfernung ankündigt, ist eines der klarsten Dokumente, die ich gesehen habe, dass diese speziellen Methoden existieren und wie man sie verwendet. Ich bin tatsächlich hierher gekommen, um herauszufinden, wie man die alte API verwendet.
Mir gefällt, dass Transformer an einem Ort, mit String-Literalen registriert werden. Ich denke, das erleichtert die Dokumentation (und die Plugin-Entwicklung) erheblich.
Bei Widgets scheinen sie alle über die Methode createWidget registriert zu werden, die dann createWidgetFrom aufruft. Das Problem, das ich hier sehe, ist, dass das _Registry eine globale Variable im Dateibereich ist, die durch eine API geschützt ist, und die API keine Iteration zulässt. Wenn wir eine Iterationsfunktion für das Widget-Registry erhalten könnten, könnten wir in Echtzeit die aktuell registrierten Widgets entdecken. Es sollte dokumentiert werden: “Führen Sie diese Zeile JavaScript in Ihrer Browserkonsole aus, um die API aufzurufen und das Registry aufzulisten”. Dann könnten wir eine sehr ähnliche Funktionalität erhalten, wie sie das Transformer-Registry bietet.
Eine weitere Sache, die bei der Plugin-Entwicklung helfen würde, wäre, ein Attribut auf jedem Root-DOM-Element zu sehen, das von einer Komponente/einem Widget gerendert wird und Ihnen mitteilt, welche Komponente/welches Widget Sie gerade betrachten. Wie z.B. “data-widget=foo”. Dies könnte eine Debugging-Funktion sein oder einfach standardmäßig aktiviert sein. Es ist OSS, also ist es nicht so, als würden Sie Sicherheit durch Obskurität erreichen.
Ich feiere den Wandel hin zu Glimmer-Komponenten. Aber das wird Zeit brauchen, und es gibt viele Widgets, mit denen die Leute in der Zwischenzeit arbeiten müssen. Daher denke ich, dass die Verbesserung der Sichtbarkeit von Widgets, wie oben erwähnt, den Übergangszeitraum für alle wahrscheinlich erleichtern würde.
Was diese API-Methoden betrifft… Es sieht so aus, als ob jemand sich die Mühe gemacht hat, detaillierte Kommentare zur JavaScript-API hinzuzufügen, aber es wurde nie eine Dokumentationsseite dafür generiert. Warum nicht?
Ich würde gerne einen Pull-Request zum Iterieren durch das Widget-Registry einreichen, wenn das in Ordnung ist.