Schnellere Plugin-Entwicklung durch Trennung des Frontends in eine Theme-Komponente

Entwickler
1

Ich habe zuvor gefragt, wie man die lokale Umgebung für schnelleres Coden beim Erstellen eines Plugins einrichtet, und ich weiß, dass andere das auch getan haben.

Ich habe einen neuen Workflow verwendet, der großartig funktioniert, und dachte, ich teile ihn, falls er für andere hilfreich ist. Er löst nicht alles, macht die Dinge aber viel angenehmer. Hier sind die Details:

Zuerst mein früheres Problem:

Um ein Plugin zu entwickeln, musste ich von einer lokalen Instanz von Discourse aus codieren, und das war wirklich langsam, weil: 1) jede Änderung an Dateien das Neuladen der Seite erforderte und mein Computer dies sehr langsam tat, wenn Discourse lief (etwa 30 Sekunden pro Seitenneuladung), 2) die lokale Discourse-Site für die Entwicklung, die ich testen würde, sehr langsam war (langsam zu navigieren usw.) und 3) jede Änderung am Backend-Plugin-Code das Stoppen und Neustarten des Servers erforderte – und das konnte einige Minuten dauern. Währenddessen würde der Lüfter meines Computers auf Hochtouren laufen.

Infolgedessen würde es wahrscheinlich eine Stunde dauern, um das zu codieren, was ich normalerweise mit einem reibungslosen Arbeitsablauf in etwa 10 Minuten codieren könnte.

Meine Lösung

Im Gegensatz zur Plugin-Entwicklung ist der Workflow für das Codieren einer Theme-Komponente dank des Discourse Theme CLI großartig. (Meine Schritte zur Verwendung finden Sie hier.) Es ist schnell und reibungslos.

Warum das Codieren eines Themes oder einer Theme-Komponente so viel schneller und einfacher ist

Mit dem Theme CLI-Tool können Sie ein Theme lokal codieren, aber “beobachten” (d. h. das Theme ausführen) auf einer Live-Site (entweder Ihrer tatsächlichen Site, Ihrer tatsächlichen Site, aber nur im Vorschau-Modus, oder einer Test-Live-Site, die Sie eingerichtet haben).

Sie müssen also Discourse selbst nicht auf Ihrem Computer ausführen – und daher verlangsamt sich mein Computer nicht, wie es bei einem Plugin der Fall wäre. Und wann immer Sie eine Änderung vornehmen, aktualisieren Sie einfach die Live-Site, mit der Sie verbunden sind, und die Änderung ist da.

Also, was ich erkannt habe: Die meiste Zeit, wenn ich ein Plugin codiere, handelt es sich tatsächlich um Frontend-Sachen (hbs-Dateien, JavaScript-Dateien usw.). Und nur ein kleiner Teil davon wird für Backend-Sachen verwendet (Einrichten von Routen, Erstellen benutzerdefinierter Felder usw.).

Anstatt alles zusammen zu codieren, verschieben Sie also einfach das gesamte Frontend-Codieren in eine Theme-Komponente, um den Workflow der Theme-Komponente zu nutzen.

Wenn ich die Backend-Sachen im Plugin aktualisieren muss, dann muss ich wieder im Plugin codieren – aber das ist nur etwa 20 % der Zeit (zumindest bei meiner Plugin-Entwicklung). Dadurch kann ich jetzt 80 % meiner Zeit mit dem viel schöneren Theme-Komponenten-Workflow verbringen.

Wenn es an der Zeit ist, alles in die Produktion zu verschieben, kann ich:

  • die Theme-Komponente und das Plugin getrennt halten und sie einfach beide auf der entsprechenden Discourse-Site verwenden, oder
  • wenn es wichtig ist, den gesamten Code an einem Ort zu haben, den Code der Theme-Komponente dann in das Plugin verschieben. Zugegebenermaßen kann das etwas mühsam sein, aber Sie müssten es nur tun, wenn Sie bereit sind, für die Produktion zu aktualisieren, und dabei den schnelleren Workflow der Theme-Komponente genießen.

Das ist alles.

Nicht revolutionär. Aber es hat die Dinge bei etwas, das mich eine Weile aufgehalten hat, erheblich verbessert.

7 „Gefällt mir“
2

Ja, das ist ein guter Ansatz.

Ich habe diesen Ansatz für Topic List Previews schon seit einiger Zeit verwendet, indem ich so viel Funktionalität wie möglich in das TC verlagert und es eigenständig gemacht habe. Zusätzliche Funktionen, die API-Änderungen erfordern, werden dann in ein Plugin ausgelagert und die Benutzer werden ermutigt, dieses ebenfalls zu installieren, um davon zu profitieren (wenn sie können).

Das einzige Problem bei diesem Ansatz ist, wenn Sie Ihren Code teilen und eine API-Änderung notwendig ist, dann müssen Sie sicherstellen, dass jemand beide Komponenten installiert. Die Aufteilung in zwei Teile ist potenziell nicht die bequemste Art, wie Leute Ihre Arbeit nutzen können, daher denke ich immer noch, dass letztendlich eine einzige Plugin-Installation für Open-Source-Arbeiten dieser Art immer noch der beste Ansatz ist.

Wenn es nur für Ihre eigene Website ist, dann ist das großartig!

3 „Gefällt mir“
3

Ja, es gibt sicherlich Situationen, in denen man am Ende eine einzige Codebasis haben möchte. Der Geistesblitz, den ich hatte, war, dass ich selbst dann, wenn ich am Ende eine einzige Codebasis haben möchte, die gesamte Frontend-Arbeit in der Theme-Komponente codieren könnte und sie dann, sobald sie funktioniert, in das Plugin verschieben könnte. Ein wenig mühsam, aber insgesamt viel besser für mich, weil ich die meiste Zeit immer noch im Workflow der Theme-Komponente mit dem Codieren verbringe.

2 „Gefällt mir“