În acest articol, vă voi împărtăși cum puteți evita unele dintre greșelile pe care le-am făcut când am aflat despre Electron.js? ‍♂️. Sper că ajută!

Notă: Acesta nu va fi un tutorial de codare, ci mai degrabă o discuție despre acțiunile mele personale.

Cu câteva luni în urmă, am decis să mă concentrez mai mult pe construirea produsului meu secundar, taggr. Am fost inspirat să-l construiesc din cauza câte fotografii am pe computer.

Pentru aceia dintre noi care păstrează o copie de rezervă a imaginilor lor, acele colecții devin adesea atât de mari și complexe încât devin o slujbă cu normă întreagă de gestionat. Un amestec de foldere și sub-foldere poate conține copii de rezervă pentru imagini de mesagerie instantanee, imagini cu rezoluție înaltă din călătoria dvs. la Bali, nunta unchiului dvs. sau petrecerea burlacilor de anul trecut.

A păstra întotdeauna astfel de colecții ordonate este plictisitor (crede-mă, am încercat de ani de zile). De asemenea, este greu pentru a descoperi fotografiile pe care le iubești cel mai mult, ascunse adânc în dosare.

Asa de taggr este o aplicație desktop care rezolvă această problemă. Permite utilizatorilor redescoperi amintirile lor în timp ce le păstrează intimitate.

Eu construiesc taggr ca aplicație desktop pe mai multe platforme. Aici voi împărtăși câteva dintre lucrurile pe care le-am învățat despre dezvoltarea de aplicații pe mai multe platforme Electron.js că mi-aș dori să știu de la început. Să începem!

fundal

Înainte de a-mi prezenta mâncărurile în această călătorie în desfășurare cu Electron, aș dori să vă ofer mai multe informații despre mine și despre cerințele taggr.

Fiecare dezvoltator provine dintr-un mediu diferit, la fel și cerințele aplicațiilor pe care le dezvoltă.

Contextualizarea alegerilor pe care le-am făcut pentru acest proiect poate ajuta viitorii dezvoltatori să aleagă instrumentele potrivite pe baza nevoilor și expertizei lor (mai degrabă decât ceea ce este hyped acolo – GitHub?, Mă uit la tine).

Lucruri pe care imi doresc sa le stiu inainte de
Dezvoltarea JavaScript pe scurt. Sursă: gifă.

Așa cum am menționat mai devreme, de la început am imaginat taggr ca aplicație multi-platformă. Aplicația va efectua toate calculele necesare de pre-procesare și învățare automată din partea clientului, datorită accentului pe confidențialitate.

Ca o emisiune de o persoană, am vrut să pot scrie aplicația mea o singură dată și să o trimit pe diferite sisteme fără să-mi pierd mintea.

Din partea mea, sunt un inginer front end îndrăgostit de web și JavaScript. Am lucrat anterior cu Java și C #, dar mă bucur de flexibilitatea oferită de web și de ecosistemul său vibrant.

După ce am experimentat din prima mână durerea utilizării unor instrumente precum Eclipse RCP pentru a construi aplicații din partea clientului înainte, știam că nu vreau să lucrez din nou cu tehnologia respectivă.

Pe scurt, cerințele stivei mele pentru taggr s-au redus la ceva de genul:

  • Ar trebui să ofere suport multiplataforma, ideal la nivel cadru. ?
  • Ar trebui să-mi permită asta scrie codul o dată, și modificări pentru fiecare platformă, dacă este necesar. ? ️
  • Ar trebui să permită acces la capacități de învățare automată, indiferent de mediul gazdă, fără a fi instalate anumite runtime. Ar trebui să fie nedureros să se stabilească. ?
  • Dacă este fezabil, ar trebui folosiți tehnologii web. Ar fi minunat să îmi folosesc cunoștințele existente. ?

După cum puteți vedea, cerințele nu se citesc ca: Ar trebui să folosesc React cu Redux, observabile și WebSockets. Acestea sunt detalii de implementare la nivel inferior și trebuie luate în considerare când și dacă apare nevoia.

Alegeți instrumentul potrivit pentru sarcină, mai degrabă decât alegeți un teanc de la început, fără a lua în considerare problemele la îndemână.

Așadar, după googuri furioase, am decis să încerc Electron. Nu mai folosisem acel cadru înainte, dar știam că multe companii îl foloseau cu succes în produse precum Atom, Cod VS, Discordie, Semnal, Slăbiciune și altele.

Open-source și cu compatibilitate prealabilă cu ambele ecosisteme JS și Node (Electron este construit folosind Chromium și Node), Electron.js a fost un instrument atractiv pentru munca la îndemână.

Nu voi intra prea mult în detaliu în ceea ce privește restul stivei, deoarece am schimbat în mod repetat părțile de bază (straturi de persistență și de vizualizare) atunci când este necesar, și nu intră în sfera acestui articol.

Cu toate acestea, aș dori să menționez Tensorflow.js, care permite rularea antrenamentului și implementarea modelelor ML direct în browser (cu WebGL) și Node (cu legături C), fără a instala runtime specifice pentru ML în gazdă.

Așadar, înapoi la Electron – crezând că este perfect, a început distracția. ??

Destul de vorbit despre fundal. Să ne scufundăm în mâncăruri de luat masa.

1. Începeți mic (și lent)?

Acesta nu este un concept nou, dar merită să fie prezentat periodic. Doar pentru că există o grămadă de minunate proiecte de start cu Electron disponibil, nu înseamnă că ar trebui să alegeți unul imediat.

Aștepta. Ce?

Lent este neted, iar netedul este rapid. – Marina zicând

Cu comoditatea vine complexitatea

În timp ce aceste startere includ multe integrări utile (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), ele au și problemele lor.

Ca un începător în Electron, am decis să aleg un șablon slab care să conțină elementele de bază pentru „crearea, publicarea și instalarea aplicațiilor Electron” fără clopotele și fluierele suplimentare. Nici măcar Webpack la început.

Vă recomand să începeți cu ceva similar cu electron-forge să te ridici și să fugi repede, poți configurați graficul de dependență și structura deasupra pentru a învăța corzile Electronului.

Când apar problemele (și vor apărea), veți fi mai bine dacă vă construiți proiectul de pornire personalizat, mai degrabă decât să alegeți unu cu scripturi +30 npm și dependențe +180 pentru început.

Acestea fiind spuse, odată ce vă simțiți confortabil cu baza Electron, nu ezitați să intensificați jocul cu Webpack / React / Redux / TheNextHotFramework. am facut-o incremental și când este nevoie. Nu adăugați o bază de date în timp real la aplicația dvs. todo pentru că ați citit undeva un articol interesant despre aceasta.

2. Vă structurați cu atenție aplicația? ‍♂️

Acesta a durat puțin mai mult pentru a avea dreptate decât sunt fericit să recunosc. ?

La început, poate fi tentant să amesteci UI și codul Backend (acces la fișiere, operațiuni extinse ale procesorului), dar lucrurile devin complexe destul de repede. Pe măsură ce aplicația mea a crescut în caracteristici, dimensiuni și complexitate, menținerea unei baze de cod UI + Backend încurcate a devenit mai complicată și predispusă la erori. De asemenea, cuplajul a făcut dificilă testarea fiecărei părți izolat.

Când construiți o aplicație desktop care face mai mult decât o pagină web încorporată (acces DB, acces la fișiere, sarcini intensive ale procesorului …), vă recomand felierea aplicației în module și reducerea cuplajului. Testarea unității devine o briză și există o cale clară spre testarea integrării între module. Pentru taggr, Am urmat în mod liber structura propusă aici.

Pe deasupra, există performanţă. Cerințele și așteptările utilizatorilor în această privință pot varia foarte mult în funcție de aplicația pe care o creați. Dar blocarea firelor principale sau de redare cu apeluri costisitoare nu este niciodată o idee bună.

3. Proiectați având în vedere modelul de filetare?

Nu voi intra prea mult în detaliu aici – mă duc în principal la ceea ce este extrem de explicat în documente oficiale.

În cazul specific al taggr, există multe operațiuni de lungă durată de procesare, GPU și IO. Când executați acele operații în firul principal sau de redare al Electron, numărul FPS scade de la 60, făcând UI să se simtă lent.

Electron oferă mai multe alternative la descărcați acele operații din firele principale și de redare, ca WebWorkers, Firele de lucru ale nodului, sau BrowserWindow instanțe. Fiecare are avantajele și avertismentele sale, iar cazul de utilizare cu care vă confruntați va determina care dintre acestea se potrivește cel mai bine.

Indiferent de alternativa pe care o alegeți pentru descărcarea operațiunilor din firele principale și de redare (atunci când este necesar), ia în considerare modul în care va fi interfața de comunicare. Mi-a luat ceva timp să vin cu o interfață de care eram mulțumit, deoarece are un impact puternic asupra modului în care aplicația dvs. este structurată și funcționează. Mi s-a părut util să experimentez diferite abordări înainte de a alege una.

De exemplu, dacă credeți că interfața de transmitere a mesajelor WebWorkers poate să nu fie cea mai ușor de depanat, dați comlink o incercare.

1611887109 735 Lucruri pe care imi doresc sa le stiu inainte de
Sponge Bob știe cel mai bine. Sursă: gifă

4. Testați ❌, testați ❌ și testați ✔️

Vești vechi, nu? Am vrut să adaug acest lucru ca ultim punct, din cauza câtorva „probleme” anecdotice cu care m-am confruntat recent. Strâns legat de primul și al doilea punct, construirea proiectului dvs. personalizat de pornire și greșeala devreme vă vor economisi timp prețios de depanare în dezvoltare.

Dacă ați urmat recomandările mele pentru împărțirea interfeței UI și Backend a aplicației în module cu o interfață curată între cele două, configurarea testelor automate de unitate și integrare ar trebui să fie ușoară. Pe măsură ce aplicația se maturizează, poate doriți să adăugați suport pentru testarea e2e de asemenea.

Extragerea locației GPS? ️

Acum două zile, în timp ce implementam funcția de extragere a locației GPS pentru taggr, odată ce testele unitare au fost verzi și funcționalitatea a funcționat în dezvoltare (cu Webpack), am decis să o încerc în mediul de producție.

În timp ce caracteristica a funcționat bine în dezvoltare, a eșuat lamentabil în producție. Informațiile EXIF ​​din imagini au fost citite ca binare și procesate de o bibliotecă terță parte. În timp ce informațiile binare au fost încărcate corect în ambele medii (verificat cu dif), biblioteca terță parte a eșuat la analizarea acestor date în versiunea de producție. Scuzati-ma, ??

Soluţie: Am aflat că setările de codificare din mediile de dezvoltare și producție stabilite de Webpack nu erau aceleași. Acest lucru a făcut ca datele binare să fie analizate ca UTF-8 în dezvoltare, dar nu în producție. Problema a fost rezolvată prin configurarea antetelor de codificare corespunzătoare în fișierele HTML încărcate de Electron.

Poze funky?

Când manipulați și lucrați cu imagini, vă puteți gândi că, dacă un JPEG „doar funcționează” pe computerul dvs., acesta este un JPEG valid. Gresit.

În timp ce lucrați cu biblioteca de prelucrare a imaginilor Node ascuțit, redimensionarea unor imagini JPEG a blocat aplicația. După o analiză atentă, cauza a fost imagini JPEG incorecte generate de Firmware Samsung. ? ‍♂️

Soluţie: setarea unor limite de eroare îmbunătățite în aplicație (de ex. blocuri try-catch), modificarea modulului de analiză JPEG și suspectarea a tot. ? ️

rezumat

Ecosistemele Node și JavaScript sunt înflorite, multe instrumente puternice fiind create și partajate în fiecare zi.

Cantitatea de opțiuni face dificilă alegerea unei căi clare pentru a începe să construiți noua aplicație minunată Electron. Indiferent de cadrele pe care le alegeți, aș recomanda să vă concentrați pe următoarele:

  1. Începeți mic și adăugați complexitate în mod incremental.
  2. Structurați-vă cu atenție aplicația, păstrarea backend-ului și preocupările UI modularizate.
  3. Proiectați având în vedere modelul de filetare, chiar și atunci când creați aplicații mici.
  4. Testează și testează din nou, pentru a prinde cele mai multe erori din timp și pentru a salva durerile de cap.

Vă mulțumim că ați rămas până la capăt! ?

taggr este o aplicație desktop pe mai multe platforme care permite utilizatorilor să redescoperi lor digital amintiri în timp ce le păstrează intimitate. Open-alpha va apărea în curând pe Linux, Windows și Mac OS. Așadar, fii cu ochii pe Stare de nervozitate și Instagram, unde postez actualizări de dezvoltare, funcții viitoare și știri.