Hej Rafał, w tym pierwszym przypadku (określonym jako niepoprawny) wystarczyłoby sprawdzić w showDetails() czy zmienna this.myArr nie jest pusta i osiągnęlibyśmy poprawne działanie, takie jak w przpadku użycia ngOnChanges(). Wynika to z tego, że przy użyciu setterow dane splywaja sekwencyjnie, w przypadku ngOnChanges() parametry wlatują do komponentu hurtowo.
Wydaje mi się, że taki dodatkowy warunek niepotrzebnie komplikuje kod. Wiadomo że jeden if nic złego nie wyrządzi, ale może być drogą do wprowadzania w projekcie niepoprawnych standardów tworzenia kodu. Chociaż jak deadline'y gonią, to się przymyka oko, żeby nie tracić czasu na główkowanie jak coś ładniej napisać. 😅
No właśnie tak musi być jak napisałeś. Ja preferuję rozwiązanie oparte na ngOnChanges. Ifologia jest jakimś rozwiązaniem, ale to dodatkowy kod, który trzeba później czytać, ogarnąć itd. Uważam, że najważniejsze z tego odcinka jest to, że taka sytuacja istnieje i trzeba mieć tego świadomość. I oczywiście w konsekwencji zabezpieczyć się właściwie. Wielkie dzięki za głos w dyskusji.
A jeżeli chcemy w Inpucie zasubskrybować Observable albo Subjecta (konstrukcja z async pipem w Html-u), to czy musimy o czymś pamiętać gdy odwołujemy się do tych danych w setterze lub w ngOnChanges? Czy postępujemy analogicznie jak gdybyśmy odwoływali się do zwykłych, nieasynchronicznych danych? PS: fajne i pomocne filmy. ☺️
Tak jak pokazałeś, można przecież też przekazać obserwera i normalnie użyć na nim async pipe, wszystko będzie śmigało o ile o to chodzi komentującemu :)@@rafalkoduje
Jak zawsze fajny materiał :) z tą zamianą kolejności input to nie spodziewałem się ze ze to tak może zadziałać :)
Tak to działa, żadnego fotomontażu nie było:)
Hej Rafał, w tym pierwszym przypadku (określonym jako niepoprawny) wystarczyłoby sprawdzić w showDetails() czy zmienna this.myArr nie jest pusta i osiągnęlibyśmy poprawne działanie, takie jak w przpadku użycia ngOnChanges(). Wynika to z tego, że przy użyciu setterow dane splywaja sekwencyjnie, w przypadku ngOnChanges() parametry wlatują do komponentu hurtowo.
Wydaje mi się, że taki dodatkowy warunek niepotrzebnie komplikuje kod. Wiadomo że jeden if nic złego nie wyrządzi, ale może być drogą do wprowadzania w projekcie niepoprawnych standardów tworzenia kodu. Chociaż jak deadline'y gonią, to się przymyka oko, żeby nie tracić czasu na główkowanie jak coś ładniej napisać. 😅
No właśnie tak musi być jak napisałeś. Ja preferuję rozwiązanie oparte na ngOnChanges. Ifologia jest jakimś rozwiązaniem, ale to dodatkowy kod, który trzeba później czytać, ogarnąć itd. Uważam, że najważniejsze z tego odcinka jest to, że taka sytuacja istnieje i trzeba mieć tego świadomość. I oczywiście w konsekwencji zabezpieczyć się właściwie. Wielkie dzięki za głos w dyskusji.
@@rafalkoduje dokładnie 🙂 też wolę ngOnChanges(), im mniej kodu tym lepiej.
A jeżeli chcemy w Inpucie zasubskrybować Observable albo Subjecta (konstrukcja z async pipem w Html-u), to czy musimy o czymś pamiętać gdy odwołujemy się do tych danych w setterze lub w ngOnChanges? Czy postępujemy analogicznie jak gdybyśmy odwoływali się do zwykłych, nieasynchronicznych danych?
PS: fajne i pomocne filmy. ☺️
Robisz to normalnie i będzie działać ;)
Normalnie, czyli inaczej niż pokazałem?
Tak jak pokazałeś, można przecież też przekazać obserwera i normalnie użyć na nim async pipe, wszystko będzie śmigało o ile o to chodzi komentującemu :)@@rafalkoduje
@@devman5813 Dzięki, o to chodziło.
devman5813 jest mega master :)
fajny kanał, szkoda tylko ze angular. aktualnie ucze sie vue ;/ beda w przyslosci odcinki dla innych freamworkow?
raczej nie planuję. Ale cieszę się z dobrej oceny :)