Perkara yang Saya Ingin Tahu Sebelum Bekerja dengan Electron.js

Dalam artikel ini, saya akan berkongsi bagaimana anda dapat mengelakkan beberapa kesilapan yang saya buat semasa belajar mengenai Electron.js? ‍♂️. Saya harap ia dapat membantu!

Catatan : Ini tidak akan menjadi tutorial pengekodan, melainkan perbincangan mengenai pengambilan peribadi saya.

Beberapa bulan yang lalu, saya memutuskan untuk lebih fokus untuk membina produk sampingan saya, taggr . Saya mendapat inspirasi untuk membinanya kerana berapa banyak gambar yang saya ada di komputer saya.

Bagi kita yang menyimpan sandaran gambar mereka, koleksi tersebut sering menjadi sangat besar dan kompleks sehingga menjadi pekerjaan sepenuh masa untuk diuruskan. Gabungan folder dan sub-folder mungkin mengandungi sandaran gambar pesanan ringkas, gambar resolusi tinggi dari perjalanan anda ke Bali, perkahwinan bapa saudara anda, atau pesta bujang tahun lalu.

Sentiasa menjaga koleksi seperti itu membosankan (percayalah, saya telah mencuba selama bertahun-tahun). Ia juga sukaruntuk mengetahui gambar yang paling anda sukai, tersembunyi jauh di dalam folder.

Jadi taggradalah aplikasi desktop yang menyelesaikan masalah itu. Ini membolehkan pengguna menemui semula kenangan mereka sambil menjaga privasi mereka .

Saya membina taggr sebagai aplikasi desktop lintas platform. Di sini saya akan berkongsi beberapa perkara yang saya pelajari mengenai pembangunan aplikasi merentas platform dengan Electron.js yang semestinya saya tahu sejak awal. Mari kita mulakan!

Latar belakang

Sebelum membentangkan perjalanan saya dalam perjalanan berterusan dengan Electron, saya ingin memberi sedikit latar belakang mengenai diri saya dan keperluan taggr .

Setiap pembangun berasal dari latar belakang yang berbeza, dan begitu juga dengan keperluan aplikasi yang mereka kembangkan.

Kontekstualisasi pilihan yang saya buat untuk projek ini dapat membantu pemaju masa depan memilih alat yang tepat berdasarkan keperluan dan kepakaran mereka (dan bukan apa yang digembar-gemburkan di luar sana - GitHub?

Seperti disebutkan sebelumnya, sejak awal saya membayangkan taggr sebagai aplikasi lintas platform. Aplikasi ini akan melakukan semua pengiraan pra-pemprosesan dan pembelajaran mesin yang diperlukan oleh pelanggan kerana fokus pada privasi.

Sebagai pertunjukan satu orang, saya mahu dapat menulis aplikasi saya sekali dan menghantarnya ke sistem yang berbeza tanpa kehilangan kewarasan saya.

Dari sisi saya, saya adalah jurutera front-end yang suka dengan web dan JavaScript. Saya sebelumnya bekerja dengan Java dan C #, tetapi saya menikmati fleksibiliti yang disediakan oleh web dan ekosistemnya yang rancak.

Setelah mengalami sendiri keperitan menggunakan alat seperti Eclipse RCP untuk membina aplikasi pelanggan sebelum ini, saya tahu saya tidak mahu bekerja dengan teknologi itu lagi.

Ringkasnya, keperluan stack saya untuk taggr menjadi seperti berikut:

  • Ia harus memberikan sokongan merentas platform, idealnya di peringkat kerangka. ?
  • Ini membolehkan saya menulis kod sekali , dan mengubah setiap platform jika diperlukan. ? ️
  • Ini harus membolehkan akses ke kemampuan pembelajaran mesin , tanpa mengira persekitaran host, tanpa waktu runtuh tertentu dipasang. Ia tidak menyakitkan untuk disiapkan. ?
  • Sekiranya boleh dilaksanakan, ia harus menggunakan teknologi web . Akan sangat bagus untuk memanfaatkan pengetahuan saya yang ada. ?

Seperti yang anda lihat, syaratnya tidak boleh dibaca seperti: Saya harus menggunakan React with Redux, observables, dan WebSockets . Itu adalah perincian pelaksanaan tahap rendah, dan mereka harus diputuskan kapan dan jika diperlukan.

Pilih alat yang tepat untuk pekerjaan daripada memilih timbunan dari awal, tanpa mengabaikan masalah yang dihadapi.

Oleh itu, setelah googling yang marah, saya memutuskan untuk mencuba Electron. Saya tidak menggunakan kerangka itu sebelumnya, tetapi saya tahu bahawa banyak syarikat berjaya menggunakannya dalam produk seperti Atom, VS Code, Discord, Signal, Slack dan banyak lagi.

Open-source dan dengan keserasian di luar kotak dengan kedua-dua ekosistem JS dan Node (Electron dibangun menggunakan Chromium dan Node), Electron.js adalah alat yang menarik untuk pekerjaan yang sedang dilakukan.

Saya tidak akan terlalu terperinci mengenai timbunan yang lain, kerana saya berulang kali menukar bahagian teras (ketekunan dan lapisan pandangan) apabila diperlukan, dan ia tidak termasuk dalam skop artikel ini.

Walau bagaimanapun, saya ingin menyebutkan Tensorflow.js, yang membolehkan latihan berjalan dan menyebarkan model ML secara langsung di penyemak imbas (dengan WebGL) dan Node (dengan pengikatan C), tanpa memasang waktu berjalan khusus untuk ML di host.

Oleh itu kembali ke Electron - kerana menganggapnya sempurna, keseronokan bermula. ??

Cukup banyak perbincangan mengenai latar belakang. Mari selami jalan raya.

1. Mula kecil (dan perlahan)?

Ini bukan konsep baru, tetapi perlu dikemukakan secara berkala. Hanya kerana terdapat banyak projek pemula dengan Elektron yang tersedia, itu tidak bermaksud anda mesti memilihnya dengan segera.

Tunggu. Apa?

Lambat lancar, dan lancar cepat. - Kata tentera laut

Dengan kemudahan datang kerumitan

Walaupun permulaan itu merangkumi banyak penyatuan yang berguna (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), mereka juga mempunyai masalah.

Sebagai pemula Electron, saya memutuskan untuk memilih templat ramping yang merangkumi asas-asas untuk 'membuat, menerbitkan, dan memasang aplikasi Electron' tanpa loceng dan wisel tambahan. Permulaan Webpack pun tidak.

Saya mengesyorkan memulakan dengan sesuatu yang serupa dengan elektron-forge untuk bangun dan berjalan dengan cepat, Anda bolehsediakan graf dan struktur kebergantungan anda di atas untuk mempelajari tali elektron.

Apabila masalah datang (dan mereka akan), anda akan menjadi lebih baik jika anda membina projek starter tersuai anda daripada memilih satu dengan skrip +30 npm dan +180 kebergantungan untuk bermula.

Yang demikian, setelah anda merasa nyaman dengan basis Electron, jangan ragu untuk meningkatkan permainan dengan Webpack / React / Redux / TheNextHotFramework. Saya melakukannya secara bertahap dan bila diperlukan. Jangan tambahkan pangkalan data masa nyata ke aplikasi todo anda hanya kerana anda membaca artikel menarik mengenainya di suatu tempat.

2. Susun aplikasi anda dengan berhati-hati? ‍♂️

Yang ini memerlukan sedikit masa untuk mendapatkan yang betul daripada yang saya senang akui. ?

Pada mulanya, mungkin menggoda untuk menggabungkan kod UI dan Backend (akses fail, operasi CPU yang diperpanjang), tetapi semuanya menjadi rumit dengan cepat. Apabila aplikasi saya berkembang dalam ciri, ukuran, dan kerumitan, mengekalkan satu pangkalan data UI + Backend yang kusut menjadi lebih rumit dan rawan ralat. Juga, gandingan ini menjadikannya sukar untuk menguji setiap bahagian secara terpisah.

Semasa membuat aplikasi desktop yang melakukan lebih dari sekadar halaman web tertanam (akses DB, akses file, tugas CPU intensif…), saya sarankan untuk mengiris aplikasi menjadi modul dan mengurangkan gandingan. Pengujian unit menjadi mudah, dan ada jalan yang jelas ke arah pengujian integrasi antara modul. Untuk taggr , saya secara longgar mengikuti struktur yang dicadangkan di sini.

Selain itu, terdapat prestasi . Keperluan dan jangkaan pengguna mengenai perkara ini mungkin berbeza-beza bergantung pada aplikasi yang anda buat. Tetapi menyekat utama atau membuat utas dengan panggilan mahal tidak pernah menjadi idea yang baik.

3. Reka bentuk dengan mempertimbangkan model threading?

Saya tidak akan membincangkan secara terperinci di sini - saya hanya menggandakan apa yang dijelaskan dengan sangat jelas dalam dokumen rasmi.

Dalam kes khusus taggr , terdapat banyak operasi intensif CPU, GPU, dan IO yang telah lama berjalan. Semasa menjalankan operasi tersebut di utas utama elektron atau penyaji, kiraan FPS menurun dari 60, menjadikan UI terasa lembap.

Electron menawarkan beberapa alternatif untuk memunggah operasi tersebut dari utas utama dan penghantar , seperti WebWorkers, Node Worker Threads, atau instance BrowserWindow. Masing-masing mempunyai kelebihan dan peringatannya, dan kes penggunaan yang anda hadapi akan menentukan mana yang paling sesuai.

Terlepas dari alternatif mana yang anda pilih untuk memunggah operasi dari utas utama dan pemutus (bila diperlukan), pertimbangkan bagaimana antarmuka komunikasi akan . Saya memerlukan beberapa saat untuk menghasilkan antara muka yang saya puas, kerana ia sangat mempengaruhi bagaimana struktur dan fungsi aplikasi anda. Saya merasa berguna untuk bereksperimen dengan pendekatan yang berbeza sebelum memilihnya.

Sebagai contoh, jika anda fikir antara muka penyampaian mesej WebWorkers mungkin bukan yang paling mudah untuk disebat, cubalah pautan tautan.

4. Uji ❌, uji ❌, dan uji ✔️

Berita lama, bukan? Saya ingin menambahkan ini sebagai titik terakhir, kerana beberapa 'isu' anekdot yang baru-baru ini saya hadapi. Terhubung dengan titik pertama dan kedua, membina projek pemula tersuai anda dan membuat kesilapan sejak awal akan menjimatkan masa penyahpepijatan berharga dalam pengembangan.

Sekiranya anda mengikuti cadangan saya untuk membagi UI dan Backend aplikasi menjadi modul dengan antara muka yang bersih antara keduanya, menyiapkan ujian Unit dan Integrasi automatik semestinya mudah. Apabila aplikasinya semakin matang, anda mungkin ingin menambahkan sokongan untuk ujian e2e juga.

Pengambilan lokasi GPS? ️

Dua hari yang lalu, ketika melaksanakan fitur pengekstrakan lokasi GPS untuk taggr , setelah ujian unit berwarna hijau dan ciri tersebut berfungsi dalam pembangunan (dengan Webpack), saya memutuskan untuk mencubanya di lingkungan produksi.

Walaupun fitur ini berfungsi dengan baik dalam pengembangan, namun gagal dalam produksi. Maklumat EXIF ​​dari gambar dibaca sebagai binari dan diproses oleh perpustakaan pihak ketiga. Walaupun maklumat binari dimuat dengan betul di kedua-dua persekitaran (diperiksa dengan diff), perpustakaan pihak ketiga gagal ketika menguraikan data tersebut dalam produksi. Maafkan saya, ??

Penyelesaian : Saya mendapat tahu bahawa tetapan pengekodan dalam persekitaran pengembangan dan pengeluaran yang ditetapkan oleh Webpack tidak sama. Ini menyebabkan data binari diuraikan sebagai UTF-8 dalam pembangunan tetapi tidak dalam pengeluaran. Masalahnya diperbaiki dengan menyiapkan tajuk pengekodan yang betul dalam fail HTML yang dimuat oleh Electron.

Gambar pelik?

Semasa memanipulasi dan bekerja dengan gambar, anda mungkin berfikir bahawa jika JPEG 'hanya berfungsi' di komputer anda, itu adalah JPEG yang sah. Keliru .

Semasa bekerja dengan perpustakaan pemprosesan gambar Node dengan tajam , mengubah ukuran beberapa gambar JPEG merosakkan aplikasi. Setelah melihat dengan teliti, penyebabnya adalah gambar JPEG yang tidak betul yang dihasilkan oleh firmware Samsung. ? ‍♂️

Penyelesaian : menetapkan had ralat yang lebih baik dalam aplikasi (mis. Blok cubaan tangkapan), mengubah modul penghuraian JPEG, dan mencurigai semuanya. ? ️

Ringkasan

Ekosistem Node dan JavaScript berkembang, dengan banyak alat berkuasa dibuat dan dikongsi setiap hari.

Jumlah pilihan menjadikannya sukar untuk memilih jalan yang jelas untuk mula membina aplikasi Electron hebat anda yang baru. Terlepas dari kerangka pilihan anda, saya akan mengesyorkan untuk memberi tumpuan kepada perkara berikut:

  1. Mulakan kecil dan tambah kerumitan secara bertahap.
  2. Struktur aplikasi anda dengan berhati-hati , menjaga backend, dan masalah UI dimodulasi.
  3. Reka bentuk dengan mempertimbangkan model threading , walaupun semasa membuat aplikasi kecil.
  4. Uji dan uji lagi , untuk menangkap sebahagian besar kesalahan sejak awal dan menyelamatkan sakit kepala.

Terima kasih kerana terus bertahan hingga akhir! ?

taggr adalah aplikasi desktop lintas platform yang membolehkan pengguna menemui semula kenangan digital mereka sambil menjaga privasi mereka . Open-alpha akan segera hadir ke Linux, Windows, dan Mac OS. Oleh itu, perhatikan Twitter dan Instagram, di mana saya menyiarkan kemas kini pembangunan, ciri dan berita yang akan datang.