Wann bevorzugst du ng-if gegenüber ng-show/ng-hide?

Question

Ich verstehe, dass ng-show und ng-hide die Klasse eines Elements beeinflussen und dass ng-if steuert, ob ein Element als Teil des DOM gerendert wird.

Gibt es Richtlinien zur Auswahl von ng-if gegenüber ng-show/ng-hide oder umgekehrt?

Answer 1

Je nach Anwendungsfall unterscheidet sich das Zusammenfassen des Unterschieds folgendermaßen:

1. ng-if entfernt Elemente aus dem DOM. Das bedeutet, dass alle Handler oder andere an diese Elemente angehängte Funktionen verloren gehen. Zum Beispiel, wenn Sie einen Klick-Handler an ein Kindelement gebunden haben, wird dieses Element aus dem DOM entfernt, wenn ng-if zu false evaluiert wird, und Ihr Klick-Handler wird nicht mehr funktionieren, auch nachdem ng-if später zu true evaluiert und das Element angezeigt wird. Sie müssen den Handler erneut anhängen.
2. ng-show/ng-hide entfernt die Elemente nicht aus dem DOM. Es verwendet CSS-Stile, um Elemente ein-/auszublenden (Hinweis: Möglicherweise müssen Sie Ihre eigenen Klassen hinzufügen). Auf diese Weise gehen Ihre Handler, die an Kinder angehängt waren, nicht verloren.
3. ng-if erstellt einen Kindbereich, während ng-show/ng-hide das nicht tut

Elemente, die sich nicht im DOM befinden, haben weniger Leistungseinfluss und Ihre Web-App könnte schneller erscheinen, wenn Sie ng-if im Vergleich zu ng-show/ng-hide verwenden. In meiner Erfahrung ist der Unterschied jedoch vernachlässigbar. Animationen sind möglich, wenn sowohl ng-show/ng-hide als auch ng-if verwendet werden, mit Beispielen für beide im Angular-Dokumentation.

Letztendlich müssen Sie die Frage beantworten, ob Sie ein Element aus dem DOM entfernen können oder nicht?

Answer 2

Siehe hier für einen CodePen, der den Unterschied in der Arbeitsweise von ng-if/ng-show, DOM-weise, zeigt.

@markovuksanovic hat die Frage gut beantwortet. Aber ich würde es aus einem anderen Blickwinkel angehen: Ich würde immer ng-if verwenden und die Elemente aus dem DOM entfernen, es sei denn:

1. du aus irgendeinem Grund die Datenbindungen und $watch-es an deinen Elementen aktiv halten möchtest, während sie unsichtbar sind. Formulare könnten ein gutes Beispiel dafür sein, wenn du die Gültigkeit von Eingaben überprüfen möchtest, die derzeit nicht sichtbar sind, um festzustellen, ob das gesamte Formular gültig ist.
2. Du verwendest eine wirklich aufwendige zustandsbehaftete Logik mit bedingten Ereignishandlern, wie oben erwähnt. Das gesagt, wenn du feststellst, dass du Ereignishandler manuell anbringst und entfernst, sodass du wichtige Zustandsinformationen verlierst, wenn du ng-if verwendest, frage dich, ob dieser Zustand besser in einem Datenmodell repräsentiert würde und die Handler bedingungsweise von Direktiven angewendet werden, wann immer das Element gerendert wird. Mit anderen Worten, die Anwesenheit/Abwesenheit von Handlern ist eine Art Zustandsdaten. Holen Sie diese Daten aus dem DOM und in ein Modell. Die Anwesenheit/Abwesenheit der Handler sollte durch die Daten bestimmt werden und somit einfach wiederherzustellen sein.

Angular ist wirklich gut geschrieben. Es ist schnell, wenn man bedenkt, was es tut. Aber was es tut, ist eine Menge Magie, die schwierige Dinge (wie die 2-Wege-Datenbindung) trivial einfach aussehen lässt. Das einfache Aussehen all dieser Dinge bedeutet einen gewissen Leistungsüberkopf. Du könntest schockiert sein, wenn du realisierst, wie oft eine Setter-Funktion während des $digest-Zyklus auf einem Stück DOM ausgewertet wird, auf das niemand schaut. Und dann realisierst du, dass du Dutzende oder Hunderte unsichtbare Elemente hast, die alle dasselbe tun...

Desktops sind vielleicht leistungsstark genug, um die meisten JS-Ausführungsprobleme zu vernachlässigen. Aber wenn du für mobile Geräte entwickelst, sollte die Verwendung von ng-if wo immer möglich eine Selbstverständlichkeit sein. Die Geschwindigkeit von JS spielt auf mobilen Prozessoren immer noch eine Rolle. Die Verwendung von ng-if ist ein sehr einfacher Weg, um potenziell signifikante Optimierungen zu sehr, sehr geringen Kosten zu erhalten.

Answer 3

Aus meiner Erfahrung:

1) Wenn Ihre Seite einen Schalter hat, der ng-if/ng-show verwendet, um etwas ein- oder auszublenden, verursacht ng-if eine längere Browserverzögerung (langsamer). Zum Beispiel: Wenn Sie einen Button haben, der zwischen zwei Ansichten umschaltet, scheint ng-show schneller zu sein.

2) ng-if wird den Scope erstellen/zerstören, wenn es zu true/false ausgewertet wird. Wenn Sie einen Controller an den ng-if angehängt haben, wird dieser Controller-Code jedes Mal ausgeführt, wenn das ng-if zu true ausgewertet wird. Wenn Sie ng-show verwenden, wird der Controller-Code nur einmal ausgeführt. Wenn Sie also einen Button haben, der zwischen mehreren Ansichten umschaltet, würde es einen großen Unterschied machen, ob Sie ng-if und ng-show verwenden und wie Sie Ihren Controller-Code schreiben.

Answer 4

Die Antwort ist nicht einfach:

Es hängt von den Zielmaschinen ab (Mobilgeräte vs. Desktops), es hängt von der Art Ihrer Daten ab, dem Browser, dem Betriebssystem, der Hardware, auf der es läuft... Sie müssen Benchmarking durchführen, wenn Sie es wirklich wissen wollen.

Es handelt sich größtenteils um ein Speicher- vs. Berechnungsproblem ... wie bei den meisten Leistungsproblemen kann der Unterschied bei wiederholten Elementen (n) wie Listen, insbesondere wenn sie verschachtelt sind (n x n oder schlimmer) und auch welche Art von Berechnungen Sie innerhalb dieser Elemente durchführen:

• ng-show: Wenn diese optionalen Elemente häufig vorhanden sind (dicht), wie zum Beispiel 90% der Zeit, kann es schneller sein, sie bereitzuhalten und nur anzuzeigen/auszublenden, insbesondere wenn ihr Inhalt günstig ist (nur einfacher Text, nichts zu berechnen oder laden). Dies verbraucht Speicherplatz, da es den DOM mit ausgeblendeten Elementen füllt, aber nur etwas anzuzeigen/auszublenden, das bereits vorhanden ist, ist wahrscheinlich eine kostengünstige Operation für den Browser.

• ng-if: Wenn dagegen Elemente wahrscheinlich nicht angezeigt werden (spärlich), bauen Sie sie einfach auf und zerstören Sie sie in Echtzeit, insbesondere wenn ihr Inhalt teuer zu erhalten ist (Berechnungen/Sortieren/Filtern, Bilder, generierte Bilder). Dies ist ideal für seltene oder "auf Anfrage" Elemente, es spart Speicherplatz, indem es den DOM nicht füllt, kann aber viel Berechnungen kosten (Erstellen/ Zerstören von Elementen) und Bandbreite (remote Inhalte abrufen). Es hängt auch davon ab, wie viel Sie in der Ansicht berechnen (Filtern/Sortieren) im Vergleich zu dem, was Sie bereits im Modell haben (vor-sortierte/vor-gefilterte Daten).

Answer 5

Eine wichtige Anmerkung:

ngIf (im Gegensatz zu ngShow) erstellt in der Regel Kindbereiche, die zu unerwarteten Ergebnissen führen können.

Ich hatte ein Problem damit und habe VIEL Zeit damit verbracht, herauszufinden, was los war.

(Meine Direktive schrieb ihre Modelwerte in den falschen Bereich.)

Also, um Ihre Haare zu retten, verwenden Sie einfach ngShow, es sei denn, Sie laufen zu langsam.

Der Leistungsunterschied ist sowieso kaum spürbar, und ich bin mir noch nicht sicher, auf wessen Seite es ohne einen Test ist...