Kiedy faworyzować ng-if kontra ng-show / ng-hide?

Rozumiem to ng-showi ng-hidewpływam na klasę ustawioną na elemencie, która ng-ifkontroluje, czy element jest renderowany jako część DOM.

Czy istnieją wytyczne dotyczące wybierania opcji ng-ifpowyżej ng-show/ ng-hidelub odwrotnie?

Zależy od przypadku użycia, ale podsumowując różnicę:

1. ng-ifusunie elementy z DOM. Oznacza to, że wszystkie twoje programy obsługi lub cokolwiek innego związane z tymi elementami zostaną utracone. Na przykład, jeśli powiążesz moduł obsługi kliknięć z jednym z elementów potomnych, gdy zostanie ng-ifoceniony wartość false, element ten zostanie usunięty z DOM, a twój moduł obsługi kliknięć nie będzie działał, nawet po ng-ifpóźniejszym sprawdzeniu wartości true i wyświetleniu elementu. Będziesz musiał ponownie podłączyć program obsługi.
2. ng-show/ng-hidenie usuwa elementów z DOM. Wykorzystuje style CSS do ukrywania / pokazywania elementów (uwaga: może być konieczne dodanie własnych klas). W ten sposób przewodnicy, którzy byli przywiązani do dzieci, nie zostaną utraceni.
3. ng-iftworzy zakres potomny, podczas gdy ng-show/ng-hidenie

Elementy, które nie znajdują się w DOM, mają mniejszy wpływ na wydajność, a Twoja aplikacja internetowa może wydawać się szybsza w użyciu w ng-ifporównaniu do ng-show/ng-hide. Z mojego doświadczenia wynika, że ​​różnica jest znikoma. Animacje są możliwe przy użyciu obu ng-show/ng-hidei ng-ifwraz z przykładami dla obu w dokumentacji Angular.

Ostatecznie pytanie, na które musisz odpowiedzieć, brzmi: czy możesz usunąć element z DOM, czy nie?

Zobacz tutaj CodePen, który pokazuje różnicę w działaniu ng-if / ng-show w DOM.

@markovuksanovic dobrze odpowiedział na pytanie. Ale ja się na to z innej perspektywy: Chciałbym zawsze używać ng-ifi dostać te elementy z DOM, chyba że:

1. z jakiegoś powodu potrzebujesz powiązań danych i $watch-es na swoich elementach, aby pozostały aktywne, dopóki są niewidoczne. Formularze mogą być dobrym przykładem, jeśli chcesz mieć możliwość sprawdzenia poprawności na wejściach, które nie są obecnie widoczne, w celu ustalenia, czy cały formularz jest prawidłowy.
2. Używasz naprawdę dopracowanej logiki stanowej z funkcjami obsługi zdarzeń warunkowych, jak wspomniano powyżej. To powiedziawszy , jeśli okaże się, że ręcznie dołączasz i odłączasz procedury obsługi, tak że tracisz ważny stan podczas korzystania z ng-if, zadaj sobie pytanie, czy stan ten byłby lepiej reprezentowany w modelu danych, a procedury obsługi stosowane warunkowo przez dyrektywy za każdym razem element jest renderowany. Innymi słowy, obecność / brak programów obsługi jest formą danych stanu. Pobierz te dane z modelu DOM i do modelu. Obecność / brak programów obsługi powinny być określone przez dane, a zatem łatwe do odtworzenia.

Angular jest napisany naprawdę dobrze. Jest szybki, biorąc pod uwagę, co robi. Ale to, co robi, to cała magia, która sprawia, że ​​trudne rzeczy (takie jak dwukierunkowe wiązanie danych) wyglądają banalnie łatwo. Sprawienie, by wszystkie te rzeczy wyglądały na łatwe, wiąże się z pewnym nakładem wydajności. Możesz być zszokowany, gdy zorientujesz się, ile setek lub tysięcy razy funkcja setera jest oceniana podczas $digestcyklu na kawałku DOM, na który nikt nawet nie patrzy. I wtedy zdajesz sobie sprawę, że masz dziesiątki lub setki niewidzialnych elementów, które robią to samo ...

Komputery stacjonarne mogą rzeczywiście być wystarczająco mocne, aby większość problemów z szybkością wykonywania JS była dyskusyjna. Ale jeśli pracujesz na urządzenia mobilne, używanie ng-if, gdy tylko jest to możliwe, powinno być proste. Szybkość JS nadal ma znaczenie dla procesorów mobilnych. Używanie ng-if jest bardzo łatwym sposobem na uzyskanie potencjalnie znaczącej optymalizacji przy bardzo, bardzo niskich kosztach.

Z mojego doświadczenia:

1) Jeśli twoja strona ma przełącznik, który używa ng-if / ng-show do pokazywania / ukrywania czegoś, ng-if powoduje większe opóźnienie przeglądarki (wolniej). Na przykład: jeśli masz przycisk służący do przełączania między dwoma widokami, ng-show wydaje się być szybszy.

2) ng-if utworzy / zniszczy zakres, gdy zostanie oceniony jako prawda / fałsz. Jeśli masz kontroler podłączony do ng-if, ten kod kontrolera będzie wykonywany za każdym razem, gdy ng-if zostanie ocenione jako prawda. Jeśli używasz ng-show, kod kontrolera zostanie wykonany tylko raz. Więc jeśli masz przycisk, który przełącza między wieloma widokami, użycie ng-if i ng-show miałoby ogromną różnicę w sposobie pisania kodu kontrolera.

Odpowiedź nie jest prosta:

To zależy od komputerów docelowych (mobilne vs stacjonarne), zależy od charakteru twoich danych, przeglądarki, systemu operacyjnego, sprzętu, na którym działa ... będziesz musiał przeprowadzić testy porównawcze, jeśli naprawdę chcesz wiedzieć.

Jest to głównie problem z pamięcią a obliczeniami ... ponieważ w przypadku większości problemów z wydajnością różnica może stać się znacząca w przypadku powtarzających się elementów (n), takich jak listy, szczególnie gdy są zagnieżdżone (nxn lub gorzej), a także rodzaj obliczeń wykonywanych w tych elementach :

• ng-show : Jeśli te opcjonalne elementy są często obecne (gęste), jak powiedzmy w 90% przypadków, może być szybsze ich przygotowanie i pokazywanie / ukrywanie, szczególnie jeśli ich zawartość jest tania (zwykły tekst, nic obliczać lub ładować). To zużywa pamięć, ponieważ wypełnia DOM ukrytymi elementami, ale po prostu pokaż / ukryj coś, co już istnieje, może być tanią operacją dla przeglądarki.

• ng-if : Jeśli przeciwnie, elementy raczej nie zostaną pokazane (rzadkie), po prostu je zbuduj i zniszcz w czasie rzeczywistym, szczególnie jeśli ich zawartość jest kosztowna (obliczenia / sortowane / filtrowane, obrazy, generowane obrazy). Jest to idealne rozwiązanie dla rzadkich lub „na żądanie” elementów, oszczędza pamięć pod względem niewypełniania DOM, ale może kosztować dużo obliczeń (tworzenie / niszczenie elementów) i przepustowości (uzyskiwanie zdalnej zawartości). Zależy to również od tego, ile obliczasz w widoku (filtrowanie / sortowanie) w porównaniu z tym, co już masz w modelu (dane wstępnie posortowane / wstępnie odfiltrowane).

Jedna ważna uwaga:

ngIf (w przeciwieństwie do ngShow) zwykle tworzy zakresy potomne, które mogą dawać nieoczekiwane wyniki.

Miałem z tym problem i spędziłem DUŻO czasu, aby dowiedzieć się, co się dzieje.

(Moja dyrektywa zapisywała wartości modelu w niewłaściwym zakresie).

Aby zaoszczędzić włosy, użyj ngShow, chyba że biegniesz zbyt wolno.

Różnica w wydajności i tak jest ledwo zauważalna i nie jestem jeszcze pewien, kto jest na korzyść bez testu ...

ng-jeśli na ng-include i na ng-kontrolerze będą miały duży wpływ na ng-include, to nie załaduje wymaganej części i nie będzie przetwarzać, chyba że flaga jest prawdziwa na ng-kontrolerze, nie załaduje kontrolera, chyba że flaga jest prawda, ale problem polega na tym, że gdy flaga zostanie sfałszowana w ng - jeśli usunie się z DOM, gdy flaga wróci do stanu rzeczywistego, przeładuje DOM w tym przypadku ng-show jest lepszy, raz pokaże ng-jeśli jest lepszy

Jeśli użyjesz ng-show or ng-hide z treści (np. Miniatury z serwera) zostaną załadowane niezależnie od wartości wyrażenia, ale będą wyświetlane na podstawie wartości wyrażenia.

Jeśli użyjesz, ng-ifzawartość zostanie załadowana tylko wtedy, gdy wyrażenie ng-if będzie zgodne z prawdą.

Używanie ng-if jest dobrym pomysłem w sytuacji, gdy zamierzasz załadować dane lub obrazy z serwera i wyświetlać je tylko w zależności od interakcji użytkowników. W ten sposób ładowanie strony nie będzie blokowane przez niepotrzebne nowe zadania.