Asjad, mida ma teadsin, enne kui töötasin saidiga Electron.js

Selles artiklis jagan, kuidas saate vältida mõningaid vigu, mille tegin Electron.js-i õppimisel? ‍♂️. Loodan, et see aitab!

Märkus . See pole tavaliselt kodeerimisõpetus, vaid pigem arutelu minu isiklike väljavõtete üle.

Paar kuud tagasi otsustasin rohkem keskenduda oma kõrvaltoote, taggr , ehitamisele . Mind inspireeris selle ehitamine sellepärast, kui palju fotosid mul arvutis on.

Neile meist, kes hoiavad oma piltidest varukoopia, muutuvad need kollektsioonid sageli nii suureks ja keerukaks, et neist saab hallata täiskohaga töö. Kaustade ja alamkaustade segu võib sisaldada kiirsõnumipiltide varukoopiaid, kõrglahutusega pilte teie Bali-reisist, onu pulmadest või eelmise aasta poissmeesteõhtust.

Selliste kollektsioonide alati korras hoidmine on tüütu (uskuge mind, olen aastaid proovinud). See on ka raskeavastada kaustadesse peidetud kaadrid, mis teile kõige rohkem meeldivad.

Nii et taggron töölauarakendus, mis selle probleemi lahendab. See võimaldab kasutajatel oma mälestused taasavastada , säilitades samas nende privaatsuse .

Olen hoone taggr kui platvormiülene töölaua rakendus. Jagan siin Electron.js-iga mõningaid asju, mida olen platvormidevahelise rakenduse arendamise kohta õppinud ja mida ma sooviksin teada juba algusest peale. Alustame!

Taust

Enne Electroniga sellel käimasoleval teekonnal oma väljavõtete esitamist tahaksin anda natuke rohkem tausta enda ja taggr-i nõuete kohta .

Iga arendaja on pärit erinevast taustast ja nii ka nende arendatavate rakenduste nõuded.

Selle projekti jaoks tehtud valikute kontekstuaalseks muutmine võib aidata tulevastel arendajatel valida oma vajaduste ja asjatundlikkuse põhjal õiged tööriistad (mitte selle, mis seal välja hüpatakse - GitHub?, Ma vaatan teid).

Nagu varem mainitud, nägin algusest peale taggrit platvormiülese rakendusena. Rakendus täidaks privaatsusele keskendumise tõttu kõik nõutavad eeltöötluse ja masinõppe arvutused kliendipoolselt.

Ühe inimese saatena tahtsin, et saaksin oma rakenduse üks kord kirjutada ja selle mõistusest ilma minemata erinevatesse süsteemidesse saata.

Oma küljest olen ma veebi ja JavaScripti armunud esiotsa insener. Varem töötasin Java ja C # -ga, kuid mulle meeldib veebi paindlikkus ja selle elav ökosüsteem.

Olles varem kogenud sellist tööriista nagu Eclipse RCP kasutamist kliendipoolsete rakenduste loomisel, teadsin, et ei taha selle tehnoloogiaga uuesti töötada.

Lühidalt, minu virnanõuded taggrile kerkisid umbes järgmiselt:

  • See peaks pakkuma platvormidevahelist tuge, ideaaljuhul raamistiku tasandil. ?
  • See peaks lubama mul koodi üks kord kirjutada ja vajadusel iga platvormi jaoks näpistada. ? ️
  • See peaks võimaldama juurdepääsu masinõppevõimalustele , olenemata hostikeskkonnast, ilma konkreetsete käituste installimiseta. Selle seadistamine peaks olema valutu. ?
  • Kui see on teostatav, peaks see kasutama veebitehnoloogiaid . Tore oleks kasutada oma olemasolevaid teadmisi. ?

Nagu näete, ei loe nõuded järgmiselt: Ma peaksin kasutama React with Redux, observable ja WebSockets . Need on madalama taseme rakendamise üksikasjad ja nende üle tuleks otsustada, millal ja kui selleks vajadus tekib.

Valige töö jaoks sobiv tööriist, selle asemel, et algusest peale korstnat valida, arvestamata käsitletavaid probleeme.

Niisiis, pärast raevukat guugeldamist otsustasin proovida Electronit. Ma ei olnud seda raamistikku varem kasutanud, kuid teadsin, et paljud ettevõtted kasutavad seda edukalt sellistes toodetes nagu Atom, VS Code, Discord, Signal, Slack ja palju muud.

Avatud lähtekoodiga ja paketiga ühilduv nii JS kui ka Node ökosüsteemidega (Electroni loomisel kasutatakse kroomi ja Node'i) oli Electron.js atraktiivne tööriist käimasoleva töö jaoks.

Ma ei hakka ülejäänud korstna osas liiga üksikasjalikult arutama, kuna muutsin vajaduse korral korduvalt põhiosi (püsivuse ja vaate kihte) ja see jääb selle artikli reguleerimisalast välja.

Tahaksin siiski mainida Tensorflow.js-i, mis võimaldab treeninguid käivitada ja ML-mudeleid juurutada otse brauseris (WebGL-iga) ja Node'is (C-sidemetega), ilma et ML-i hostile konkreetseid käitamisaegu installiks.

Nii et tagasi Electroni juurde - arvates, et see on täiuslik, algas lõbu. ??

Piisavalt rääkida taustast. Sukeldume kaasavõtmistesse.

1. Alustada väikselt (ja aeglaselt)?

See pole uus kontseptsioon, kuid tasub seda perioodiliselt esile tõsta. See, et Electroniga on saadaval palju ägedaid starterprojekte, ei tähenda, et peaksite selle kohe valima.

Oota. Mida?

Aeglane on sile ja sujuv on kiire. - merevägi ütleb

Mugavusega kaasneb keerukus

Kuigi need starterid sisaldavad palju kasulikke integreerimisi (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), on neil ka oma probleemid.

Electroni algajana otsustasin valida lahja malli, mis sisaldas põhitõdesid "Electroni rakenduste loomiseks, avaldamiseks ja installimiseks" ilma täiendavate kellade ja vileteta. Alguses isegi mitte Webpacki.

Soovitan alustada kiirelt tööle asumiseks midagi sarnast, mis sarnaneb elektronvõltsimisega, saateseadke ülal oma sõltuvusgraafik ja struktuur, et õppida Elektroni köied.

Kui probleemid tulevad (ja need ka tulevad), on teil parem, kui koostate oma kohandatud käivitusprojekti, selle asemel, et valida alguseks +30 npm skripti ja +180 sõltuvust.

See tähendab, et kui tunnete end Electroni baasil mugavalt, võite julgelt mängu Webpack / React / Redux / TheNextHotFramework abil suurendada. Tegin seda järk-järgult ja vajadusel. Ärge lisage oma todirakendusse reaalajas andmebaasi lihtsalt sellepärast, et lugesite selle kohta kuskilt lahedat artiklit.

2. Struktureerige oma rakendus teadlikult? ‍♂️

Selle õigeks saamine võttis veidi kauem aega, kui tunnistan hea meelega. ?

Alguses võib olla ahvatlev segada kasutajaliidese ja taustaprogrammi kood (juurdepääs failidele, laiendatud protsessori toimingud), kuid asjad lähevad üsna kiiresti keeruliseks. Kui minu rakendused kasvasid funktsioonide, suuruse ja keerukuse poolest, muutus ühe sassis UI + taustaprogrammi koodibaasi säilitamine keerulisemaks ja veaohtlikumaks. Samuti raskendas ühendamine iga osa eraldi katsetamist.

Töölauarakenduse ehitamisel, mis teeb enamat kui sisseehitatud veebileht (juurdepääs DB-le, juurdepääs failidele, intensiivsed protsessoriülesanded ...), soovitan rakenduse tükeldada mooduliteks ja vähendada sidumist. Ühikute testimisest saab imelihtne ja moodulite vahel on selge tee integreerimise testimise poole. Sest taggr , ma lõdvalt millele kavandatav struktuur siin.

Selle peal on jõudlus . Nõuded ja kasutajate ootused selles küsimuses võivad tohutult erineda, sõltuvalt teie loodavast rakendusest. Kuid peamiste või renderdavate lõimude blokeerimine kallite kõnede abil pole kunagi hea mõte.

3. Kujundamine keermestamise mudelit silmas pidades?

Ma ei hakka siin liiga üksikasjalikult arutama - ma lihtsalt kahekordistan peamiselt seda, mida on ametlikes dokumentides hämmastavalt selgitatud.

Taggravi konkreetsel juhul on palju pikki CPU, GPU ja IO intensiivseid toiminguid. Nende toimingute tegemisel Electroni põhi- või renderdamisniidis langeb FPS-i arv 60-st, mis muudab kasutajaliidese aeglaseks.

Electron pakub mitmeid toiminguid nende toimingute laadimiseks põhi- ja renderdamisniididest , näiteks WebWorkers, Node Worker Threads või BrowserWindow eksemplarid. Igal neist on oma eelised ja hoiatused ning kasutamisjuhtum, millega te silmitsi seisate, määrab, milline neist sobib kõige paremini.

Sõltumata sellest, millise alternatiivi valite operatsioonide põhi- ja renderdamisniidist välja laadimiseks (vajadusel), kaaluge, kuidas suhtlusliides saab olema . Mul kulus mõnda aega, kuni jõudsin välja liidesega, millega olin rahul, kuna see mõjutab tugevalt seda, kuidas teie rakendus on üles ehitatud ja toimib. Leidsin, et on kasulik enne ühe valimist katsetada erinevaid lähenemisviise.

Näiteks kui arvate, et WebWorkersi sõnumi edastamise liidest pole kõige lihtsam siluda, proovige comlinki.

4. Testige ❌, testige ❌ ja testige ✔️

Vanad uudised, eks? Tahtsin selle lisada viimase punktina seoses paari anekdootliku probleemiga, millega hiljuti kokku puutusin. Esimese ja teise punktiga tihedalt seotud, säästab teie kohandatud starteriprojekti loomine ja varakult vigade tegemine väärtuslikku silumisaega arenduses.

Kui järgisite minu soovitusi rakenduse kasutajaliidese ja taustaprogrammi jagamiseks nende kahe puhta liidesega mooduliteks, peaks automaatse üksuse ja integreerimise testide seadistamine olema lihtne. Kui rakendus küpseb, võiksite lisada ka e2e testimise tuge.

GPS-i asukoha tuvastamine? ️

Kaks päeva tagasi, rakendades GPS-i asukoha tuvastamise funktsiooni taggrile , otsustasin , et kui üksuse testid olid rohelised ja funktsioon töötas väljaarendamisel (koos Webpackiga), otsustasin seda proovida tootmiskeskkonnas.

Kuigi funktsioon töötas arendamisel hästi, ebaõnnestus see tootmises tohutult. Piltidelt saadud EXIF-i teavet luges binaarne ja töötles kolmanda osapoole raamatukogu. Kui binaarteave oli mõlemas keskkonnas õigesti laaditud (kontrollitud diff-ga), nurjus kolmanda osapoole teek selliste andmete parsimisel tootmishoones. Vabandage mind, ??

Lahendus : sain teada, et Webpacki määratud arendus- ja tootmiskeskkondade kodeerimisseaded ei olnud samad. See põhjustas binaarandmete parsimise UTF-8 kujul arengus, kuid mitte tootmises. Probleem lahendati, seadistades Electroni laaditud HTML-failidesse õiged kodeerimispäised.

Funky pildid?

Piltidega manipuleerides ja nendega töötades võite mõelda, et kui JPEG teie arvutis lihtsalt töötab, on see kehtiv JPEG. Vale .

Töötades Sõlme pilditöötlus raamatukogu terav , saneerimist mõned JPEG piltide kukkus rakenduse. Pärast hoolikat vaatamist oli põhjuseks Samsungi püsivara loodud valed JPEG-pildid. ? ‍♂️

Lahendus : rakenduses parandatud veapiiride seadistamine (nt proovimisklotsid), näpistage JPEG-i sõelumismoodulit ja kahtlustage kõike. ? ️

Kokkuvõte

Ökosüsteemid Node ja JavaScripts õitsevad, iga päev luuakse ja jagatakse palju võimsaid tööriistu.

Valikute hulga tõttu on uue uue ägeda rakenduse Electron ehitamiseks selge tee valimine keeruline. Sõltumata teie valitud raamistikest soovitaksin keskenduda järgmisele:

  1. Alustage väikesest ja lisage keerukus järk-järgult.
  2. Struktureerige oma rakendus teadlikult , hoides taustaprogrammi ja kasutajaliidese probleemid moduleeritud.
  3. Kujundamine, pidades silmas keermestamise mudelit , isegi väikeste rakenduste ehitamisel.
  4. Proovige ja proovige uuesti , et enamus vigu varakult kätte saada ja peavalud kokku hoida.

Täname, et püsisite lõpuni! ?

taggr on platvormidevaheline töölauarakendus, mis võimaldab kasutajatel oma digitaalsed mälud taasavastada , säilitades samas nende privaatsuse . Open-alfa on varsti saadaval Linuxis, Windowsis ja Mac OS-is. Seega hoidke silma peal Twitteril ja Instagramis, kuhu postitan arenguvärskendusi, tulevasi funktsioone ja uudiseid.