Question Quand privilégier ng-if vs ng-show / ng-hide?


je comprends que ng-show et ng-hide affecter la classe définie sur un élément et que ng-if contrôle si un élément est rendu dans le DOM.

Existe-t-il des directives sur le choix ng-if plus de ng-show/ng-hide ou vice versa?


485
2018-02-19 01:42


origine


Réponses:


Cela dépend de votre cas d'utilisation mais pour résumer la différence:

  1. ng-if va supprimer des éléments de DOM. Cela signifie que tous vos gestionnaires ou tout autre élément lié à ces éléments seront perdus. Par exemple, si vous avez lié un gestionnaire de clic à l'un des éléments enfants, ng-if évalue à false, cet élément sera supprimé de DOM et votre gestionnaire de clic ne fonctionnera plus, même après ng-if plus tard évalue à true et affiche l'élément. Vous devrez rattacher le gestionnaire.
  2. ng-show/ng-hide ne supprime pas les éléments de DOM. Il utilise des styles CSS pour masquer / afficher des éléments (remarque: vous devrez peut-être ajouter vos propres classes). De cette façon, vos gestionnaires qui ont été attachés aux enfants ne seront pas perdus.
  3. ng-if crée une portée enfant tout en ng-show/ng-hide ne fait pas

Les éléments qui ne sont pas dans le DOM ont un impact moindre sur les performances et votre application Web peut sembler plus rapide lors de l'utilisation. ng-if par rapport à ng-show/ng-hide. Dans mon expérience, la différence est négligeable. Des animations sont possibles lors de l'utilisation des deux ng-show/ng-hide et ng-if, avec des exemples pour les deux dans la documentation Angular.

En fin de compte, la question à laquelle vous devez répondre est de savoir si vous pouvez supprimer des éléments de DOM ou non?


667
2018-02-19 02:58



Voir ici pour un CodePen qui montre la différence dans le fonctionnement de ng-if / ng-show, DOM-wise.

@markovuksanovic a bien répondu à la question. Mais je viendrais d'un autre point de vue: je toujours utilisation ng-if et récupérez ces éléments dans DOM, sauf si:

  1. vous avez besoin pour une raison quelconque les liaisons de données et $watch-es sur vos éléments pour rester actifs tant qu'ils sont invisibles. Les formulaires peuvent être un bon exemple si vous voulez pouvoir vérifier la validité des entrées qui ne sont pas visibles pour déterminer si le formulaire entier est valide.
  2. Vous utilisez une logique dynamique complexe avec des gestionnaires d'événements conditionnels, comme mentionné ci-dessus. Cela dit, si vous vous retrouvez à attacher et détacher manuellement des gestionnaires, de telle sorte que vous perdez un état important lorsque vous utilisez ng-if, demandez-vous si cet état serait mieux représenté dans un modèle de données et les gestionnaires appliqués est rendu. En d'autres termes, la présence / l'absence de gestionnaires est une forme de données d'état. Récupérez ces données du DOM et dans un modèle. La présence / absence des gestionnaires devrait être déterminée par les données, et donc facile à recréer.

Angular est vraiment bien écrit. C'est rapide, vu ce qu'il fait. Mais ce qu'il fait, c'est tout un tas de magie qui rend les choses difficiles (comme la liaison de données bidirectionnelle) très simples. Rendre toutes ces choses faciles implique des frais généraux de performance. Vous pourriez être choqué de réaliser combien de centaines ou de milliers de fois une fonction de réglage est évaluée au cours de la $digestcycle sur un morceau de DOM que personne ne regarde même. Et puis vous réalisez que vous avez des dizaines ou des centaines d'éléments invisibles qui font tous la même chose ...

Les ordinateurs de bureau peuvent en effet être assez puissants pour rendre la plupart des problèmes de vitesse d'exécution de JS discutables. Mais si vous développez pour mobile, utiliser ng-if chaque fois que cela est humainement possible devrait être une évidence. La vitesse JS compte toujours sur les processeurs mobiles. L'utilisation de ng-if est un moyen très facile d'obtenir une optimisation potentiellement significative à très très faible coût.


128
2018-05-06 21:43



Selon mon expérience:

1) Si votre page a une bascule qui utilise ng-if / ng-show pour montrer / cacher quelque chose, ng-if provoque plus de retard du navigateur (plus lent). Par exemple: si vous utilisez un bouton pour basculer entre deux vues, ng-show semble être plus rapide.

2) ng-if va créer / détruire la portée quand elle est évaluée à true / false. Si vous avez un contrôleur attaché au ng-if, ce code du contrôleur sera exécuté chaque fois que le ng-if sera vrai. Si vous utilisez ng-show, le code du contrôleur n'est exécuté qu'une seule fois. Donc, si vous avez un bouton permettant de basculer entre plusieurs vues, l'utilisation de ng-if et de ng-show ferait une énorme différence dans la manière d'écrire votre code de contrôleur.


52
2017-10-07 23:08



La réponse n'est pas simple:

Cela dépend des machines cibles (mobile vs desktop), cela dépend de la nature de vos données, du navigateur, de l'OS, du matériel sur lequel il fonctionne ... vous aurez besoin de benchmark si vous voulez vraiment savoir.

C’est surtout un problème de mémoire ou de calcul… comme avec la plupart des problèmes de performance, la différence peut devenir significative avec éléments répétés (n) comme des listes, surtout quand imbriqué (n x n, ou pire) et aussi quel genre de calculs que vous exécutez à l'intérieur ces éléments:

  • ng-show: Si ces éléments optionnels sont souvent présents (dense), comme disons 90% des temps, il peut être plus rapide de les avoir prêts et de les afficher / masquer, surtout si leur contenu est bon marché (juste du texte, rien à calculer ou à charger). Cela consomme de la mémoire car il remplit le DOM avec des éléments cachés, mais juste afficher / cacher quelque chose qui existe déjà est susceptible d'être une opération bon marché pour le navigateur.

  • ng-si: Si au contraire les éléments ne sont pas susceptibles d'être montrés (clairsemés) il suffit de les construire et de les détruire en temps réel, surtout si leur contenu est cher à obtenir (calculs / triés / filtrés, images, images générées). Idéal pour les éléments rares ou à la demande, il économise de la mémoire en ne remplissant pas le DOM mais peut coûter beaucoup de calculs (création / destruction d'éléments) et de bande passante (obtention de contenu à distance). Cela dépend aussi de ce que vous calculez dans la vue (filtrage / tri) par rapport à ce que vous avez déjà dans le modèle (données pré-triées / pré-filtrées).


28
2017-10-20 08:21



Une note importante:

ngIf (contrairement à ngShow) crée généralement des portées enfants pouvant produire des résultats inattendus.

J'avais un problème lié à cela et j'ai passé beaucoup de temps à comprendre ce qui se passait.

(Ma directive écrivait ses valeurs de modèle sur la mauvaise portée.)

Donc, pour sauver vos cheveux, utilisez ngShow à moins de courir trop lentement.

La différence de performance est à peine perceptible de toute façon et je ne suis pas encore sûr de qui est la faveur sans un test ...


11
2017-09-10 11:43



Si tu utilises ng-show or ng-hide le contenu (par exemple les vignettes du serveur) sera chargé quelle que soit la valeur de l'expression mais sera affiché en fonction de la valeur de l'expression.

Si tu utilises ng-if le contenu sera chargé seulement si l'expression de la ng-si évalue à la vérité.

Utiliser ng-if est une bonne idée dans une situation où vous allez charger des données ou des images à partir du serveur et les afficher uniquement en fonction de l'interaction des utilisateurs. De cette façon, votre chargement de pages ne sera pas bloqué par des tâches intensives inutiles.


4
2017-09-20 17:36



ng-if sur ng-include et sur ng-controller aura un impact important sur ng-include, il ne chargera pas le partiel requis et ne traitera pas à moins que flag ne soit vrai sur ng-controller, il ne chargera pas le contrôleur sauf si flag est vrai mais le problème est quand un drapeau devient faux dans ng-si il enlèvera de DOM quand le drapeau devient vrai il rechargera le DOM dans ce cas ng-show est meilleur, pour une fois montre ng-si est meilleur


3
2017-07-04 03:49