Неща, които искам да знам, преди да работя с Electron.js

В тази статия ще споделя как можете да избегнете някои от грешките, които направих, когато научих за Electron.js? ‍♂️. Надявам се да помогне!

Забележка : Това няма да бъде урок по кодиране, а по-скоро дискусия за моите лични похвати.

Преди няколко месеца реших да се съсредоточа повече върху изграждането на моя страничен продукт, taggr . Вдъхнових се да го изградя заради това колко снимки имам на компютъра си.

За тези от нас, които пазят резервно копие на своите снимки, тези колекции често стават толкова големи и сложни, че стават работа на пълен работен ден за управление. Комбинация от папки и подпапки може да съдържа резервни копия на снимки за незабавни съобщения, снимки с висока разделителна способност от пътуването ви до Бали, сватбата на чичо ви или миналогодишното ергенско парти.

Винаги да поддържам подобни колекции подредени е досадно (повярвайте ми, опитвах се от години). Също така е труднода откриете кадрите, които обичате най-много, скрити дълбоко в папките.

Така че taggrе настолно приложение, което решава този проблем. Позволява на потребителите да преоткриват спомените си, като същевременно запазват поверителността си .

Изграждам taggr като настолно приложение за различни платформи. Тук ще споделя някои от нещата, които научих за разработката на приложения на различни платформи с Electron.js, които бих искал да знам от самото начало. Да започваме!

Заден план

Преди да представя моите заведения на това продължаващо пътуване с Electron, бих искал да дам малко повече информация за себе си и изискванията на taggr .

Всеки разработчик идва от различен произход, както и изискванията на приложенията, които разработват.

Контекстуализирането на изборите, които направих за този проект, може да помогне на бъдещите разработчици да изберат правилните инструменти въз основа на техните нужди и експертиза (а не това, което е свръх - GitHub?, Гледам ви).

Както бе споменато по-рано, от самото начало си представях taggr като приложение за различни платформи. Приложението ще изпълнява всички необходими изчисления за предварителна обработка и машинно обучение от страна на клиента поради фокуса върху поверителността.

Като шоу за един човек исках да мога да напиша приложението си веднъж и да го изпратя до различни системи, без да губя разсъдъка си.

От моя страна съм инженер от фронт енд, влюбен в мрежата и JavaScript. Преди работих с Java и C #, но се радвам на гъвкавостта, която предлага мрежата и нейната жизнена екосистема.

След като изпитах от първа ръка болката от използването на инструменти като Eclipse RCP за изграждане на клиентски приложения преди, знаех, че не искам да работя отново с тази технология.

Накратко, изискванията ми за стека за taggr се свеждат до нещо подобно:

  • Той трябва да осигурява междуплатформена поддръжка, в идеалния случай на ниво рамка. ?
  • Трябва да ми позволи да напиша кода веднъж и да променя всяка платформа, ако е необходимо. ? ️
  • Той трябва да позволява достъп до възможностите за машинно обучение , независимо от средата на хоста, без да се инсталират конкретни времена на изпълнение. Трябва да е безболезнено да се настройва. ?
  • Ако е възможно, той трябва да използва уеб технологии . Би било чудесно да използвам съществуващите си знания. ?

Както можете да видите, изискванията не се четат като: Трябва да използвам React с Redux, наблюдаеми и WebSockets . Това са подробности за изпълнението на по-ниско ниво и те трябва да бъдат решени кога и ако възникне необходимост.

Изберете правилния инструмент за работата, вместо да избирате стек от самото начало, без да обръщате внимание на наличните проблеми.

И така, след бясно гуглене, реших да опитам Electron. Не бях използвал тази рамка преди, но знаех, че много компании я използват успешно в продукти като Atom, VS Code, Discord, Signal, Slack и други.

С отворен код и с нестандартна съвместимост както с JS, така и с Node екосистемите (Electron се изгражда с помощта на Chromium и Node), Electron.js беше привлекателен инструмент за текущата работа.

Няма да навлизам твърде подробно по отношение на останалата част от стека, тъй като многократно смених основни части (персистенция и изгледни слоеве), когато е необходимо, и това изпада извън обхвата на тази статия.

Бих искал обаче да спомена Tensorflow.js, който позволява стартиране на обучение и внедряване на модели на ML директно в браузъра (с WebGL) и Node (със свързвания C), без да се инсталират конкретни изпълнения за ML в хоста.

И така, обратно към Electron - мислейки, че е перфектно, забавлението започна. ??

Стига да говорим за фона. Нека да се потопим в заведенията.

1. Започнете малко (и бавно)?

Това не е нова концепция, но си струва да се повдига периодично. Само защото има много страхотни начални проекти с Electron, това не означава, че трябва да изберете един веднага.

Изчакайте. Какво?

Бавното е гладко, а плавното е бързо. - Морска поговорка

С удобството идва и сложността

Докато тези начинаещи включват много полезни интеграции (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), те също имат своите проблеми.

Като начинаещ на Electron, реших да избера постно шаблон, който включваше основите за „създаване, публикуване и инсталиране на приложения на Electron“ без излишни приказки. Нито Webpack в началото.

Препоръчвам да започнете с нещо подобно на електрон-коване, за да стартирате и да работите бързо, можетенастройте вашата графика на зависимост и структура отгоре, за да научите въжетата на Electron.

Когато проблемите дойдат (и ще се появят), ще ви бъде по-добре, ако създадете свой персонализиран стартов проект, вместо да изберете такъв със +30 npm скриптове и +180 зависимости за начало.

Въпреки това, след като се почувствате комфортно с основата на Electron, не се колебайте да активирате играта с Webpack / React / Redux / TheNextHotFramework. Направих го постепенно и при нужда. Не добавяйте база данни в реално време към приложението си за задачи само защото сте прочели някъде страхотна статия за нея.

2. Внимателно структурирайте приложението си?

Това отне малко повече време, за да се оправи, отколкото съм щастлив да призная. ?

В началото може да е изкушаващо да смесите потребителския интерфейс и Backend кода (достъп до файлове, разширени операции на процесора), но нещата се усложняват доста бързо. Тъй като приложението ми нарастваше по функции, размери и сложност, поддържането на една заплетена кодова база на UI + Backend стана по-сложно и склонно към грешки. Също така, съединителят затруднява тестването на всяка част изолирано.

Когато създавате настолно приложение, което прави повече от вградена уеб страница (достъп до DB, достъп до файлове, интензивни задачи на процесора ...), препоръчвам нарязването на приложението на модули и намаляване на свързването. Единичното тестване става бриз и има ясен път към интеграционното тестване между модулите. За taggr , аз следвах свободно структурата, предложена тук.

На всичкото отгоре има и производителност . Изискванията и очакванията на потребителите по този въпрос могат да се различават силно в зависимост от приложението, което създавате. Но блокирането на основните или рендиращите нишки със скъпи обаждания никога не е добра идея.

3. Дизайн с мисъл за модела с резби?

Тук няма да навлизам прекалено много в подробности - просто удвоявам това, което е страхотно обяснено в официалните документи.

В конкретния случай на taggr има много дълготрайни CPU, GPU и IO интензивни операции. Когато изпълнявате тези операции в основната или визуализираща нишка на Electron, броят на FPS намалява от 60, което кара потребителския интерфейс да се чувства бавен.

Electron предлага няколко алтернативи за разтоварване на тези операции от основната и визуализиращата нишки , като например WebWorkers, Node Worker Threads или BrowserWindow. Всеки от тях има своите предимства и недостатъци, а случаят на употреба, с който се сблъсквате, ще определи кой от тях е най-подходящ.

Независимо коя алтернатива сте избрали за разтоварване на операциите от основната и визуализиращата нишки (когато е необходимо), помислете как ще бъде комуникационният интерфейс . Отне ми време да измисля интерфейс, от който бях доволен, тъй като това силно влияе върху структурата и функционирането на вашето приложение. Намерих полезно да експериментирам с различни подходи, преди да избера един.

Например, ако смятате, че интерфейсът за предаване на съобщения на WebWorkers може да не е най-лесният за отстраняване на грешки, опитайте comlink.

4. Тест ❌, тест ❌ и тест ✔️

Стари новини, нали? Исках да добавя това като последна точка, поради няколко анекдотични „проблема“, с които се сблъсках наскоро. Силно свързан с първата и втората точка, изграждането на вашия персонализиран стартов проект и грешките по-рано ще ви спестят ценно време за отстраняване на грешки по-нататък в разработката.

Ако сте спазили препоръките ми за разделяне на потребителския интерфейс и Backend на приложението на модули с изчистен интерфейс между двете, настройването на автоматизирани тестове за единица и интеграция трябва да е лесно. Докато приложението узрее, може да искате да добавите поддръжка и за e2e тестване.

Извличане на GPS местоположение? ️

Преди два дни, докато внедрявахме функцията за извличане на GPS местоположение за taggr , след като модулните тестове бяха зелени и функцията работи в разработка (с Webpack), реших да я изпробвам в производствената среда.

Въпреки че функцията работеше добре в разработването, тя се провали с ужас в производството. Информацията EXIF ​​от снимките беше прочетена като двоична и обработена от библиотека на трета страна. Докато двоичната информация беше правилно заредена и в двете среди (проверена с разл.), Библиотеката на трета страна се провали при анализирането на такива данни в производствената компилация. Извинете ме, ??

Решение : Разбрах, че настройките за кодиране в средите за разработка и производство, зададени от Webpack, не са еднакви. Това накара бинарните данни да бъдат анализирани като UTF-8 в процес на разработка, но не и в производство. Проблемът е отстранен чрез настройка на правилните заглавки за кодиране в HTML файловете, заредени от Electron.

Фънки снимки?

Когато манипулирате и работите с изображения, може да си помислите, че ако JPEG просто „работи“ на вашия компютър, това е валиден JPEG. Неправилно .

В процеса на работа с възел библиотека за обработка на изображения рязко , преоразмеряване няколко JPEG изображения разби приложението. След внимателно разглеждане причината са неправилни JPEG изображения, генерирани от фърмуера на Samsung. ? ‍♂️

Решение : настройване на подобрени граници на грешки в приложението (напр. Блокове try-catch), настройване на модула за синтактичен анализ на JPEG и подозрение за всичко. ? ️

Обобщение

Екосистемите Node и JavaScripts цъфтят, като всеки ден се създават и споделят много мощни инструменти.

Количеството опции затруднява избора на ясен път, за да започнете да изграждате новото си страхотно приложение Electron. Независимо от избраните рамки, бих препоръчал да се съсредоточите върху следното:

  1. Започнете от малко и добавете сложност постепенно.
  2. Внимателно структурирайте приложението си , като запазите бекенда и проблемите на потребителския интерфейс модулирани.
  3. Проектирайте с мисъл за модела с резби , дори когато създавате малки приложения.
  4. Тествайте и тествайте отново , за да уловите по-рано повечето грешки и да спестите главоболие.

Благодаря, че останахте до края! ?

taggr е междуплатформено настолно приложение, което позволява на потребителите да преоткрият своите цифрови спомени, като същевременно запазват поверителността си . Open-alpha идва скоро за Linux, Windows и Mac OS. Затова следете Twitter и Instagram, където публикувам актуализации за разработка, предстоящи функции и новини.