electron jest spectron e2e unitaire test Cours logiciel - Electron

Chap 8 : Tests unitaires & end-2-end ( Spectron…

C’est lassant, ça prend du temps, et c’est bien souvent idiot au premier abord. Je vous présente donc….. les TESTS ! 😒 On les évites bien trop souvent, mais il faut le dire moi le premier, que l’on a tous connus des projets auquel à force de rajouts de fonctionnalités, que certaines unes d’entres elles, ont sans le vouloir casser d’autres fonctionnalités. En effet, quand on est sur une branche et que l’on focus cette nouvelle feature, on test celle-ci exclusivement dans l’environnement de développement. Et il se peut que l’on casse d’autres chose à vouloir bouger, modifier et optimiser notre code. Et on s’en rend bien souvent compte trop tard lors d’éventuelle realease en production, ce qui peut engendrer d’importantes conséquences. Ou dans le meilleur des cas comme moi, passer pour un con lors de mes démos 😅

 

Objectif

  • Installer & adapter les environnements Jest et Spectron à Electron
  • Réaliser des tests end-2-end
  • Réaliser des tests unitaires

 

Spectron & Jest : pourquoi et comment

Lors de la création d’un projet Angular via CLI, vous aurez d’avantage de chance de connaître les noms de Karma, Jasmine, ou encore Protractor, qui sont proposé par défaut.

 

  • Pourquoi migrer de framework si ceux de base sont proposé par Angular ? 🤔

 

Et bien pour deux raisons :

  1. Jest est vraisemblablement plus rapide que ses concurrents pour effectuer ses tests, car ils peuvent s’exécuter en parallèle. Vous gagnez donc au change, au fil du temps que votre application se développe.
  2. La seconde est que même si on créer à première vu un site web, il a néanmoins pour but d’être utilisé sous forme d’application bureautique via Electron. Les framework de test cité plus haut sont formidable pour tester des sites web. Cependant, comme on fait appel à des fonctions de l’API de Electron, on ne peut ouvrir notre application Electron convenablement sur notre navigateur favori. Ceux-ci ne vont donc être utile que vous du test unitaire, mais on peut dors et déjà oublier les tests e2e. C’est pour cela que Spectron est idéal, puisque développé pour tester des applications conçu sous Electron.
  3. Donne la couverture de code couvert par les tests
  4. Pas besoin d’un navigateur web pour exécuter les tests, tout se fait depuis la console
  5. Réalisation de ‘snapshot’, afin d’assurer que l’on ait pas de régression d’un point de vue UI

 

Jest

C’est le moteur de test développé par Facebook. Pratique, car tourne sur Angular, React, Vue.

 

Spectron
Spectron wrapper de WebDriverIO et Selenium

C’est un wrapper qui embarque à la fois Selenium, et WebDriverIO.

  • Selenium est un framework de test, qui permet de réaliser des opérations sur le navigateur web.
  • WebDriverIO quant à lui, est un autre framework de test qui reprend l’API de Selenium de façon customisé, écrit en javascript et exploitable par NodeJS. Il va ainsi ajouter des fonctionnalités de binding. On va pouvoir réaliser des opérations de click de souris sur des éléments, récupérer des champs de valeur, naviguer dans notre application, etc. Concrètement, on va pouvoir reproduire une utilisation du logiciel par un vrai utilisateur, mais en ligne de code.
  • Spectron, enfin, va ajouter des fonctionnalités pour avoir accès à l’ensemble de l’API de Electron

 

Optionnel : bibliothèque d’assertions

Lorsque on effectue des tests, on compare un état souhaité, avec l’état réellement obtenue lors de l’utilisation de l’application. J’utilise la librairie de base de NodeJS, à savoir assert. Simple et facile d’utilisation. Mais il est vrai que certains préférerons d’utiliser des styles d’écriture BDD ou TDD. Chai est une librairie que je recommande, qui permet de faire cela, tout en poussant les fonctionnalités de comparaison pour avoir des tests encore plus poussé.

Exemple de style que vous pouvez rencontrez, pour faire une comparaison de base :

  • Should : foo.should.equal(‘bar’);
  • Expect : expect(foo).to.equal(‘bar’);
  • Assert : assert.equal(foo, ‘bar’);

 

Spectron & Jest : utilisation

Installation

On commence par installer les modules nécessaire, en dépendance de développement via le gestionnaire de packets NPM :

Jest : npm install –save-dev jest

Auto complétion Jest : npm install –save-dev @types/jest

Spectron : npm install –save-dev spectron

 

/!\ Attention /!\

Veillez à bien respecter les versions entre Electron et Spectron, ou vous risquez d’avoir des soucis de compatibilité :

Electron Version Spectron Version
~1.0.0 ~3.0.0
~1.1.0 ~3.1.0
~1.2.0 ~3.2.0
~1.3.0 ~3.3.0
~1.4.0 ~3.4.0
~1.5.0 ~3.5.0
~1.6.0 ~3.6.0
~1.7.0 ~3.7.0
~1.8.0 ~3.8.0
^2.0.0 ^4.0.0
^3.0.0 ^5.0.0
^4.0.0 ^6.0.0
^5.0.0 ^7.0.0
^6.0.0 ^8.0.0
^7.0.0 ^9.0.0
^8.0.0 ^10.0.0

 

Configuration

On va créer un fichier de configuration pour jest, jest.config.json, à la racine de notre projet :

  • testMatch : définit une regexp pour matcher le nom des fichiers de tests. Ici, on garde les fichiers dans le dossier /e2e/,  et qui contient le mot .e2e. ou .unit. et qui est un fichier TS ou JS

 

Ensuite, on va ajouter un nouveau script pour automatiser le lancement de nos tests, dans notre fichier package.json :

  • config : pour renseigner la configuration crée précédent
  • runInBand : lancer les tests de façon séquentiel
  • detectOpenHandles : autorise Jest à fermer une session d’un test automatiquement si celui-ci ne se termine pas correctement, afin de continuer les tests

 

Squelette de base d’un test

Voici le template de base pour réaliser un test :

  • describe : c’est le mot clé pour définir un groupe de test
  • beforeEach : permet de retourner une application lancé a chaque début de test
  • afterEach : permet de fermer notre application une fois un test exécuté
  • it : mot clé pour définir un test

Vous pouvez observer la mise en place d’un timeout par Jest, mais aussi dans la définition de notre application. Cela permet de laisser un peu de temps à notre application pour s’ouvrir, avant de pouvoir l’utiliser.

L’ensemble des interactions possible via WebDriverIO sont disponible sur leur page de leur API.

 

Le code est exécuté de façon asynchrone. Vous allez donc devoir les rédiger soit en utilisant async/await, ou en utilisant des promesses. Chacun ses préférences, même si je trouve le code avec des async/await bien plus lisible et compréhensible.

 

Exemple de test

Je vous donne quelques exemple de tests simples, pour vous donnez des idées. Vous verrez les tests les plus simple à savoir cliquer sur des bouttons, récupérer des valeurs de champs de texte, accéder à l’API de Electron…

 

Vérifier que les outils de développement de Chronium ne sont pas ouvert 

 

Lire le contenu d’un champ texte

 

Vérifier la navigation entre module et composant

 

Tester l’application en plein écran

 

 

Conclusion

Spectron est la librairie officiel pour tester des applications sous Electron.

formation electron transpilation tsc Cours logiciel - Electron

Chap 7 : Backend en Typescript ( transpilation via…

Nous avons vu précédemment comment build et package l’ensemble de notre application en un .exe ou un installateur, si on souhaite le distribuer dans le chapitre précédent.

Je pensais avoir déjà fait un rapide tour d’Electron en 6 chapitres, mais à force de l’utiliser je pense pouvoir ajouter quelques chapitres supplémentaires qui pourrait bien vous servir et faciliter le développement autour de ce génial framework.

 

 

Objectif

  • Diviser les fonctionnalités de notre unique fichier du backend (main.js) en une multitude de fichiers
  • Permettre d’écrire le backend en Typescript et plus Javascript via un transpileur (TSC)
  • Pouvoir transpiler en instantané ( hot reload )

Le code source concernant ce chapitre est disponible sur mon Github.

 

 

Passage du Javascript vers le Typescript

Pour le moment, nous avons l’ensemble de notre application du frontend écrit via Angular en Typescript, mais le backend en Javascript. Il faut dire que le TS apporte beaucoup au JS traditionnel, et c’est pour cela que j’ai décider de migrer le backend. Il faut savoir que seul le pure javascript est compréhensible de nos navigateurs.

 

  • Comment Angular peut-il alors faire du frontend alors que l’on écrit notre application en TS ? 🤔🤔

 

De façon invisible, nous avons Webpack, planqué dans Angular, qui nous créer notre bundle en effectuant une multitude de transformation de nos fichiers, donc une que l’on va voir maintenant, est qui est la phase de transpilation. Celui-ci va transpiler l’ensemble de nos fichiers TS. Un mot bien complexe qui n’est rien d’autre que la conversion des fichiers TS en JS.

 

Script NPM pour la transpilation du typescript

Je suis parti sur TSC, qui est le transpiler de base de Typescript, car il est très simple d’utilisation, pas besoin de s’embêter avec un tas de paramétrage pour transpiler deux pauvres fichiers TS. Si vous souhaitez vous lancer dans des utilisations plus poussés, renseignez vous auprès de Webpack ou encore Babel.

 

On ajoute premièrement à notre package-json un nouveau script pour nous permettre d’appeler TSC :

  • backend-serve : nom du script
  • –project : argument pour fournir un fichier json de description pour le transpiler
  • –watch : argument pour compiler à la volé, dès qu’une sauvegarde de code est détecté

 

Si vous souhaitez transpiler seulement une fois sans avoir besoin du rechargement à la demande, vous pouvez supprimer l’argument ‘–watch’.

 

Une fois le script ajouté, on va créer un nouveau fichier comme vous avez pu le lire précédemment, tsconfig.backend.json, qui va nous permettre de décrire comment nous souhaitons transpiler nos fichiers TS.

Les arguments les plus importants sont :

  • include : on liste ici l’ensemble des fichiers TS que l’on souhaite transpiler
  • baseUrl : décrit la base du projet. On s’en servira plus tard lorsque je parlerais d’import de module en absolue ou relatif.

 

Ré-écrire son Main.js en typescript

Le but va être de ré-écrire son fichier d’entrée de notre application Electron, Main.js, en une version typescripté. Ouais je sais que ce mot existe pas, et alors c’est mon blog !😋

La ligne 5 représente un import de module pour les fichiers JS, la ligne 6 la méthode pour les fichiers TS

On va copier notre fichier Main.js et en faire un nouveau Main.ts. Vous risquez d’avoir quelques erreurs de lancé par votre linter, rien de bien complexe à modifier, vous devriez vous en sortir sans grand soucis. Un exemple dont vous pouvez avoir est la façon dont vous devez importer vos modules.

 

 

Je vais néanmoins quand même vous accompagner pour vos premières classes, car vous risquez d’avoir un petit soucis 😜

 

 

Architecture du backend

Jusqu’à présent nous n’avions qu’un seul fichier pour le backend, pour la gestion du cycle de vie de notre application. Au fur et à mesure des fonctionnalités que vous allez ajouter au backend, il se peut que vous souhaitiez éclater ce fichier ‘main.js’ en une multitude d’autres afin d’avoir une plus fine granularité, et ainsi d’améliorer l’extensibilité du code dans le futur. Je vous propose de suivre l’architecture suivante :

 

On va ajouter les deux classes suivantes :

  • StorageManager : on va lui déléguer l’ensemble des fonctionnalités de Main.js qui touche l’ensemble des serialization des données du module electron-store
  • CommunicationManager : on va lui déléguer l’ensemble des fonctionnalités de Main.js qui touche à l’échange d’informations entre le render et le main process, soit l’ensemble des fonctions du module IPC.

 

Erreur du loader/resolveFilename

Vous avez enfin une belle architecture, écrite en TS, et vous avez TSC de configuré. Aucune erreur sur l’ensemble de vos consoles, super, vous pouvez lancer Electron… et BIM ! Une belle erreur devrait apparaître, comme quoi vos nouveaux composants fraîchement crées ne sont pas trouvable 😒. Tsc étant un transpiler simple, il ne fait pas la liaison entre les composants lorsque on utile des imports absolue. Cependant si vous utilisez des importation de module avec des liens relatifs, vous n’aurez pas de soucis. Cependant, l’écriture de ces imports rend leur lecture complexe, en voici un exemple :

import * as test from ‘../../../../../../monModule’;

 

  • Mais pourquoi la console de TSC ne m’a pas indiqué d’erreur lors de la transpilation, mais seulement au moment de lancer Electron ? Car nous l’avons paramétré dans le fichier tsconfig.backend.json, avec l’argument ‘baseURL’ souvenez vous.

 

Si j’ai fais ce tutoriel avec TSC, c’est qu’il existe néanmoins des solutions, même si je vous avoue m’être bien cassé la tête sur ce problème. Pour résoudre ce soucis de chemin dans les require, vous avez deux petits modules à la rescousse disponible sur NPM.

 

Méthode 1 – La plus simple & basique

Son principe est simple, il va ajouter le répertoire parent de plus haut niveau dans le module de recherche de chemin de Node.

 

Il suffit d’installer le module suivant :

npm install app-module-path –save

C’est la méthode la plus simple, car il suffit d’ajouter une seule ligne de code, au début de notre fichier main.ts :

Pratique, car fonctionne lors du build, mais aussi en mode hot-reload durant le développement.

 

Cependant, si vous souhaitez seulement tester un fichier en particulier, une classe par example, et donc ne pas lancer votre application entière via le main.ts (faire simple un => node maclasse.js), cela ne fonctionnera pas car ayant ajouté le code précédent dans le main.ts, celui-ci ne sera pas lu. Pour cela vous êtes soit obligé de toujours lancer le main.ts depuis node pour que l’ensemble des imports soient modifiés, soit ajouter ce code dans l’ensemble des classes, ce qui peut vite devenir lassant. C’est pour cette raison là que je vous conseille la méthode 2.

 

Méthode 2 (recommandé) – Un poil plus complexe, mais plus flexible

Un second module vient à notre rescousse mais se comporte tout autrement. En effet, il va aller modifier les imports absolue de chaque fichier pour les remplacer par des liens absolue lors du build, dans les fichiers transpilé .js. Terriblement efficace, et pas bien plus complexe en ne nécessitant qu’une petite étape supplémentaire de configuration.

On installe ce module via:

  • npm install ttypescript --save
  • npm install @zerollup/ts-transform-paths --save

Héhé, je vous en fait installer un second en cachette car nous allons avoir besoin d’un wrapper, ttypescript, qui va nous permettre d’utiliser des plugins de transformation qui sont supporté dans notre fichier de configuration des options de compilation, disponible dans le fichier tsconfig.json.

 

Premièrement, on va modifier notre script NPM du fichier package.json de tout à l’heure pour qu’il utilise ttypescript que l’on vient d’installer :

 

On va ensuite modifier notre fichier de configuration qui permet de transpiler le backend, tsconfig.backend.json, afin de lui ajouter notre transformateur dans l’option ‘plugin’ pour qu’il puisse ré-écrire les imports :

Et on lui dit dans l’argument ‘paths’ de récupérer tout les fichiers à la base du projet et de les importer tel quel.

 

C’est finit, vous n’avez plus qu’a builder le backend depuis la console, avec notre script npm via la commande :

npm run backend-serve

Pour tester si tout fonctionne lancer le serveur de développement Angular avec:

npm run angular-serve

Ainsi que electron via :

npm run electron-serve

 

Mise à jour de la configuration du build

Afin de pouvoir continuer à builder, packager et distribuer votre application avec le module electron-builder, n’oubliez pas de modifier votre configuration de build disponible dans le fichier electron-builder.json ( ou dans votre package.json si vous n’avez pas dissocié les fichiers de configuration ). En effet, venant de modifier le backend en une multitude de nouveau fichiers TS et JS, nous devons mettre à jour notre configuration afin que celle-ci les prennes en compte dans le packaging de l’application. Pour cela, on va ajouter un nouvel item dans l’argument ‘files’, afin d’ajouter nos fichiers javascript précédemment transpilé :

 

Conclusion

On vient de voir la façon la plus simple pour pouvoir transpiler son backend Electron via TSC et un transformateur, pour résoudre les liens des imports absolue en relatif. Cela va nous permettre d’utiliser le typage et ainsi d’avoir un code source plus rigoureux grâce à Typescript.

 

Cours logiciel - Electron

Chap 2 : Barre d’outils, appel de l’API de…

Préface

Nous avons vu au chapitre précédent comment créer une frameless window basique.

Nous allons y ajouter quelques fonctionnalités de base que doit avoir un logiciel, via sa barre d’outils.

Le code source concernant ce chapitre est disponible sur mon Github.

Résultats du cours

 

Hot reloading du backend

Autant le hot reload des pages web du front se font automatiquement via le module Webpack contenu dans Angular, autant le backend ne s’effectue pas. Pour cela on va ajouter un module npm dans notre projet :

  • npm install electron-reload

Il va nous permettre de créer un nouveau main process de Electron, en lui donnant simplement en argument le chemin de l’exécutable de electron.

Nous lui ajouterons un argument pour permettre un hard reset du module, ce qui évite d’avoir des processus de Electron fantôme qui peuvent persister.

Et enfin un dernier argument, nous permettant de pouvoir injecter des arguments au lancement de electron, et dans notre cas de garder dans notre environnement de dév, le lancement des dev tools de chronium.

 

Barre d’outils via l’API de Electron

Définition de la vue, via des flexbox 

On va introduire des notions de responsive design qui est propre aux stack du web. Ceci nous permet de rendre adaptable la vue d’une page en fonction de la hauteur et largeur de l’écran de l’utilisateur, et ainsi d’en modifier sa disposition. On parle alors de Flexbox. Celles-ci sont déclaré dans les pages CSS, et permette de définir des règles de disposition entre chaque éléments ( des <div> par exemple ). Cela peut définir des règles pour indiquer comment tel ou tel élément doit grossir, réduire, ou encore se disposer en ligne ou colonne avec ses éléments voisin. Un petit module que j’apprécie et qui est disponible sur NPM, va nous permettre d’induire ces flexbox, directement dans les balises du code HTML de la page :

  • npm install @angular/flex-layout

 

On souhaite avoir une barre d’outils comme ceci :

  • Partie gauche :
    • Une icone du logiciel avec un bouton d’accueil
  • Partie du milieu :
    • Le nom du logiciel
  • Partie droite :
    • Une barre d’outils avec des boutons permettant de réduire, de minimiser/maximiser la fenêtre, ainsi qu’un dernier pour fermer la fenêtre

 

1 – Contener Global

On va commencer par créer un contener global ( notre mat-toolbar ), qui va prendre le maximum d’espace possible de son parent, définit par la directive fxFill :

 

2 – Création des 3 sous conteners (définit précédemment)

On utilise la directive fxLayout=’row’ afin de créer 3 conteners sur la même ligne. Quand a fxLayoutAlign=’space-between’, elle va nous permettre de définir le type d’espacement entre chacun d’eux. Celle-ci nous permet de les espacer au maximum des un aux autres.

 

3- Alignement vertical d’un des trois sous conteners

On souhaite qu’ils soient aligné au milieu ce leur ligne. On va donner l’exemple pour le contener de droite. Pour cela, on va ajouter au contener précédent, la directive fxLayout=’column’ pour pouvoir créer des conteners de façon vertical ( rappeler vous que le row permet d’aligner des conteners de façon horizontal), avec le bon fxLayoutAlign=’center’ qui va bien, pour permettre de les aligner au milieu au seins de celui-ci.

Si on reprend notre cheminement depuis le début, on doit normalement avoir un contener fixé à droite de la barre, et qui sera aligné au milieu concernant son axe vertical. On souhaite maintenant avoir y incorporer 3 bouttons d’actions.

 

4 – Boutons d’actions

On va recréer un contener de type row cette fois-ci, nous permettant de grouper l’ensemble de nos trois boutons de façon horizontal. En effet avec le point précédent, nous étions dans un contener de type column, et donc aligné sur l’axe vertical, chose que l’on ne souhaite pas.

Vous n’avez plus qu’a ajouter vos trois boutons, avec l’appel aux fonctions qui seront déclaré dans le contrôleur, via la directive de angular, (click)=’votre_fonction()’.

 

Pour un peu d’esthétisme, j’ai rajouté une classeclass=‘button hoverBtnWhite‘, lié dans le fichier CSS, permettant qu’au passage de la souris, la couleur de l’icone et de son background change.

 

 

Définition du contrôleur, via le service Electron

Maintenant que la partie graphique est mise en place, on va passer au contrôleur, permettant d’ajouter des actions à nos jolis boutons 😉

On va ajouter un nouveau module, nous permettant d’accéder à l’API de Electron directement depuis notre contrôleur.

  • npm install ngx-electron --save

On l’importe dans notre module principal, soit App :

import {NgxElectronModule} from 'ngx-electron';

Et on le déclare dans la partie des imports :

import: [ NgxElectronModule ]

Dans notre composant Header.ts, nous aurons besoin d’importer le module ElectronService. En créer un attribut de classe, l’instancier lors de la construction du composant, et se servir du module REMOTE de l’API de Electron. On va alors pouvoir utiliser via ce module, les utilitaires du process main, depuis le render process. Le code suivant vous montre comment lier nos boutons créer précedemment pour leur affecter respectivement les actions  suivantes :

  • fermer la fenêtre,
  • réduire la fenêtre,
  • maximiser,
  • unmaximiser.

 

Materials icons en offline

Si vous utilisez des icons de la librairie Material, soit celle de base de Angular, vous allez les télécharger à chaque lancement de l’app. Cependant, le jour ou vous voulez déployer votre application hors ligne, plus rien de marche, et les messages d’erreurs ne sont pas tellement explicite, vous êtes obligé d’aller chercher dans les requetes HTTP. Pire si comme moi vous avez du déployer une app offline sur iPad, sans n’avoir de console de développeur de iOS, alors autant prévoir les choses à l’avance. On va utiliser un module disponible sur NPM pour pouvoir toujours les avoir dans notre app :

  • npm install material-design-icons-iconfont --save

Et ajoutez les lignes suivantes dans votre fichier de style globale de votre app, soit style.scss :

 

Conclusion

Nous venons de voir comment appeler l’API de Electron depuis notre front en Angular, pour lui ajouter des fonctionnalités simple d’un logiciel.

Nous verrons au prochain chapitre comment créer un explorateur de fichier simple, pour présenter le module ipc de Electron, permettant de communiquer et d’échanger des données entre main et render process.

 

 

Cours web frontend - Angular 8

Chap 5 : Gestion de la navigation via les…

Nous avons vu au chapitre précédent, l’ajout de deux composants dans notre application web, dont un menu de navigation. On va souhaiter maintenant de pouvoir nous balader à travers notre app pour afficher tel ou tel composant. Le code source du projet est disponible ici sur Github.

 

Routing entre component

On va commencer par créer deux nouveaux composants pour correspondre à nos deux onglets du menu :

  • ng generate component acheter
  • ng generate component vendre

Automatiquement, ces deux composants vont être déclarés dans notre app.module.ts.

 

On va créer deux alias pour deux routes différentes dans notre nav bar qui permettront de rediriger vers un composant :

 

On va aller ajouter cette redirection de route dans notre fichier app-routing.module.ts. On ajoute aussi l’import de nos deux composants. Quand au fichier de routing, celui ci est crée lors de la création du module si vous ajoutez l’attribut --routing.

On va dire de charger tel ou tel composant selon l’alias renvoyé par notre nav bar :

 

Redirection d’une route

Une chose qui peut être intéressant, c’est de pouvoir rediriger une route vers un composant spécifique. Par exemple, au démarrage de l’application, on souhaite charger par défaut un onglet spécifique.  Nous allons ajouter une directive de redirection dans le fichier app-routing.module.ts comme cela :

 

On est alors automatiquement redirigé lorsque l’on ouvre localhost:4200 vers localhost:4200/acheter, avec le composant ‘acheter’ d’ouvert :

 

Routing pour entre module

On va créer un nouveau module pour imager notre navigation entre module :

  • ng generate module login --routing

Ainsi que trois nouveaux composants :

  • ng generate component inscription
  • ng generate component connexion
  • ng generate component login

On va se service de login pour créer une seconde nav bar, nous permettant de naviguer au seins du module Login pour nous permettre de choisir entre la page d’inscription et de connexion.

 

On ajoute le nouvel onglet à notre nav bar principal:

 

On ajoute la nav bar secondaire :

 

N’oubliez pas d’ajouter dans le constructeur de login.component.ts, les items du sous menu :

La balise <router-outlet></router-outlet> va nous permettre d’inclure le code HTML des enfants dynamiquement, soit login/connexion ou login/inscription à tout moment lors de la navigation.

 

Il nous reste plus qu’a ajouter les routes des enfants du module Login dans notre fichier de routing principal qui est dans le module app :

 

Lazy loading, ou chargement à la demande

Au fur et à mesure que vous ajoutez des fonctionnalités à votre application, il se peut que celle-ci prennent de plus en plus de temps à s’ouvrir. En effet, c’est lors du démarrage que l’ensemble des pages sont récupérés, que les objets sont construits, etc. Afin d’alléger cette phase, on peut donner une nouvelle directive à angular, lui demandant de charger les modules à la demande seulement. Ces composants ou modules ne seront donc crée que lorsque l’un de ses composant sera appelé lors de la navigation.

Premièrement on va modifier notre appel à notre module Login  dans le fichier de routing principal de notre application :

 

Ensuite, on a juste à donner les nouvelles routes au sein du module enfant :

 

Pre loading

Nous venons de voir comment charger nos modules séparément et à la demande. On peut encore optimiser ces temps de chargement au démarrage.

En effet, une fois le module principal chargé, on pourrait demander à Angular de pouvoir pré-charger en arrière plan les autres modules de l’application, alors même que l’utilisateur peut dors et déjà interagir avec le module principal de l’application. Cela permettra ainsi d’avoir une navigation quasi instantané des autres modules.

Pour cela, on va modifier la stratégie de pré-chargement dans le fichier de routing principale de l’application :

 

 

Cours web frontend - Angular 8

Chap 3 : Structure d’un application Angular

Nous avons vu au chapitre précédent comment générer le squelette de base d’une application sous Angular 8. Nous avons vu une multitude de fichiers crées lors de cette génération effectue par Angular/Cli.

Sont-ils tous réellement utiles ? A quoi correspondent-ils ? Je vais vous en présenter les principaux à connaître.

Il faut savoir que Angular permet de créer une multitude de brique logiciel ( composant, service, classe…  ) que l’on va assembler entre eux de façon organisé et distincte ( module ).

 

Structure globale

/e2e

Ce dossier va permettre de rédiger divers test end to end par le framework Protractor

 

/package.json

C’est un fichier json qui va contenir la description de l’ensemble des modules NPM utilisé pour notre application. Vous aurez le choix d’installer ou d’update certains packet en comparant ce fichier. Utilise aussi pour gérer les dépendances nécessaires entre packet.

 

/angular.json

Fichier de configuration qui contient certains hyper paramètres important, tel que le dossier de sortir pour les builds de production, les dossiers contenant les fichiers de styles ou encore les assets, la page HTML principal à afficher, etc.

 

/src

Ce dossier va contenir l’ensemble de nos fichiers sources de notre application

 

Module et composition

Un module est un conteneur, un building block. Il permet de créer des packages distant d’un point de vue fonctionnalité. Par exemple pour un site web simple comme le bon coin, on peut avoir un module pour la gestion des annonces, et un module pour la gestion de l’authentification des comptes.

Ces modules nous apportent une plus fine granularité au sein d’un projet. Cela permet plus tard, d’améliorer l’extensibilité et la maintenabilité du code pour l’ajout de nouvelles fonctionnalités.

Vous pouvez créer un module via la commande Cli suivante :

  • ng generate module [nom du module] –routing

L’option –routing est optionnel, mais nous facilite la tâche. Nous le verrons juste après.

 

Cette commande va nous créer plusieurs fichier. On imagine que notre module s’appelle APP.

  • app.module.ts : c’est le fichier centrale de notre module. On y définit l’ensemble des imports qui seront utilisé dans notre module (librairies NPM), on y définit l’ensemble des composants qui y seront déclaré, mais aussi des services.  C’est quelque peu comme les fichiers H/HPP en C/C++.
  • app-routing.module.ts : c’est le fichier responsable de la navigation entre composant, et donc entre les vues.

 

Component et composition

Un composant est une entité dans angular. Il prend la forme que vous lui donnez. Cela peut très bien être une page d’accueil en entier, comme une simple barre de navigation servant de menu. C’est à vous de choisir encore une fois la granularité que vous donnez aux objets de votre application.

 

Vous pouvez créer un composant via la commande Cli suivante :

  • ng generate component [nom du composant]

 

Cette commande va nous créer plusieurs fichier. On imagine que notre module s’appelle comp1.

  • comp1.component.css : c’est la feuille de style de notre component
  • comp1.component.html : c’est la feuille qui correspond à la partie graphique, la vue
  • comp1.component.spec.ts : c’est un fichier permettant de réaliser des tests, qui seront automatisé avec Protractor
  • comp1.component.ts : c’est le contrôleur de notre component. Il va nous permettre d’y ajouter des fonctionnalités entre la vue, les boutons, la base de données, etc.
Cours web frontend - Angular 8

Chap 2 : Initialisation de notre première application

On a vu comment installer les dépendances nécessaires à une application web dans le chapitre précédent.

On va maintenant voir comment générer le squelette de base d’une application en Angular 8.

Création de l’app

On va générer notre application avec la commande CLI suivante :

  • ng new NomdeL’app

 

CLI va nous demander plusieurs questions concernant la génération :

Angular routing : nous le verrons dans un prochain chapitre. Cela permet de gérer la navigation au sein de l’application. On ne va pas s’en servir dans le chapitre actuel, mais vous pouvez mettre Oui.

Choix des feuilles de style : CLI nous propose entre CSS, SCSS et Sass. Le CSS étant le plus commun, on va garder celui-ci. Sachez que le compilateur transformera le SCSS et Sass en CSS. Ces deux derniers permettent juste une écriture des styles de façon plus lisible et rapide. Ce choix n’est pas définitif puisque vous pourrez le changer à n’importe quel moment plus tard dans le développement de votre application.

Comparaison syntaxique entre 3 langages de style

Cli va nous générer des fichiers. Pas besoin de savoir l’utilité de chaque pour le moment, nous le verrons dans le prochain chapitre. On va se déplacer dans le fichier racine du projet :

  • cd NomdeL’app

Pour enfin lancer :

  • ng serve

Cette dernière commande va nous permettre de build notre application. Et celle-ci est pratique, puisqu’il suffira de changer une seule ligne de code dans notre projet, pour que le projet soit re-buildé automatiquement, et que l’on voit les modifications dans le navigateur en temps quasi-réel.

 

Vous n’avez plus qu’a lancer votre navigateur préféré et aller sur :

  • http://localhost:4200/

 

Eeeeeeeeeh TADAAAAAAA

Je vous l’accorde ce n’est pas ouf. Mais c’était rapide non ?

 

Avant d’aller plus loin dans  la customisation de notre application web, dans le prochain chapitre 3, nous ferons une halte pour comprendre l’ensemble des composants crées précédemment.

Cours web frontend - Angular 8

Chap 1 : Installation des pré-requis

Pour créer le frontend d’une application avec le framework Angular, il va nous falloir installer quelques dépendances nécessaires. Rassurez-vous, rien de bien long 🙃

 

Node.Js & NPM

Pour faire simple, c’est un framework en Javascript permettant de réaliser des serveurs pour le backend. On en a besoin puisqu’il va nous fournir NPM. C’est le gestionnaire de packet pour le web, comme NuGet pour le C#, ou encore PiP pour Python. Il va nous permettre d’installer pleins de librairies nous facilitant le développement de notre application.

 

Vous pouvez le récupérer sur son site https://nodejs.org/en/

Installer la version que vous souhaitez cela importe peu. Il va créer un dossier Node sur le disque C. Vous devrez rajouter ce dossier C:\ProgramFiles\Node\ au PATH des variables d’environnement de votre système d’exploitation, pour que nous puissions utiliser les alias dans la console.

On peut alors tester que tout fonctionne correctement :

C’est OK pour nous, on a bien Node.Js et NPM qui sont accessible.

 

Angular & Angular/Cli

La prochaine étape va être d’installer la librairie Angular. Mais pourquoi alors parler de Angular/Cli ? CLI est une interface de ligne de commande pour Angular, une sorte d’extension. Elle va nous permettre de faciliter la création d’une application Angular par la suite en créant à notre place toute sorte d’objets pré codés, nous permettant alors de gagner un certain temps.

Dans une console on va alors se mettre à la racine du projet duquel on souhaite créer, et exécuter :

  • npm i @angular/cli

 

Vous pouvez voir l’ensemble des packets installé via :

  • npm list –depth=0

L’attribut –depth est facultatif. Il permet de réduire l’arbre des dépendances de l’ensemble des packets pour y voir plus claire

 

Nous voilà OK pour le chapitre suivant, auquel on va pouvoir initialiser notre première application !