Quand privilégier ng-if par rapport à ng-show/ng-hide ?

Question

Je comprends que ng-show y ng-hide affectent la classe définie sur un élément et que ng-if contrôle si un élément est rendu comme faisant partie du DOM.

Existe-t-il des directives pour choisir ng-if sur ng-show / ng-hide ou vice-versa ?

Answer 1

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

1. ng-if supprimera les éléments du 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 clics à l'un des éléments enfants, lorsque la fonction ng-if évalue à false, cet élément sera supprimé du DOM et votre gestionnaire de clic ne fonctionnera plus, même après que la fonction ng-if évalue ensuite à true et affiche l'élément. Vous devrez rattacher le gestionnaire.
2. ng-show/ng-hide ne supprime pas les éléments du DOM. Il utilise les styles CSS pour cacher/afficher les éléments (note : vous devrez peut-être ajouter vos propres classes). De cette façon, vos gestionnaires qui étaient attachés aux enfants ne seront pas perdus.

Les éléments qui ne sont pas dans le DOM ont moins d'impact sur les performances et votre application web peut sembler plus rapide lorsque vous utilisez la fonction ng-if par rapport à ng-show/ng-hide . D'après mon expérience, la différence est négligeable. Les animations sont possibles en utilisant à la fois 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 un élément du DOM ou non ?

Answer 2

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

@markovuksanovic a bien répondu à la question. Mais je l'aborderais sous un autre angle : je toujours utilice ng-if et sortir ces éléments du DOM, à moins que :

1. vous avez, pour une raison quelconque, besoin des liaisons de données et des $watch -sur vos éléments pour qu'ils restent actifs alors qu'ils sont invisibles. Les formulaires pourraient être un bon cas pour cela, si vous voulez être en mesure de vérifier la validité des entrées qui ne sont pas actuellement visibles, afin de déterminer si le formulaire entier est valide.
2. Vous utilisez une logique d'état très élaborée avec des gestionnaires d'événements conditionnels, comme indiqué ci-dessus. Cela dit Si vous vous retrouvez à attacher et détacher manuellement des gestionnaires, de sorte que vous perdez un état important lorsque vous utilisez ng-if, demandez-vous si cet état ne serait pas mieux représenté dans un modèle de données, et si les gestionnaires ne seraient pas appliqués conditionnellement par des directives chaque fois que l'élément est rendu. En d'autres termes, la présence/absence de gestionnaires est une forme de données d'état. Sortez ces données du DOM, et mettez-les 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 très bien écrit. Il est rapide, compte tenu de ce qu'il fait. Mais ce qu'il fait, c'est tout un tas de magie qui fait que des choses difficiles (comme la liaison de données à deux voies) semblent trivialement faciles. Faire en sorte que toutes ces choses paraissent faciles implique une certaine surcharge de performance. Vous pourriez être choqué de réaliser combien de centaines ou de milliers de fois une fonction setter est évaluée au cours de l'exécution de la fonction $digest sur un morceau de DOM que personne ne regarde. 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 suffisamment puissants pour rendre la plupart des problèmes de vitesse d'exécution des JS sans objet. Mais si vous développez pour les mobiles, utiliser ng-if chaque fois que c'est humainement possible devrait être une évidence. La vitesse d'exécution des JS est toujours importante sur les processeurs mobiles. L'utilisation de ng-if est un moyen très simple d'obtenir une optimisation potentiellement importante à un coût très, très faible.

Answer 3

D'après mon expérience :

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

2) ng-if créera/détruira la portée quand il évalue à true/false. Si vous avez un contrôleur attaché au ng-if, le code de ce contrôleur sera exécuté chaque fois que le ng-if sera évalué à true. Si vous utilisez ng-show, le code du contrôleur ne sera exécuté qu'une seule fois. Donc, si vous avez un bouton qui bascule entre plusieurs vues, l'utilisation de ng-if et de ng-show fera une énorme différence dans la façon dont vous écrirez votre code de contrôleur.

Answer 4

Une note importante :

ngIf (contrairement à ngShow) crée généralement des scopes enfants qui peuvent produire des résultats inattendus.

J'ai eu 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 dans la mauvaise portée).

Donc, pour sauver vos cheveux, utilisez ngShow, sauf si vous courez 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 en faveur sans un test...

Answer 5

Ng-if sur ng-include et sur ng-controller aura un grand impact matière sur ng-include, il ne chargera pas le partiel requis et ne le traitera pas, sauf si le drapeau est vrai. sur ng-controller, il ne chargera pas le contrôleur sauf si le drapeau est vrai. mais le problème est que quand un drapeau devient faux dans ng-if il sera supprimé du DOM quand le drapeau redevient vrai il rechargera le DOM dans ce cas ng-show est mieux, pour un show unique ng-if est mieux