Composants angulaires génériques – Liaisons facultatives

Composants angulaires génériques

Je souhaite créer un ensemble de composants génériques (angular 1.5) avec plusieurs liaisons facultatives qui seraient utilisées dans plusieurs applications. J’ai peur que cela crée beaucoup d’observateurs inutiles pour une application qui n’utilise pas le maximum de liaisons facultatives. Exemple:

Component declaration:

let dateRangeComponent = {
    bindings: {
        label: '@',
        name1: '@',
        name2: '@',
        model1: '>?',
        model2: '>?',
        extra1: '>?'
    },
    template: `<div ng-if="$ctrl.model1>stuff</div>
               <div ng-if="$ctrl.model2>stuff</div>
               <div ng-if="$ctrl.extra1>stuff</div>`
};

Component use example:

<date-rage-component label="Pretty Date" name1="Start" name2="end"/>

Ma question est de savoir s’il est possible de supprimer automatiquement tous les éléments liés aux liaisons facultatives inutilisées, sachant qu’elles ne sont pas définies au moment de la compilation. Par exemple, imaginons que je veuille utiliser un composant dans mon application où il n’a besoin d’aucune des liaisons facultatives, angulaire créerait beaucoup d’observateurs inutiles pour garder le ng-if mis à jour, alors que nous savons qu’ils seront toujours faux.

Est-ce que je fais une optimisation précoce des performances lorsque cela n’est pas nécessaire ou que je comprends mal un concept ? J’ai pensé à créer une directive costum wrapper pour tirer parti de la compilation transclude paresseuse dans angular 1.5 Quelque chose comme ça (pseudo-code, non testé):

<optional-binding-once ng-if="::attrs.model1">
  <div ng-if="attrs.model1">
      stuff
  </div>
</optional-binding-once>

De cette façon, je pense que le code à l’intérieur de optional-binding-once ne serait compilé que si ng-if est vrai, réduisant ainsi un observateur si une liaison n’est pas définie.

(EDIT) Quelques conclusions après quelques tests et recherches

Eh bien, je suppose qu’il n’y a pas de solution triviale pour réduire le nombre d’observateurs à l’intérieur d’un composant lorsqu’il y a des liaisons facultatives non remplies.

J’ai effectué quelques tests à travers la phase $digest d’angular, pour vérifier si l’augmentation du nombre de ce type d’observateurs est vraiment un problème.

Voici mes résultats :

Les tests étaient dans le pire des cas avec 888 composants avec 4 liaisons optionnelles.

Chrome – Sans fixations optionnelles (composant 888, nombre total d’observateurs 889)

Nombre total d’observateurs : 889
Durée du cycle du dernier résumé : 0,9950000000026193
Temps moyen pour les 1004 derniers cycles de digestion : 1,0544920318724353 ms
démarrage du chargement du dom (400 ms)


Chrome – Avec fixations en option (composant 888, 4 fixations en option, total d’observateurs 4441)

Nombre total d’observateurs : 4441


Durée du cycle du dernier résumé : 1,1549999999988358
Temps moyen pour les 1001 derniers cycles de digestion : 1,6851748251747816 ms
démarrage du chargement du dom (600 ms)


Safari – Sans liaisons optionnelles (composant 888, nombre total d’observateurs 889)

Nombre total d’observateurs : 889


Durée du cycle du dernier résumé : 1,0849999999991269
Temps moyen pour les 530 derniers cycles de digestion : 1,211632075471664 ms
Safari – Avec liaisons optionnelles (composant 888, 4 liaisons optionnelles, nombre total d’observateurs 4441)

Nombre total d’observateurs : 4 441
Durée du cycle du dernier résumé : 1,7450000000026193
Temps moyen pour les 588 derniers cycles de digestion : 2,1167176870748237 ms


Conclusion :

Dans le pire des cas, le temps de $digest sera augmenté de 1 ms. Je ne pense pas que cette augmentation sera un goulot d’étranglement pour les performances de mon application. Ce type d’observateurs échouera dans la première condition $digest ( value = get(current)) !== (last = watch.last) && etc …), ayant ainsi un petit impact sur le temps de traitement, car ils ne changer ou salir le contexte angulaire !

 517 total views,  2 views today

One thought on “Composants angulaires génériques – Liaisons facultatives”

  1. […] J’ai essayé d’externaliser mes icônes SVG dans un fichier et de les référencer avec un balisage comme <svg><use xlink:href= »file.svg#icon » /></svg>. En théorie, cela fonctionne très bien, mais différents navigateurs ont des problèmes de rendu. Tous les navigateurs sont capables de restituer correctement le svg en référençant le symbole avec <use> à l’intérieur du fichier et en ouvrant directement l’url du fichier svg. […]

Add a Comment

Your email address will not be published.