Dinge, von denen ich wünschte, ich wüsste sie, bevor ich mit Electron.js arbeite

In diesem Artikel werde ich erläutern, wie Sie einige der Fehler vermeiden können, die ich beim Erlernen von Electron.js gemacht habe? ‍♂️. Ich hoffe, es hilft!

Hinweis : Dies ist kein Coding-Tutorial, sondern eine Diskussion über meine persönlichen Erkenntnisse.

Vor ein paar Monaten habe ich beschlossen, mich mehr auf den Aufbau meines Nebenprodukts taggr zu konzentrieren . Ich war inspiriert, es zu bauen, weil ich so viele Fotos auf meinem Computer habe.

Für diejenigen von uns, die ein Backup ihrer Bilder führen, werden diese Sammlungen oft so groß und komplex, dass sie zu einem Vollzeitjob werden. Eine Mischung aus Ordnern und Unterordnern kann Sofortnachrichtensicherungen, hochauflösende Bilder von Ihrer Reise nach Bali, der Hochzeit Ihres Onkels oder der Junggesellenparty im letzten Jahr enthalten.

Es ist mühsam , solche Sammlungen immer sauber zu halten (glauben Sie mir, ich habe es jahrelang versucht). Es ist auch schwerum die Aufnahmen zu entdecken, die Sie am meisten lieben, versteckt tief in den Ordnern.

Also taggrist eine Desktop-App, die dieses Problem löst. Damit können Benutzer ihre Erinnerungen neu entdecken und gleichzeitig ihre Privatsphäre schützen .

Ich erstelle taggr als plattformübergreifende Desktop-Anwendung. Hier werde ich einige der Dinge, die ich über die plattformübergreifende App-Entwicklung gelernt habe, mit Electron.js teilen, von denen ich wünschte, ich wüsste sie von Anfang an. Lass uns anfangen!

Hintergrund

Bevor ich meine Imbissbuden auf dieser laufenden Reise mit Electron vorstelle, möchte ich etwas mehr Hintergrundwissen über mich selbst und die Anforderungen von taggr geben .

Jeder Entwickler hat einen anderen Hintergrund, ebenso wie die Anforderungen der von ihm entwickelten Anwendungen.

Die Kontextualisierung der Entscheidungen, die ich für dieses Projekt getroffen habe, kann zukünftigen Entwicklern helfen, die richtigen Tools basierend auf ihren Anforderungen und ihrem Fachwissen auszuwählen (und nicht das, was da draußen gehypt wird - GitHub?, Ich sehe Sie an).

Wie bereits erwähnt, habe ich mir taggr von Anfang an als plattformübergreifende Anwendung vorgestellt. Die App würde aufgrund des Fokus auf Datenschutz alle erforderlichen Vorverarbeitungs- und maschinellen Lernberechnungen clientseitig durchführen.

Als Einzelausstellung wollte ich meine App einmal schreiben und an verschiedene Systeme senden können, ohne meine geistige Gesundheit zu verlieren.

Von meiner Seite bin ich ein Front-End-Ingenieur, der sich in das Web und JavaScript verliebt. Ich habe zuvor mit Java und C # gearbeitet, aber ich genieße die Flexibilität, die das Web bietet, und sein lebendiges Ökosystem.

Nachdem ich zuvor den Schmerz erlebt hatte, Tools wie Eclipse RCP zum Erstellen clientseitiger Apps zu verwenden, wusste ich, dass ich nicht wieder mit dieser Technologie arbeiten wollte.

Kurz gesagt, meine Stack-Anforderungen für taggr haben sich auf Folgendes reduziert:

  • Es sollte plattformübergreifende Unterstützung bieten , idealerweise auf Framework-Ebene. ?
  • Es sollte mir ermöglichen , den Code einmal zu schreiben und bei Bedarf für jede Plattform zu optimieren. ? ️
  • Es sollte den Zugriff auf maschinelle Lernfunktionen unabhängig von der Hostumgebung ermöglichen, ohne dass bestimmte Laufzeiten installiert werden müssen. Das Einrichten sollte schmerzlos sein. ?
  • Wenn möglich, sollten Webtechnologien verwendet werden . Es wäre großartig, mein vorhandenes Wissen zu nutzen. ?

Wie Sie sehen können, lauten die Anforderungen nicht wie folgt : Ich sollte React with Redux, Observables und WebSockets verwenden . Dies sind Implementierungsdetails auf niedrigerer Ebene, und sie sollten entschieden werden, wann und ob dies erforderlich ist.

Wählen Sie das richtige Werkzeug für den Job aus, anstatt von Anfang an einen Stapel auszuwählen, ohne die vorliegenden Probleme zu berücksichtigen.

Nachdem ich wütend gegoogelt hatte, beschloss ich, Electron auszuprobieren. Ich hatte dieses Framework zuvor noch nicht verwendet, aber ich wusste, dass viele Unternehmen es erfolgreich in Produkten wie Atom, VS Code, Discord, Signal, Slack und anderen einsetzen.

Electron.js war Open Source und mit sofort einsatzbereiter Kompatibilität mit dem JS- und dem Node-Ökosystem (Electron wird mit Chromium und Node erstellt) ein attraktives Tool für die vorliegende Arbeit.

Ich werde nicht zu sehr auf den Rest des Stapels eingehen, da ich bei Bedarf wiederholt die Kernteile (Persistenz- und Ansichtsebenen) geändert habe und dies nicht in den Geltungsbereich dieses Artikels fällt.

Ich möchte jedoch Tensorflow.js erwähnen, mit dem Schulungen ausgeführt und ML-Modelle direkt im Browser (mit WebGL) und Node (mit C-Bindungen) bereitgestellt werden können, ohne dass bestimmte Laufzeiten für ML auf dem Host installiert werden müssen.

Also zurück zu Electron - da es perfekt war, begann der Spaß. ??

Genug geredet über den Hintergrund. Lassen Sie uns in die Imbissbuden eintauchen.

1. Klein anfangen (und langsam)?

Dies ist kein neues Konzept, aber es lohnt sich, es regelmäßig zur Sprache zu bringen. Nur weil es eine Menge großartiger Starterprojekte mit Electron gibt, heißt das nicht, dass Sie sich sofort eines aussuchen sollten.

Warten. Was?

Langsam ist glatt und glatt ist schnell. - Navy Sprichwort

Mit der Bequemlichkeit geht Komplexität einher

Diese Starter enthalten zwar viele nützliche Integrationen (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), haben aber auch ihre Probleme.

Als Electron-Neuling habe ich mich für eine schlanke Vorlage entschieden, die die Grundlagen für das Erstellen, Veröffentlichen und Installieren von Electron-Apps ohne zusätzliche Schnickschnack enthält. Nicht einmal Webpack am Anfang.

Ich empfehle, mit etwas ähnlichem wie Electron-Forge zu beginnen, um schnell einsatzbereit zu seinRichten Sie Ihr Abhängigkeitsdiagramm und Ihre Struktur oben ein, um die Seile von Electron zu lernen.

Wenn die Probleme auftreten (und dies auch tun wird), sind Sie besser dran, wenn Sie Ihr benutzerdefiniertes Starterprojekt erstellen, anstatt zunächst eines mit +30 npm-Skripten und +180 Abhängigkeiten auszuwählen.

Sobald Sie sich mit der Basis von Electron vertraut gemacht haben, können Sie das Spiel mit Webpack / React / Redux / TheNextHotFramework verbessern. Ich habe es schrittweise und bei Bedarf gemacht. Fügen Sie Ihrer ToDo-App keine Echtzeitdatenbank hinzu, nur weil Sie irgendwo einen coolen Artikel darüber gelesen haben.

2. Strukturieren Sie Ihre App achtsam? ‍♂️

Dieser hat etwas länger gedauert, als ich zugeben möchte. ?

Am Anfang mag es verlockend sein, die Benutzeroberfläche und den Backend-Code (Dateizugriff, erweiterte CPU-Operationen) zu verwechseln , aber die Dinge werden ziemlich schnell komplex. Als meine Anwendung an Funktionen, Größe und Komplexität zunahm, wurde die Verwaltung einer verworrenen UI + Backend-Codebasis komplizierter und fehleranfälliger. Außerdem machte es die Kupplung schwierig, jedes Teil einzeln zu testen.

Wenn Sie eine Desktop-App erstellen, die mehr als eine eingebettete Webseite ausführt (DB-Zugriff, Dateizugriff, intensive CPU-Aufgaben…), empfehle ich, die App in Module zu unterteilen und die Kopplung zu verringern. Unit-Tests werden zum Kinderspiel, und es gibt einen klaren Weg zum Integrationstest zwischen den Modulen. Für taggr folgte ich locker der hier vorgeschlagenen Struktur.

Hinzu kommt die Leistung . Die Anforderungen und Benutzererwartungen in dieser Angelegenheit können je nach der von Ihnen erstellten Anwendung stark variieren. Das Blockieren der Haupt- oder Renderthreads mit teuren Aufrufen ist jedoch niemals eine gute Idee.

3. Design unter Berücksichtigung des Gewindemodells?

Ich werde hier nicht zu sehr ins Detail gehen - ich verdopple nur hauptsächlich das, was in den offiziellen Dokumenten unglaublich erklärt wird.

Im speziellen Fall von taggr gibt es viele lang laufende CPU-, GPU- und E / A-intensive Vorgänge. Wenn Sie diese Vorgänge im Haupt- oder Renderer-Thread von Electron ausführen, sinkt die FPS-Zahl von 60, wodurch sich die Benutzeroberfläche träge anfühlt.

Electron bietet verschiedene Alternativen zum Auslagern dieser Vorgänge aus den Haupt- und Renderer-Threads , z. B. WebWorkers, Node Worker-Threads oder BrowserWindow-Instanzen. Jedes hat seine Vorteile und Vorbehalte, und der Anwendungsfall, dem Sie gegenüberstehen, bestimmt, welcher am besten passt.

Unabhängig davon, für welche Alternative Sie sich entscheiden, um die Vorgänge aus den Haupt- und Renderer-Threads zu entfernen (falls erforderlich), sollten Sie überlegen, wie die Kommunikationsschnittstelle aussehen soll . Es hat eine Weile gedauert, bis ich eine Oberfläche gefunden habe, mit der ich zufrieden war, da sie die Struktur und Funktion Ihrer Anwendung stark beeinflusst. Ich fand es hilfreich, mit verschiedenen Ansätzen zu experimentieren, bevor ich einen auswählte.

Wenn Sie beispielsweise der Meinung sind, dass die WebWorkers-Schnittstelle für die Nachrichtenübermittlung möglicherweise nicht am einfachsten zu debuggen ist, probieren Sie comlink aus.

4. Test ❌, Test ❌ und Test ✔️

Alte Nachrichten, richtig? Ich wollte dies als letzten Punkt hinzufügen, aufgrund einiger anekdotischer "Probleme", mit denen ich kürzlich konfrontiert war. Durch die enge Verknüpfung mit dem ersten und zweiten Punkt können Sie wertvolle Debugging-Zeit in der Entwicklung sparen, indem Sie Ihr benutzerdefiniertes Starterprojekt erstellen und frühzeitig Fehler machen.

Wenn Sie meinen Empfehlungen zur Aufteilung der Benutzeroberfläche und des Backends der App in Module mit einer sauberen Schnittstelle zwischen beiden gefolgt sind, sollte das Einrichten automatisierter Unit- und Integrationstests einfach sein. Wenn die Anwendung ausgereift ist, möchten Sie möglicherweise auch Unterstützung für e2e-Tests hinzufügen.

GPS-Standortextraktion? ️

Vor zwei Tagen, als die GPS-Standortextraktionsfunktion für taggr implementiert wurde, entschied ich mich, sie in der Produktionsumgebung zu testen , nachdem die Komponententests grün waren und die Funktion in der Entwicklung (mit Webpack) funktionierte.

Während das Feature in der Entwicklung gut funktionierte, schlug es in der Produktion kläglich fehl. Die EXIF-Informationen aus den Bildern wurden als binär gelesen und von einer Bibliothek eines Drittanbieters verarbeitet. Während die binären Informationen in beiden Umgebungen korrekt geladen wurden (mit diff überprüft), schlug die Bibliothek eines Drittanbieters beim Parsen solcher Daten im Produktionsbuild fehl. Entschuldigen Sie, ??

Lösung : Ich habe festgestellt, dass die von Webpack festgelegten Codierungseinstellungen in den Entwicklungs- und Produktionsumgebungen nicht identisch sind. Dies führte dazu, dass die Binärdaten in der Entwicklung, jedoch nicht in der Produktion als UTF-8 analysiert wurden. Das Problem wurde behoben, indem die richtigen Codierungsheader in den von Electron geladenen HTML-Dateien eingerichtet wurden.

Funky Bilder?

Wenn Sie Bilder bearbeiten und damit arbeiten, denken Sie möglicherweise, dass ein JPEG, das auf Ihrem Computer nur funktioniert, ein gültiges JPEG ist. Falsch .

Während der Arbeit mit der Node-Bildverarbeitungsbibliothek scharf hat die Größe einiger JPEG-Bilder die App zum Absturz gebracht. Bei genauerer Betrachtung waren die von der Samsung-Firmware erzeugten falschen JPEG-Bilder die Ursache. ? ‍♂️

Lösung : Einrichten verbesserter Fehlergrenzen in der App (z. B. Try-Catch-Blöcke), Optimieren des JPEG-Parsing-Moduls und Verdacht auf alles. ? ️

Zusammenfassung

Die Node- und JavaScripts-Ökosysteme blühen auf, und jeden Tag werden viele leistungsstarke Tools erstellt und gemeinsam genutzt.

Die Vielzahl der Optionen macht es schwierig, einen klaren Weg für die Erstellung Ihrer neuen fantastischen Electron-App zu finden. Unabhängig von den von Ihnen gewählten Rahmenbedingungen würde ich empfehlen, sich auf Folgendes zu konzentrieren:

  1. Fangen Sie klein an und erhöhen Sie die Komplexität schrittweise.
  2. Strukturieren Sie Ihre App achtsam , halten Sie das Backend und die Benutzeroberfläche modularisiert.
  3. Entwerfen Sie unter Berücksichtigung des Threading-Modells , auch beim Erstellen kleiner Apps.
  4. Testen und erneut testen , um die meisten Fehler frühzeitig zu erkennen und Kopfschmerzen zu vermeiden.

Danke, dass du bis zum Ende dabei bist! ?

taggr ist eine plattformübergreifende Desktop-Anwendung, mit der Benutzer ihre digitalen Erinnerungen unter Wahrung ihrer Privatsphäre neu entdecken können . Open-Alpha ist in Kürze für Linux, Windows und Mac OS verfügbar. Behalten Sie also Twitter und Instagram im Auge, wo ich Entwicklungsupdates, kommende Funktionen und Neuigkeiten veröffentliche.