Donc, angular 8 est sorti, il comprend un aperçu Ivy, un support pour les techniciens de maintenance, le chargement différentiel et quelques autres touches de finition.
Manfred Steyer explique les changements les plus importants de la dernière version.
Comme prévu, il n'y a pas eu de surprise: la mise à jour du framework et de la CLI peut se faire à l'aide de la mise à jour ng, et de nouvelles fonctionnalités sont un bel ajout à la devise «évolution au lieu de révolution».
Dans cet article, l'auteur parle des nouvelles fonctionnalités les plus importantes d'Angular 8 et d'Angular CLI 8. Les exemples utilisés dans l'article se trouvent sur
GitHub .
Sous la coupe:
- Premier regard sur Ivy
- Travailleurs Web
- Charge différentielle
- Modules de chargement paresseux
- Changements critiques dans ViewChild et ContentChild
- Nouvelles fonctionnalités ngUpgrade
Premier regard sur Ivy
La prochaine grande nouvelle que la communauté angulaire attend est Ivy, un nouveau compilateur, et aussi un nouveau moteur de rendu. Ivy peut générer des bundles beaucoup plus petits, une compilation incrémentielle et est également la base de futures innovations dans Angular.
Étant donné que de nombreuses pièces de base d'Angular ont été modifiées, l'équipe Angular a accordé une attention particulière à la compatibilité avec les versions précédentes: après la mise à niveau vers Ivy, les applications existantes devraient fonctionner de la même manière qu'auparavant. Au mieux, vous obtiendrez des lots beaucoup plus petits. Ce n'est pas désintéressé, car plus de 600 applications sur Google sont officiellement basées sur Angular - le nombre réel serait beaucoup plus élevé.
Avec Angular 8, une version préliminaire d'Ivy est disponible pour les tests. Le but de cette version est d'obtenir un retour rapide. Par conséquent, l'équipe angulaire recommande de ne pas utiliser Ivy dans la prod en ce moment, mais de continuer à utiliser le moteur de vue classique (Fig.1)
Grâce au chargement différentiel (comme indiqué ci-dessous), les tailles de paquets peuvent être optimisées dès maintenant.
Selon Brad Green, CTO de l'équipe Angular chez Google, au ngconf 2019, Ivy améliorera considérablement la taille des packages en mode compatibilité, combinée à un chargement différentiel. Ainsi, les casse-cou peuvent déjà tester la future API Ivy. Ce mode, en particulier, a un grand potentiel d'optimisation. L'API est toujours marquée comme privée. En regardant ses classes et ses fonctions, vous pouvez dire: elles commencent par un symbole spécial ɵ.
Si vous voulez déjà essayer Ivy, vous pouvez créer un nouveau projet avec le commutateur enable-ivy:
ng new ivy-project --enable-ivy
Cette clé indique à la CLI d'enregistrer l'entrée suivante dans la configuration tsconfig.app.json:
"angularCompilerOptions": { "enableIvy": true }
Cette entrée peut également être ajoutée manuellement après la mise à niveau vers la version 8, pour tester une application existante à l'aide d'Ivy.
Pour exécuter l'application en mode débogage, il est recommandé d'utiliser AOT:
ng serve --aot
De plus, vous devez faire attention à la taille de l'application créée à l'aide de ng build. Avec angulaire 9, Ivy doit être activé par défaut. D'ici là, l'équipe Angular prévoit de continuer à travailler pour assurer la compatibilité avec les anciennes versions.
Travailleurs Web
JavaScript est un thread unique par définition. Pour cette raison, les tâches longues, telles que l'interrogation des données, sont généralement effectuées de manière asynchrone. Inutile de dire que cela n'aide pas dans les calculs complexes. Ils deviennent particulièrement courants avec les solutions JavaScript étendues, nous prenons donc en charge les travailleurs Web sur presque tous les navigateurs Web. Ce sont des scripts qui sont lancés par le navigateur dans un thread séparé. La communication avec le flux sur l'onglet du navigateur se fait via des messages.
Bien que les travailleurs Web ne soient pas liés à Angular en tant que tels, ils doivent être pris en compte lors de la construction. L'objectif est de fournir un package pour chaque travailleur Web. Cette tâche a été effectuée par la nouvelle CLI.
Pour démontrer une nouvelle fonctionnalité, je vais montrer à JavaScript l'implémentation du soi-disant «
problème des n reines ». L'idée est de placer une reine d'affilée sur un échiquier, sans pouvoir se menacer mutuellement. Cela signifie que dans la même rangée, colonne ou diagonale ne doit pas être une autre reine.
L'algorithme de calcul de toutes les solutions possibles sur un échiquier est considéré comme complexe sur le plan informatique. Bien que les calculs pour un échiquier ordinaire à huit et huit colonnes soient assez rapides, les ordinateurs conventionnels ont atteint la limite avec une carte 12 x 12. La solution pour une carte 27 x 27 est le record actuel. Pour cette tâche, des superordinateurs russes ont été utilisés.
Pour traduire ce calcul en arrière-plan, nous devons d'abord créer un travailleur Web à l'aide de la CLI:
ng generate worker n-queens
Cette instruction crée un fichier non seulement pour l'employé, mais aussi pour les fichiers de configuration nécessaires pour le processus de génération et les entrées dans les fichiers existants. Si le même dossier contient un composant du même nom avec une extension de fichier .component.ts commune, la CLI ajoutera également du code pour interagir avec le travailleur Web.
Le travailleur lui-même se compose d'un écouteur pour l'événement:
import nQueens from './n-queens'; addEventListener('message', ({ data }) => { const result = nQueens(data.count); postMessage(result, undefined); });
L'événement est exécuté lorsque le thread principal envoie un message au travailleur. Le paramètre contient des informations envoyées par le flux principal. Dans ce cas, il est limité par la propriété count, qui définit la taille de l'échiquier. Après avoir évalué la fonction nQueens, qui est omise ici, eventListener renvoie le résultat au thread principal via postMessage. Ainsi, le navigateur déclenche un événement de message.
La classe Worker est utilisée dans le composant using pour interagir avec le script de travail:
const count = parseInt(this.count, 10); const worker = new Worker('../logic/n-queens.worker', { type: 'module'
Le composant envoie un message avec la taille souhaitée de l'échiquier au travailleur via postMessage et commence ainsi le calcul. Il reçoit le résultat via l'événement de message.
À l'avenir, la CLI se charge de l'assemblage correct des scripts de travail. Le compilateur TypeScript les reconnaît à la fin de .worker.ts, qui est enregistré dans tsconfig.worker.json créé par la commande
ng generate worker . Pour garantir que la CLI n'affecte plus ces fichiers lors de la création de l'application principale,
ng generate worker place le même modèle de fichier dans la section d'exclusion de tsconfig.app.json.
L'implémentation complète est dans le projet avec des exemples de l'auteur. À titre de comparaison, un exemple de la tâche N reines peut être résolu à la fois dans le thread principal et dans le Web Worker. Lorsque vous essayez de résoudre un problème pour un échiquier 12 x 12, par exemple, vous verrez que l'interface utilisateur se bloque dans le premier cas, tandis que le calcul d'arrière-plan avec le travailleur Web ne réduira pas les performances.
Charge différentielle
Jusqu'à présent, il était de coutume de compiler des applications dans le bon vieux ES 5, puisque cette version de «JavaScript de nos pères» fonctionne presque partout. Cela signifie que IE11 et le robot d'exploration de Google peuvent exécuter ce code.
Cependant, la nouvelle ES 2015 et ses versions ultérieures sont plus efficaces: elles vous permettent de créer des packages plus compacts et le navigateur peut également les interpréter plus efficacement. Comme il était auparavant de coutume de revenir à ES 5 comme dénominateur le moins commun, les navigateurs modernes ne pouvaient malheureusement pas profiter de la nouvelle version de la langue.
Maintenant c'est fini: à partir de la version 8, la CLI a une fonctionnalité appelée chargement différentiel. L'idée est de fournir deux groupes de packages: l'un basé sur ECMAScript 5 et conçu pour les anciens navigateurs, l'autre basé sur une nouvelle version d'ECMAScript, comme ECMAScript 2015, et offre aux navigateurs modernes les avantages mentionnés précédemment.
Vous n'avez pas besoin de faire beaucoup de travail pour activer le chargement différentiel: il suffit de définir les limites supérieures et inférieures des versions prises en charge d'ECMAScript. La limite supérieure est indiquée dans tsconfig.json comme suit:
"target": "es2015"
La limite inférieure est définie dans le fichier de liste de navigateurs. Ce fichier comprend des navigateurs qui seront pris en charge selon certains critères, comme la part de marché par exemple. Ils peuvent être enregistrés, par exemple, dans le fichier de liste de navigateurs, que la CLI crée à la racine du projet lors de la création d'un nouveau projet:
> 0.5%
last 2 versions
Firefox ESR
not dead
IE 9-11
Dans ce cas, la liste des navigateurs comprend les navigateurs ES 5 avec une entrée IE 9-11. Ainsi, la CLI définit le seuil inférieur comme cette version. Lorsque la CLI reçoit la commande ng build, le processus de génération s'exécute pour les deux versions:
L'inconvénient de ce procédé est le suivant: le temps nécessaire à l'assemblage double.
Les navigateurs peuvent désormais décider de la version des packages à télécharger. Pour ce faire, ils obtiennent des liens vers des scripts dans le module complémentaire index.html: ceux qui pointent vers des packages ECMAScript 5 reçoivent l'ajout d'un nomodule. Ainsi, les navigateurs avec prise en charge ECMAScript et, par conséquent, prise en charge ECMAScript 2015+ n'ignoreront pas ce script. D'un autre côté, les packages ECMAScript 2015+ sont implémentés par la CLI avec type = "module". Ainsi, les anciens navigateurs ignoreront ces scripts:
<script src="main-es2015.js" type="module"></script> <script src="main-es5.js" nomodule></script>
Contrairement à ng build, les autres commandes CLI utilisent uniquement (!) La limite supérieure de la prise en charge ES. Dans notre cas, il s'agit d'ECMAScript 2015. Cela se produit, y compris pour des raisons d'efficacité: lors du débogage et des tests, les développeurs souhaitent généralement voir le résultat le plus rapidement possible, sans attendre la deuxième génération.
Modules de chargement paresseux
Dès les premiers jours, le routeur angulaire prend en charge le chargement paresseux. Jusqu'à présent, cela a été réalisé avec la définition magique d'un module chargeable:
{ path: 'lazy', loadChildren: () => './lazy/lazy.module#LayzModule' }
La valeur avant # décrit le chemin menant au fichier d'implémentation du module; la valeur après signifie la classe qu'elle contient. Ce style de description fonctionne dans Angular 8, mais a été déconseillé par rapport aux importations dynamiques ECMAScript:
{ path: 'lazy', loadChildren: () => import('./lazy/lazy.module').then(m => m.LazyModule) }
La nouvelle option d'enregistrement contient toujours le nom de fichier comme valeur magique. Cependant, comme les importations sont prises en charge par de nombreux IDE, les valeurs non valides renverront immédiatement une erreur.
Changements critiques dans ViewChild et ContentChild
Il y a des changements critiques dans l'utilisation de ViewChild et ContentChild, qui, malheureusement, dans le passé ne fonctionnaient pas toujours de manière prévisible. Si dans les versions antérieures, ils étaient utilisés par un composant pour interroger des éléments qui ne se trouvent pas dans la directive structure, tels que ngIf ou ngFor, le résultat de la requête était déjà disponible dans ngOnInit. Sinon, nous pourrions y accéder au plus tôt ngAfterViewInit (ou ngAfterContentInit pour ContentChild). Pour les éléments qui ont été chargés dans le DOM ultérieurement en raison de la liaison de données, le code du programme doit avoir ngAfterViewChecked ou, en conséquence, ngAfterContentChecked.
Comme ce comportement était déroutant, le composant devrait maintenant indiquer quand la résolution devrait se produire:
@ViewChild('info', { static: false }) paragraph: ElementRef;
Si l'indicateur statique est vrai, Angular essaiera de trouver les éléments lorsque le composant est initialisé. Cela ne fonctionne que s'ils ne figurent pas dans la directive structurelle. Lorsque vous utilisez static: false, la résolution est effectuée après l'initialisation ou la mise à jour de la vue.
ng update essaiera d'entrer automatiquement la valeur correcte, si ce n'est pas possible, il ajoutera un commentaire avec TODO.
Cette modification n'affectera pas les requêtes avec les décorateurs ViewChildren et ContentChildren. Ils ont toujours eu un comportement dynamique, en termes nouveaux dans le sens de statique: faux.
Nouvelles fonctionnalités ngUpgrade
Jusqu'à présent, l'un des problèmes avec AngularJS 1.X et Angular mélangé avec ngUpgrade était que les routeurs des deux frameworks étaient en concurrence en raison de l'URL. Cela a conduit à des effets secondaires difficiles à expliquer. Pour éviter cela, la possibilité d'utiliser un seul service de localisation d'URL dans les deux versions a été ajoutée.
Pour ce faire, l'équipe Angular a étendu les capacités des services de localisation Angular et a ainsi fourni un remplacement pour $ location dans AngularJS.
Pour cette raison, une nouvelle méthode onUrlChange a été ajoutée au service de localisation pour suivre les modifications d'URL:
export class AppComponent { constructor(loc: Location, pLoc: PlatformLocation) { loc.onUrlChange((url) => console.debug('url change', url)); console.debug('hostname: ', pLoc.hostname); } }
Le service PlatformLocation offre un accès supplémentaire à des parties spécifiques de l'URL. Une description détaillée de la façon dont le remplacement de $ location basé sur celui-ci est utilisé pour mieux intégrer les frameworks peut être trouvée
ici . De plus, vous pouvez maintenant trouver la solution de chargement paresseux AngularJS, qui est basée sur l'importation ECMAScript dynamique susmentionnée.
Conclusion
Encore une fois, l'équipe Angular a tenu parole: la transition vers la nouvelle version d'Angular est simple et n'inclut pas de changements majeurs. Au contraire, certains coins ont été lissés, ce qui rend le travail avec le cadre SPA de Google encore plus confortable. Le chargement différentiel offre des possibilités d'optimisation supplémentaire de la taille des packages si les anciens navigateurs ne sont pas pris en charge ou pris en charge par des packages distincts. La prise en charge de Web Worker montre que les tâches à forte intensité de calcul trouvent leur chemin vers le traitement dans le navigateur. Les amateurs peuvent désormais faire leurs premiers pas avec Ivy.
PS: Ceci est ma première traduction, veuillez donc noter les commentaires, suggestions et erreurs dans les commentaires.