Ce que je souhaite savoir avant de travailler avec Electron.js

Dans cet article, je vais partager comment vous pouvez éviter certaines des erreurs que j'ai commises en découvrant Electron.js? ‍♂️. J'espère que ça aide!

Remarque : ce ne sera pas un didacticiel de codage, mais plutôt une discussion sur mes plats à emporter personnels.

Il y a quelques mois, j'ai décidé de me concentrer davantage sur la création de mon produit secondaire, taggr . J'ai été inspiré pour le construire en raison du nombre de photos que j'ai sur mon ordinateur.

Pour ceux d'entre nous qui conservent une sauvegarde de leurs photos, ces collections deviennent souvent si volumineuses et complexes qu'elles deviennent un travail à temps plein à gérer. Un mélange de dossiers et de sous-dossiers peut contenir des sauvegardes d'images de messagerie instantanée, des images haute résolution de votre voyage à Bali, du mariage de votre oncle ou de l'enterrement de vie de garçon de l'année dernière.

Il est fastidieux de toujours garder de telles collections en ordre (croyez-moi, j'essaye depuis des années). C'est aussi durpour découvrir les clichés que vous aimez le plus, cachés au plus profond des dossiers.

Alors taggrest une application de bureau qui résout ce problème. Il permet aux utilisateurs de redécouvrir leurs souvenirs tout en préservant leur vie privée .

Je construis taggr en tant qu'application de bureau multiplateforme. Ici, je vais partager certaines des choses que j'ai apprises sur le développement d'applications multiplateformes avec Electron.js que j'aurais aimé savoir depuis le début. Commençons!

Contexte

Avant de présenter mes plats à emporter sur ce voyage en cours avec Electron, je voudrais donner un peu plus de contexte sur moi-même et les exigences de taggr .

Chaque développeur vient d'un milieu différent, tout comme les exigences des applications qu'ils développent.

La contextualisation des choix que j'ai faits pour ce projet peut aider les futurs développeurs à sélectionner les bons outils en fonction de leurs besoins et de leur expertise (plutôt que de ce qui est à la mode - GitHub?, Je vous regarde).

Comme mentionné précédemment, depuis le début, j'ai envisagé taggr comme une application multiplateforme. L'application effectuerait tous les calculs de pré-traitement et d'apprentissage automatique requis côté client en raison de l'accent mis sur la confidentialité.

En tant qu'émission individuelle, je voulais pouvoir écrire mon application une fois et l'expédier vers différents systèmes sans perdre la raison.

De mon côté, je suis un ingénieur front end amoureux du web et de JavaScript. J'ai déjà travaillé avec Java et C #, mais j'apprécie la flexibilité qu'offre le Web et son écosystème dynamique.

Ayant déjà fait l'expérience de la douleur liée à l'utilisation d'outils comme Eclipse RCP pour créer des applications côté client, je savais que je ne voulais plus travailler avec cette technologie.

En bref, mes exigences de pile pour taggr se résumaient à quelque chose comme ce qui suit:

  • Il devrait fournir un support multiplateforme, idéalement au niveau du cadre. ?
  • Cela devrait me permettre d' écrire le code une fois , et d'ajuster chaque plate-forme si nécessaire. ? ️
  • Il doit permettre l' accès aux capacités d'apprentissage automatique , quel que soit l'environnement hôte, sans que des environnements d'exécution spécifiques soient installés. Il devrait être indolore à mettre en place. ?
  • Si possible, il devrait utiliser les technologies Web . Ce serait formidable de tirer parti de mes connaissances existantes. ?

Comme vous pouvez le voir, les exigences ne se lisent pas comme suit: Je devrais utiliser React avec Redux, observables et WebSockets . Ce sont des détails de mise en œuvre de niveau inférieur, et ils devraient être décidés quand et si le besoin s'en fait sentir.

Choisissez le bon outil pour le travail plutôt que de choisir une pile depuis le début, sans tenir compte des problèmes à résoudre.

Alors, après avoir fouillé sur Google, j'ai décidé d'essayer Electron. Je n'avais jamais utilisé ce cadre auparavant, mais je savais que de nombreuses entreprises l'utilisaient avec succès dans des produits tels que Atom, VS Code, Discord, Signal, Slack et plus encore.

Open-source et avec une compatibilité immédiate avec les écosystèmes JS et Node (Electron est construit en utilisant Chromium et Node), Electron.js était un outil attrayant pour le travail en cours.

Je n'entrerai pas trop dans les détails concernant le reste de la pile, car j'ai changé à plusieurs reprises les parties principales (persistance et couches de vue) en cas de besoin, et cela sort du cadre de cet article.

Cependant, je voudrais mentionner Tensorflow.js, qui permet d'exécuter la formation et de déployer des modèles ML directement dans le navigateur (avec WebGL) et Node (avec des liaisons C), sans installer des environnements d'exécution spécifiques pour ML dans l'hôte.

Revenons donc à Electron - pensant que c'était parfait, le plaisir a commencé. ??

Assez parlé de l'arrière-plan. Plongeons dans les plats à emporter.

1. Commencez petit (et lentement)?

Ce n'est pas un nouveau concept, mais cela vaut la peine d'être évoqué périodiquement. Ce n'est pas parce qu'il existe une tonne de projets de démarrage impressionnants avec Electron que vous devriez en choisir un tout de suite.

Attendez. Quelle?

Lent est lisse et lisse est rapide. - Dicton de la marine

Avec la commodité vient la complexité

Bien que ces démarreurs incluent de nombreuses intégrations utiles (Webpack, Babel, Vue, React, Angular, Express, Jest, Redux), ils ont également leurs problèmes.

En tant que débutant Electron, j'ai décidé d'opter pour un modèle allégé qui incluait les bases pour `` créer, publier et installer des applications Electron '' sans les cloches et sifflets supplémentaires. Pas même Webpack au début.

Je recommande de commencer par quelque chose de similaire à la forge d'électrons pour être opérationnel rapidement, vous pouvezconfigurez votre graphique de dépendance et votre structure par-dessus pour apprendre les ficelles d'Electron.

Lorsque les problèmes surviennent (et ils le seront), vous serez mieux si vous créez votre projet de démarrage personnalisé plutôt que d'en choisir un avec des scripts +30 npm et +180 dépendances pour commencer.

Cela dit, une fois que vous vous sentez à l'aise avec la base d'Electron, n'hésitez pas à améliorer le jeu avec Webpack / React / Redux / TheNextHotFramework. Je l'ai fait progressivement et au besoin. N'ajoutez pas de base de données en temps réel à votre application todo simplement parce que vous avez lu un article sympa à ce sujet quelque part.

2. Structurez consciemment votre application? ‍♂️

Celui-ci a mis un peu plus de temps à être correct que je suis heureux de l'admettre. ?

Au début, il peut être tentant de mélanger l'interface utilisateur et le code backend (accès aux fichiers, opérations CPU étendues), mais les choses se compliquent assez rapidement. Au fur et à mesure que mon application se développait en fonctionnalités, en taille et en complexité, le maintien d'une interface utilisateur et d'une base de code backend enchevêtrées est devenu plus compliqué et sujet aux erreurs. De plus, le couplage rendait difficile le test de chaque pièce isolément.

Lors de la création d'une application de bureau qui fait plus qu'une page Web intégrée (accès à la base de données, accès aux fichiers, tâches intensives du processeur…), je recommande de découper l'application en modules et de réduire le couplage. Les tests unitaires deviennent un jeu d'enfant, et il existe un chemin clair vers les tests d'intégration entre les modules. Pour taggr , j'ai vaguement suivi la structure proposée ici.

En plus de cela, il y a la performance . Les exigences et les attentes des utilisateurs à ce sujet peuvent varier énormément en fonction de l'application que vous créez. Mais bloquer les threads principaux ou de rendu avec des appels coûteux n'est jamais une bonne idée.

3. Concevez avec le modèle de filetage à l'esprit?

Je n'entrerai pas trop dans les détails ici - je ne fais que doubler principalement ce qui est incroyablement expliqué dans la documentation officielle.

Dans le cas spécifique de taggr , il existe de nombreuses opérations intensives en CPU, GPU et IO. Lors de l'exécution de ces opérations dans le thread principal ou de rendu d'Electron, le nombre de FPS descend de 60, ce qui rend l'interface utilisateur lente.

Electron propose plusieurs alternatives pour décharger ces opérations des threads principaux et du moteur de rendu , tels que les instances WebWorkers, Node Worker Threads ou BrowserWindow. Chacun a ses avantages et ses mises en garde, et le cas d'utilisation auquel vous êtes confronté déterminera celui qui vous convient le mieux.

Quelle que soit l'alternative que vous choisissez pour décharger les opérations hors des threads principal et de rendu (si nécessaire), considérez comment l'interface de communication sera . Il m'a fallu un certain temps pour trouver une interface dont j'étais satisfait, car elle a un impact important sur la structure et le fonctionnement de votre application. J'ai trouvé utile d'expérimenter différentes approches avant d'en choisir une.

Par exemple, si vous pensez que l'interface de transmission de messages WebWorkers n'est peut-être pas la plus simple à déboguer, essayez comlink.

4. Testez ❌, testez ❌ et testez ✔️

De vieilles nouvelles, non? Je voulais ajouter ceci comme dernier point, en raison de quelques «problèmes» anecdotiques auxquels j'ai été confronté récemment. Fortement lié aux premier et deuxième points, construire votre projet de démarrage personnalisé et faire des erreurs tôt vous fera gagner un temps de débogage précieux plus loin dans le développement.

Si vous avez suivi mes recommandations pour diviser l'interface utilisateur et le backend de l'application en modules avec une interface propre entre les deux, la configuration de tests unitaires et d'intégration automatisés devrait être facile. Au fur et à mesure que l'application mûrit, vous souhaiterez peut-être ajouter la prise en charge des tests e2e.

Extraction de localisation GPS? ️

Il y a deux jours, lors de l'implémentation de la fonction d'extraction de localisation GPS pour taggr , une fois que les tests unitaires étaient au vert et que la fonctionnalité fonctionnait en développement (avec Webpack), j'ai décidé de l'essayer dans l'environnement de production.

Bien que la fonctionnalité ait bien fonctionné en développement, elle a lamentablement échoué en production. Les informations EXIF ​​des images ont été lues comme binaires et traitées par une bibliothèque tierce. Alors que les informations binaires ont été correctement chargées dans les deux environnements (vérifiées avec diff), la bibliothèque tierce a échoué lors de l'analyse de ces données dans la version de production. Pardon, ??

Solution : j'ai découvert que les paramètres d'encodage dans les environnements de développement et de production définis par Webpack n'étaient pas les mêmes. Cela a entraîné l'analyse des données binaires comme UTF-8 en développement mais pas en production. Le problème a été résolu en configurant les en-têtes de codage appropriés dans les fichiers HTML chargés par Electron.

Des images géniales?

Lorsque vous manipulez et travaillez avec des images, vous pouvez penser que si un JPEG «fonctionne» sur votre ordinateur, il s'agit d'un JPEG valide. C'est faux .

Tout en travaillant avec la bibliothèque de traitement d'image Node Sharp , le redimensionnement de certaines images JPEG a bloqué l'application. Après avoir examiné de près, la cause était des images JPEG incorrectes générées par le micrologiciel Samsung. ? ‍♂️

Solution : configurer des limites d'erreur améliorées dans l'application (par exemple, des blocs try-catch), modifier le module d'analyse JPEG et suspecter tout. ? ️

Sommaire

Les écosystèmes Node et JavaScripts sont en plein essor, avec de nombreux outils puissants créés et partagés chaque jour.

Le nombre d'options rend difficile le choix d'un chemin clair pour commencer à créer votre nouvelle application Electron impressionnante. Indépendamment de vos cadres de choix, je recommanderais de vous concentrer sur les éléments suivants:

  1. Commencez petit et ajoutez de la complexité progressivement.
  2. Structurez soigneusement votre application , gardez le backend et les problèmes d'interface utilisateur modulaires.
  3. Concevez avec le modèle de thread à l'esprit , même lors de la création de petites applications.
  4. Testez et testez à nouveau , pour détecter la plupart des erreurs dès le début et éviter les maux de tête.

Merci d'être resté jusqu'à la fin! ?

taggr est une application de bureau multiplateforme qui permet aux utilisateurs de redécouvrir leurs souvenirs numériques tout en préservant leur confidentialité . Open-alpha arrive bientôt sur Linux, Windows et Mac OS. Alors gardez un œil sur Twitter et Instagram, où je publie des mises à jour de développement, des fonctionnalités à venir et des actualités.