2.3 Principes de conception du FRONT

2.3.1 - Gestion commune des principales dépendances (via le workspace Angular)

L’ensemble du code du FRONT est rassemblé dans un workspace Angular. Ce workspace permet que tous les applicatifs FRONT puissent

  • être dépendants les uns des autres (sans publier de version dans un repository NPM/YARN) ;
  • partager les mêmes dépendances (pour ne pas avoir une version d’Angular différente d’une démarche à une autre).

2.3.2 - Segmentation du code

L’ensemble du code du FRONT se segmente, assez logiquement, en différents applicatifs (moins nombreux que le socle) : Le code du FRONT est construit dans un workspace Angular. Les différents projets existants sont :

  • Le framework est une librairie contenant toute l’intelligence d’une application frontale PSL dont le moteur se basant sur les fichiers de configuration d’une application de démarche.
  • La partie CYPRESS du framework contient les classes d’exécution des tests E2E.
  • L’application Edition permet de construire et tester une configuration publique d’application de démarche.
  • Chaque type de démarche donnant lieu à une application Angular distincte.

2.3.3 - conception du framework

Le framework de ma PSL est un ensemble de classes et de composants codés en Typescript soutenant le fonctionnement de toutes les démarches de la nouvelle PSL. Ce framework n’est pas exécutable en l’état car il n’est qu’une librairie présente dans l’espace de travail Angular (cf. noeud /projects/framework/projectType dans le fichier 2-code/front/angular.json. Il doit être utilisé depuis une application. Mais le framework est conçu pour que le volume de code et de configuration de chaque application de démarche soit le plus réduit et le plus simple possible.

En lui-même, le framework se divise en deux parties :

  • le code applicatif dans le répertoire 2-code/front/projects/framework/src/lib
  • le code utilitaire pour Cypress dans le répertoire 2-code/front/projects/framework/cypress

Côté applicatif, existent

  • des classes de modèle (des DTO) fournissant une structure correspondant aux données manipulées :
  • la structure d’un brouillon de démarche
  • la structure de la configuration de démarche (en deux fichiers TS)
  • les données liées à la sécurité OIDC
  • la structure des messages affichables à l’usager
  • des composants de service contenant l’intelligence et toutes les fonctionnalités subtiles :
    • le service statefull contenant toutes les données saisies page après page (uniquement les données validées au clic sur le bouton SUIVANT)
    • le service statefull contenant les BehaviorSubject permettant aux composants d’interagir entre eux sur des évènements globaux
    • les services stateless de gestion des bouchons (statut courant et jeux de données), des brouillons (sauvegarde et chargement), configuration (chargement et prise en compte), pièces jointes (upload), document (liste et download post-soumission), formulaire (création à partir de la configuration), sécurité OIDC, appels au référentiels, sécurité (plus golobalement que l’OIDC), appel au service de soumission et validation des données saisies.
  • des composants WEB structurant de l’application :entête, pied de page, fil d’Ariane, page
  • des composants paramétrables spécifiques correspondant à chaque besoin : paragraphe, saisie de texte, saisie de date, saisie d’adresse, …
  • des classes utilitaires

Les services les plus complexes à appréhender sont ceux se basant sur des fonctionnalités riches d’Angular (pas les appels à une API du socle) :

  • contexte.service.ts est basé sur un principe simple : tout évènement important (connexion réussie, changement de page, affichage d’un message à l’usager, chargement de la configuration, soumission, …) est notifié dans un BehaviorSubject à travers une methode ayant un véritable sens fonctionnel. De plus, ce composant de contexte retient/conserve les données dont la durée de vie est le déroulement de la démarche par l’usager (on perd tout si on recharge la page). Enfin, ce composant expose des méthodes public obtenirUnObservableSurxxx(): Observable permettant à tout composant de l’application de déclencher du code suite à la publication d’un évènement.
  • formulaire.service.ts est le gros algorithme utilisant, à fond, les fonctionnalités de formulaire “reactive” d’Angular. En quelques lignes, à travers les APIs TS d’Angular, est créée une instance de FormGroup représentant l’ensemble du formulaire de la page et un FormControl pour chaque champ de saisie de la dite page. La configuration/manipulation/lecture/miseAjour/… de ces champs se fait alors exclusivement dans le code TS. L’objectif est là de déplacer la compléxitée de la configuration de chaque champ de la page HTML (modèle des fomulaire template-driven) vers le code TS. Ainsi, le code de chaque type de composant (liste déroulante, radio, checkbox, …) reste simple car la compléxité est traitée de manière centrale dans le service formulaire.service.ts.

2.3.4 - tests automatisés

Les tests automatisés des écrans ne sont pas développé spécifiquement pour chaque démarche (sauf pour les parties de code codées en spécifique). Ces tests se basent, eux aussi, sur la configuration de la démarche et une partie du code du framework dédiée (tout le contenu du répertoire 2-code/front/projects/framework/cypress).

Ces tests automatisés se basent sur l’outil Cypress (framework de test encouragé par Angular en remplacement de Protractor). Chaque projet de démarche contient donc une configuration Cypress et un fichier 2-code/front/projects/codedemarche/cypress/e2e/codedemarche.cy.ts démarrant les tests :

  • chargement de la ressource statique de configuration bouchonnée (URL fournie depuis codedemarche.cy.ts)
  • chargement de la ressource statique du brouillon bouchonné (URL fournie depuis codedemarche.cy.ts)
  • calcul de tous les scénarios possibles selon les différents points d’entrée (toutes les combinaisons de paramètre d’entrée)
  • démarrage de tous les scénarios en chargeant l’application à partir de l’URL (sans usage du brouillon)
  • navigation de page en page en renseignant les champs avec les données du brouillon
  • vérification des libellés, de la présence/activation des pages/bloc/champs selon les conditions paramétrées

/!\ L’exécution des tests E2E ne peut se faire que si l’ensemble des bouchons sont actifs dans l’application Angular (pour disposer d’un jeu de donnée fixe et ne pas avoir de redirection sur un site externe pour l’authentification).