Ting, jeg ønsker jeg vidste, før jeg arbejdede med Electron.js

I denne artikel fortæller jeg, hvordan du kan undgå nogle af de fejl, jeg lavede, da jeg lærte om Electron.js? ‍♂️. Jeg håber det hjælper!

Bemærk : Dette er ikke en kodningsvejledning, men snarere en diskussion om mine personlige takeaways.

For et par måneder tilbage besluttede jeg at fokusere mere på at opbygge mit sideprodukt , taggr . Jeg blev inspireret til at bygge den på grund af hvor mange fotos jeg har på min computer.

For dem af os, der holder en sikkerhedskopi af deres billeder, bliver disse samlinger ofte så store og komplekse, at de bliver et fuldtidsjob at administrere. En blanding af mapper og undermapper kan indeholde billedbackups til instant messaging, billeder i høj opløsning fra din rejse til Bali, din onkels bryllup eller sidste års bachelorparty.

Det er kedeligt at holde sådanne samlinger ryddelige (tro mig, jeg har prøvet i årevis). Det er også sværtat opdage de skud, du elsker mest, skjult dybt inde i mapperne.

taggrer en desktop-app, der løser dette problem. Det giver brugerne mulighed for at genopdage deres minder, mens de bevarer deres privatliv .

Jeg bygger taggr som en platform-applikation på tværs af platforme. Her deler jeg nogle af de ting, jeg har lært om udvikling af app på tværs af platforme med Electron.js, som jeg ville ønske, jeg vidste fra starten. Lad os komme igang!

Baggrund

Før jeg præsenterer mine takeaways på denne igangværende rejse med Electron, vil jeg gerne give lidt mere baggrund om mig selv og kravene i taggr .

Hver udvikler kommer fra en anden baggrund, og det samme gør kravene til de applikationer, de udvikler.

Kontekstualisering af de valg, jeg tog til dette projekt, kan hjælpe fremtidige udviklere med at vælge de rigtige værktøjer baseret på deres behov og ekspertise (snarere end hvad der hypes derude - GitHub? Jeg ser på dig).

Som nævnt tidligere forestillede jeg mig fra starten af taggr som en applikation på tværs af platforme. Appen udfører alle de krævede forbehandlings- og maskinlæringsberegninger på klientsiden på grund af fokus på privatlivets fred.

Som en en-person-show ville jeg være i stand til at skrive min app en gang og sende den til forskellige systemer uden at miste min forstand.

Fra min side er jeg en frontend engineer, der er forelsket i internettet og JavaScript. Jeg har tidligere arbejdet med Java og C #, men jeg nyder den fleksibilitet, som internettet giver, og dets livlige økosystem.

Efter at have oplevet smerte ved første hånd at bruge værktøjer som Eclipse RCP til at opbygge apps på klientsiden før, vidste jeg, at jeg ikke ønskede at arbejde med den teknologi igen.

Kort sagt kogte mine stakkrav til taggr ned til noget som følgende:

  • Det skal yde supporttværs af platforme, ideelt set på rammeniveau. ?
  • Det skulle tillade mig at skrive koden en gang og om nødvendigt justere for hver platform. ? ️
  • Det skal muliggøre adgang til maskinlæringsfunktioner , uanset værtsmiljøet, uden at der installeres specifikke driftstider. Det skal være smertefrit at opsætte. ?
  • Hvis det er muligt, skal det bruge webteknologier . Det ville være dejligt at udnytte min eksisterende viden. ?

Som du kan se, læses kravene ikke som: Jeg skal bruge React with Redux, observerbare og WebSockets . Disse er implementeringsdetaljer på lavere niveau, og de bør besluttes, hvornår og hvis behovet opstår.

Vælg det rigtige værktøj til jobbet i stedet for at vælge en stak fra begyndelsen og se bort fra de aktuelle problemer.

Så efter rasende googling besluttede jeg at prøve Electron. Jeg havde ikke brugt den ramme før, men jeg vidste, at mange virksomheder brugte den med succes i produkter som Atom, VS Code, Discord, Signal, Slack og mere.

Open source og med out-of-the-box kompatibilitet med både JS- og Node-økosystemerne (Electron er bygget ved hjælp af Chromium og Node), var Electron.js et attraktivt værktøj til det aktuelle arbejde.

Jeg vil ikke gå for meget i detaljer med hensyn til resten af ​​stakken, da jeg gentagne gange har ændret kernedele (vedholdenhed og visningslag), når det er nødvendigt, og det falder uden for denne artikels anvendelsesområde.

Jeg vil dog gerne nævne Tensorflow.js, som muliggør kørsel af træning og implementering af ML-modeller direkte i browseren (med WebGL) og Node (med C-bindinger) uden at installere specifikke driftstider for ML i værten.

Så tilbage til Electron - tænkte det var perfekt, det sjove begyndte. ??

Tal nok om baggrunden. Lad os dykke ned i takeaways.

1. Start lille (og langsom)?

Dette er ikke et nyt koncept, men det er værd at bringe det op med jævne mellemrum. Bare fordi der er masser af fantastiske startprojekter med Electron tilgængelige, betyder det ikke, at du skal vælge en med det samme.

Vente. Hvad?

Langsom er glat, og glat er hurtig. - Navy ordsprog

Med bekvemmelighed kommer kompleksitet

Mens disse startere inkluderer mange nyttige integrationer (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), har de også deres problemer.

Som elektronbegynder besluttede jeg at gå efter en slank skabelon, der indeholdt det grundlæggende for 'at oprette, udgive og installere elektronapps' uden de ekstra klokker og fløjter. Ikke engang Webpack i starten.

Jeg anbefaler at starte med noget, der ligner elektron-smedning for at komme i gang hurtigt, det kan duopsæt din afhængighedsgraf og struktur ovenpå for at lære rebene i Electron.

Når problemerne kommer (og de vil), har du det bedre, hvis du bygger dit brugerdefinerede startprojekt i stedet for at vælge et med +30 npm-scripts og +180 afhængigheder til at begynde med.

Når det er sagt, når du først har det godt med Electrons basis, er du velkommen til at intensivere spillet med Webpack / React / Redux / TheNextHotFramework. Jeg gjorde det trinvist, og når det var nødvendigt. Føj ikke en realtidsdatabase til din todo-app, bare fordi du læser en cool artikel om den et eller andet sted.

2. Er du opmærksom på at strukturere din app? ‍♂️

Denne tog lidt længere tid at få ret, end jeg med glæde erkender. ?

I begyndelsen kan det være fristende at blande UI og Backend-koden (filadgang, udvidede CPU-operationer), men tingene bliver komplicerede ret hurtigt. Da min applikation voksede i funktioner, størrelse og kompleksitet, blev vedligeholdelse af en sammenfiltret UI + Backend-codebase mere kompliceret og fejlbehæftet. Koblingen gjorde det også svært at teste hver del isoleret.

Når du bygger en desktop-app, der gør mere end en integreret webside (DB-adgang, filadgang, intensive CPU-opgaver ...), anbefaler jeg at skære appen i moduler og reducere koblingen. Enhedstestning bliver en leg, og der er en klar vej mod integrationstest mellem modulerne. For taggr , jeg løseligt fulgt strukturen foreslås her.

Derudover er der ydeevne . Kravene og brugerforventningerne i denne sag kan variere voldsomt afhængigt af den applikation, du bygger. Men at blokere hoved- eller gengivelsestråde med dyre opkald er aldrig en god idé.

3. Design med trådmodellen i tankerne?

Jeg vil ikke gå for meget i detaljer her - jeg fordobler bare hovedsageligt det, der er utroligt forklaret i de officielle dokumenter.

I det specifikke tilfælde af taggr er der mange langvarige CPU-, GPU- og IO-intensive operationer. Når du udfører disse operationer i Electrons hoved- eller renderertråd, tæller FPS-faldet fra 60, hvilket gør, at brugergrænsefladen føles træg.

Electron tilbyder flere alternativer til at downloade disse operationer fra hoved- og renderertråde , såsom WebWorkers, Node Worker Threads eller BrowserWindow-forekomster. Hver har sine fordele og forbehold, og den brugssag, du står over for, bestemmer hvilken der passer bedst.

Uanset hvilket alternativ du vælger for at aflaste operationerne fra hoved- og renderertråde (når det er nødvendigt), overvej hvordan kommunikationsgrænsefladen bliver . Det tog mig et stykke tid at komme med en grænseflade, jeg var tilfreds med, da det har stor indflydelse på, hvordan din applikation er struktureret og fungerer. Jeg fandt det nyttigt at eksperimentere med forskellige tilgange før jeg valgte en.

For eksempel, hvis du mener, at WebWorkers interface til meddelelsesovergang muligvis ikke er den nemmeste at fejle, så prøv comlink.

4. Test ❌, test ❌ og test ✔️

Gamle nyheder, ikke? Jeg ville tilføje dette som det sidste punkt på grund af et par anekdotiske 'problemer', som jeg for nylig stod overfor. Stærkt knyttet til det første og andet punkt, ved at opbygge dit brugerdefinerede startprojekt og lave fejl tidligt sparer du dyrebar fejlretningstid længere i udviklingen.

Hvis du fulgte mine anbefalinger til opdeling af appens brugergrænseflade og Backend i moduler med en ren grænseflade mellem de to, skal det være let at oprette automatiserede enheds- og integrationstests. Efterhånden som applikationen modnes, vil du muligvis også tilføje support til e2e-test.

GPS-lokaliseringsudtrækning? ️

For to dage siden, mens jeg implementerede GPS-lokaliseringsudvindingsfunktionen til taggr , besluttede jeg at prøve det i produktionsmiljøet , når enhedstestene var grønne og funktionen fungerede under udvikling (med Webpack).

Mens funktionen fungerede godt i udviklingen, mislykkedes den hårdt i produktionen. EXIF-oplysningerne fra billederne blev læst som binære og behandlet af et tredjepartsbibliotek. Mens de binære oplysninger blev indlæst korrekt i begge miljøer (kontrolleret med diff), mislykkedes tredjepartsbiblioteket, når man analyserede sådanne data i produktionsbygningen. Undskyld mig, ??

Løsning : Jeg fandt ud af, at kodningsindstillingerne i udviklings- og produktionsmiljøer indstillet af Webpack ikke var de samme. Dette medførte, at binære data blev analyseret som UTF-8 under udvikling, men ikke i produktion. Problemet blev løst ved at indstille de korrekte kodningsoverskrifter i HTML-filerne indlæst af Electron.

Funky billeder?

Når du manipulerer og arbejder med billeder, tror du måske, at hvis en JPEG 'bare fungerer' på din computer, er den en gyldig JPEG. Forkert .

Mens du arbejdede med Node-billedbehandlingsbiblioteket skarpt , gik størrelsen på nogle JPEG-billeder ned på appen. Efter at have kigget nøje, var årsagen forkerte JPEG-billeder genereret af Samsung firmware. ? ‍♂️

Løsning : opsætning af forbedrede fejlgrænser i appen (f.eks. Prøvefangstblokke), tilpasning af JPEG-parsemodulet og mistanke om alt. ? ️

Resumé

Node- og JavaScripts-økosystemerne blomstrer med mange kraftfulde værktøjer, der oprettes og deles hver dag.

Mængden af ​​muligheder gør det svært at vælge en klar sti til at begynde at bygge din nye fantastiske Electron-app. Uanset dine valgte rammer vil jeg anbefale at fokusere på følgende:

  1. Start lille og tilføj kompleksitet trinvist.
  2. Vær opmærksom på at strukturere din app , holde backend og UI vedrører modulariseret.
  3. Design med trådmodellen i tankerne , selv når du bygger små apps.
  4. Test og test igen for at fange de fleste af fejlene tidligt og spare hovedpine.

Tak for at holde fast indtil slutningen! ?

taggr er en desktop-applikation på tværs af platforme, der gør det muligt for brugere at genopdage deres digitale minder, mens de bevarer deres privatliv . Open-alpha kommer snart til Linux, Windows og Mac OS. Så hold øje med Twitter og Instagram, hvor jeg sender udviklingsopdateringer, kommende funktioner og nyheder.