Olyan dolgokat, amiket szeretnék tudni, mielőtt az Electron.js-szel dolgoznék

Ebben a cikkben megosztom, hogyan lehet elkerülni azokat a hibákat, amelyeket elkövettem az Electron.js megismerésekor? ‍♂️. Remélem, segít!

Megjegyzés : Ez nem egy kódolási oktatóanyag, hanem inkább egy beszélgetés a személyes elvihetőségeimről.

Pár hónapja úgy döntöttem, hogy inkább a melléktermékem, a taggr . Arra inspiráltam, hogy elkészítsem, mert hány fénykép van a számítógépemen.

Azok számára, akik biztonsági másolatot tartanak a képeikről, ezek a gyűjtemények gyakran olyan nagyok és összetettek, hogy teljes munkaidős munkává válnak. A mappák és az almappák keveréke tartalmazhat azonnali üzenetküldő képmentéseket, nagy felbontású képeket a Balira tett utadról, a nagybátyád esküvőjéről vagy a tavalyi legénybúcsúról.

Az ilyen gyűjtemények mindig rendben tartása unalmas (hidd el, évek óta próbálkozom). Ez is nehézhogy felfedezze azokat a felvételeket, amelyeket a legjobban szeret, a mappák mélyén elrejtve.

Tehát taggregy asztali alkalmazás, amely megoldja ezt a problémát. Ez lehetővé teszi a felhasználók számára, hogy újból felfedezzék emlékeiket, miközben megőrzik magánéletüket .

Építek taggr mint egy cross-platform asztali alkalmazás. Itt megosztok néhány dolgot, amit a cross-platform alkalmazás fejlesztéséről tanultam az Electron.js-szel, és amelyeket bárcsak a kezdetektől fogva ismernék. Kezdjük el!

Háttér

Mielőtt bemutatnám az elvihető anyagokat az Electronnal folytatott utazásomról, szeretnék még egy kis hátteret adni magamról és a taggr követelményeiről .

Minden fejlesztő más háttérből származik, és az általuk fejlesztett alkalmazások követelményei is.

A projektre tett döntéseim kontextusba helyezése segíthet a jövőbeli fejlesztőknek kiválasztani a megfelelő eszközöket igényeik és szakértelmük alapján (ahelyett, hogy odakinn élnek - GitHub?, Rád nézek).

Mint korábban említettük, a kezdetektől fogva a taggramot több platformra kiterjedő alkalmazásként képzeltem el . Az alkalmazás az összes szükséges előfeldolgozási és gépi tanulási számítást elvégzi a kliens oldalon, a magánéletre összpontosítva.

Egyszemélyes show-ként azt szerettem volna tudni, hogy egyszer megírhatom az alkalmazásomat, és különféle rendszerekbe szállíthatom anélkül, hogy elveszíteném a józan eszemet.

A magam oldaláról egy elülső mérnök vagyok, szerelmes az internetbe és a JavaScriptbe. Korábban dolgoztam a Java-val és a C # -val, de élvezem a web rugalmasságát és élénk ökoszisztémáját.

Korábban tapasztaltam azt a fájdalmat, hogy korábban olyan eszközöket használtam, mint az Eclipse RCP kliensoldali alkalmazások készítéséhez, és tudtam, hogy nem akarok többet együtt dolgozni ezzel a technológiával.

Röviden: a taggrammal kapcsolatos követelményeim a következőkhöz hasonlítottak:

  • Platformok közötti támogatást kell nyújtania , ideális esetben a keretrendszer szintjén. ?
  • Lehetővé teszi számomra, hogy egyszer megírjam a kódot , és ha szükséges, minden platformra csípjek. ? ️
  • Lehetővé kell tennie a gépi tanulási képességekhez való hozzáférést, a fogadó környezettől függetlenül, külön futásidejű telepítés nélkül. Beállításának fájdalommentesnek kell lennie. ?
  • Ha megvalósítható, webes technológiákat kell használnia . Nagyon jó lenne kihasználni a meglévő tudásomat. ?

Amint láthatja, a követelmények nem így hangzanak: a React with Redux, az observable és a WebSockets alkalmazást kell használnom . Ezek alacsonyabb szintű végrehajtási részletek, és ezekről akkor kell dönteni, amikor és amikor szükség van rá.

Válassza ki a megfelelő eszközt a munkához, ahelyett, hogy az elejétől kezdve válogatna egy halmot, figyelmen kívül hagyva a problémákat.

Dühös guglizás után úgy döntöttem, hogy kipróbálom az Electron-t. Korábban még nem használtam ezt a keretrendszert, de tudtam, hogy sok vállalat sikeresen használja olyan termékekben, mint az Atom, a VS Code, a Discord, a Signal, a Slack és még sok más.

Nyílt forráskódú, és a JS és a Node ökoszisztémákkal együttesen elérhető kompatibilitással (az Electron felépítése Chromium és Node használatával történik) az Electron.js vonzó eszköz volt a szóban forgó munkához.

Nem részletezem túl részletesen a verem többi részét, mivel szükség esetén többször is megváltoztattam az alaprészeket (perzisztencia és nézetrétegeket), és ez nem tartozik a cikk hatálya alá.

Szeretném azonban megemlíteni a Tensorflow.js fájlt, amely lehetővé teszi az edzés futtatását és az ML modellek telepítését közvetlenül a böngészőben (WebGL-lel) és a Node-ban (C összerendeléssel), anélkül, hogy az ML-hez meghatározott futási időket telepítenénk a gazdagépre.

Tehát vissza az Electronhoz - azt gondolva, hogy tökéletes, elkezdődött a móka. ??

Elég beszélni a háttérről. Merüljünk el az elvihetőkben.

1. Kicsiben (és lassan) kezdeni?

Ez nem új koncepció, de érdemes rendszeresen felvetni. Csak azért, mert rengeteg fantasztikus kezdő projekt áll rendelkezésre az Electron-nal, ez nem jelenti azt, hogy azonnal ki kellene választania egyet.

Várjon. Mit?

A lassú sima és a sima gyors. - Haditengerészet mondása

A kényelemmel együtt jár a bonyolultság

Míg ezek a kezdők sok hasznos integrációt tartalmaznak (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), megvannak a maguk problémái is.

Electron újoncként úgy döntöttem, hogy egy sovány sablont választok, amely tartalmazza az „Electron alkalmazások létrehozásának, közzétételének és telepítésének” alapjait a különféle harangok és sípok nélkül. Kezdetben még Webpack sem.

Azt javaslom, hogy kezdjünk valami hasonlóhoz, mint az elektron-hamisítás, hogy gyorsan fel tudjunk állni, és lehetállítsa be a függőségi grafikonját és szerkezetét a tetején, hogy megtanulja az Electron köteleit.

Amikor megjelennek a problémák (és meg is fognak történni), akkor jobban jársz, ha elkészíted az egyéni indítóprojektet, nem pedig +30 npm parancsfájlokkal és +180 függőséggel választasz egyet.

Mindazonáltal, ha jól érzi magát az Electron alapjaival, nyugodtan fokozza a játékot a Webpack / React / Redux / TheNextHotFramework segítségével. Fokozatosan és szükség esetén csináltam . Ne adjon hozzá valós idejű adatbázist a todo alkalmazásához, csak azért, mert valahol olvasott róla egy jó cikket.

2. Gondosan strukturálja az alkalmazását? ‍♂️

Ennek egy kicsit több időbe telt, mire örülök, hogy bevallom. ?

Az elején csábító lehet az UI és a Backend kód összekeverése (fájlhozzáférés, kiterjesztett CPU-műveletek), de a dolgok meglehetősen gyorsan bonyolódnak. Amint az alkalmazásom jellemzői, mérete és összetettsége egyre nőtt, az összekuszált UI + Backend kódbázis fenntartása bonyolultabbá és hibára hajlamosabbá vált. A kapcsolás megnehezítette az egyes részek izolált tesztelését.

Olyan asztali alkalmazás készítésekor, amely nem csak beágyazott weboldalt végez (DB-hozzáférés, fájlhozzáférés, intenzív CPU-feladatok ...), akkor azt javaslom, hogy az alkalmazást modulokba vágja és csökkentse a csatolást. Az egység tesztelése szellővé válik, és a modulok között egyértelmű út vezet az integrációs tesztelés felé. A taggr esetében lazán követtem az itt javasolt struktúrát.

Ráadásul van teljesítmény . Az ezzel kapcsolatos követelmények és a felhasználói elvárások nagyban változhatnak az épülő alkalmazástól függően. De a fő vagy a render szálak blokkolása drága hívásokkal soha nem jó ötlet.

3. Tervezzen a menetes modellt szem előtt tartva?

Nem részletezem itt túlságosan a részleteket - csak főleg megduplázom azt, amit félelmetesen elmagyaráznak a hivatalos dokumentumok.

A taggr konkrét esetben sok régóta futó CPU, GPU és IO intenzív művelet van. Amikor ezeket a műveleteket az Electron fő vagy renderelő szálában hajtja végre, az FPS számlálás 60-ról süllyed, így a felhasználói felület lassúnak tűnik.

Az Electron számos alternatívát kínál ezeknek a műveleteknek a fő és a renderelő szálakból való eltávolítására , például a WebWorkers, a Node Worker Threads vagy a BrowserWindow példányokról. Mindegyiknek megvannak a maga előnyei és figyelmeztetései, és az Ön által tapasztalt felhasználási eset meghatározza, hogy melyik a legmegfelelőbb.

Függetlenül attól, hogy melyik alternatívát választja a műveletek kitöltéséhez a fő és a renderelő szálakból (ha szükséges), fontolja meg , hogy milyen lesz a kommunikációs felület . Eltartott egy ideig, mire egy olyan kezelőfelülettel készültem, amellyel elégedett voltam, mivel ez nagyban befolyásolja az alkalmazás felépítését és működését. Hasznosnak találtam a különböző megközelítések kísérletezését, mielőtt kiválasztottam egyet.

Például, ha úgy gondolja, hogy a WebWorkers üzenetátviteli felületét nem lehet a legkönnyebb hibakeresni, próbálja meg a comlinket.

4. Tesztelje, tesztelje és tesztelje ✔️

Régi hír, igaz? Ezt akartam hozzáadni utolsó pontként, néhány anekdotikus „probléma” miatt, amelyekkel nemrégiben szembesültem. Szorosan kapcsolódva az első és a második ponthoz, az egyéni indító projekt megalkotása és a hibák korai hibázása értékes hibakeresési időt takarít meg a fejlesztésben.

Ha betartotta az alkalmazás kezelőfelületének és a háttérprogramnak a kettő közötti tiszta felülettel rendelkező modulokra bontására vonatkozó ajánlásaimat, akkor az automatizált egység- és integrációs tesztek létrehozásának egyszerűnek kell lennie. Amint az alkalmazás lejár, érdemes hozzáadnia az e2e tesztelés támogatását is.

GPS helymeghatározás? ️

Két nappal ezelőtt, amikor végrehajtottam a GPS helymeghatározási funkcióját a taggr számára , miután az egység tesztjei zöldek voltak, és a funkció működött a fejlesztés során (a Webpack segítségével), úgy döntöttem, hogy kipróbálom a termelési környezetben.

Míg a szolgáltatás jól működött a fejlesztésben, a gyártásban csúfosan megbukott. A képekből származó EXIF-információkat binárisként olvasták és egy harmadik fél által készített könyvtár dolgozta fel. Míg a bináris információkat mindkét környezetben helyesen töltötték be (a diff-rel ellenőrizték), a harmadik fél könyvtárának kudarcot vallott az ilyen adatok elemzése a termelési buildben. Elnézést, ??

Megoldás : Megtudtam, hogy a Webpack által beállított fejlesztési és gyártási környezetek kódolási beállításai nem ugyanazok. Ez azt eredményezte, hogy a bináris adatokat UTF-8-ként elemezték a fejlesztésben, de a gyártásban nem. A problémát úgy oldották meg, hogy beállították a megfelelő kódoló fejléceket az Electron által betöltött HTML fájlokba.

Funky képek?

Képekkel való manipulálás és munka közben azt gondolhatja, hogy ha egy JPEG „csak működik” a számítógépén, akkor az érvényes JPEG. Rossz .

Miközben a Node képfeldolgozó könyvtárával élesen dolgozott, néhány JPEG kép átméretezése összeomlotta az alkalmazást. Alapos megnézés után az ok a Samsung firmware által generált hibás JPEG-képek voltak. ? ‍♂️

Megoldás : javított hibahatárok beállítása az alkalmazásban (pl. Try-catch blokkok), a JPEG elemző modul módosítása és mindenre gyanakvás. ? ️

Összegzés

A Node és a JavaScripts ökoszisztémák virágoznak, sok hatékony eszközt hoznak létre és osztanak meg minden nap.

Az opciók száma megnehezíti az egyértelmű útvonalat az új fantasztikus Electron alkalmazás építésének megkezdéséhez. A választott kerettől függetlenül azt javaslom, hogy a következőkre összpontosítson:

  1. Kezdje kicsiben, és fokozatosan adja hozzá a bonyolultságot.
  2. Gondosan strukturálja az alkalmazását , megtartva a háttérprogramot és a moduláris felhasználói felületet.
  3. Tervezzen a menetes modellt szem előtt tartva , még akkor is, ha kis alkalmazásokat épít.
  4. Teszteljen és teszteljen újra , hogy a hibák nagy részét már korán elkapja és megspórolja a fejfájást.

Köszönöm, hogy kitartottál a végéig! ?

A taggr egy platformon átívelő asztali alkalmazás, amely lehetővé teszi a felhasználók számára, hogy újból felfedezzék digitális emlékeiket a magánéletük megőrzése mellett . Az Open-alfa hamarosan Linuxra, Windowsra és Mac OS-re érkezik. Tehát figyelemmel kíséri a Twitteret és az Instagramot, ahol fejlesztési frissítéseket, közelgő szolgáltatásokat és híreket teszek közzé.