Kiedy można przechowywać obiekt na $ rootScope w AngularJS

Widzę wiele samouczków dotyczących uwierzytelniania, które umieszczają obiekt 'auth' na $ rootScope, w tym AngularFire-seed od osób FireBase.

Uważam, że umieszczanie obiektów na korzeniach było złym zwyczajem, a zamiast tego należy raczej stworzyć usługę. Dlaczego to (najwyraźniej) jest ok, jeśli chodzi o uwierzytelnianie? A może bardziej ogólne pytanie: kiedy jest ok, a może nawet dobra praktyka, aby umieścić coś na korzeniach?

Podać inny przykład. Mam dodatkowo obiekt profilu na użytkowniku. Czy można również dodać to do auth-obiektu? Nawet nie zanieczyszczam korzenia w tym przypadku, ponieważ obiekt autowy już tam jest. Czy można umieścić profil na rootcope w ten sposób (przez obiekt auth)? Jeśli nie, dlaczego?

wiem, było kilka pytań, ale wszystkie one sprowadzają się do jednego qeustion w tytule ...

Źródło

2014-04-11 EricC

NIE umieszczam całego obiektu auth/session w rootScope. Wolę mieć kontroler poziomu aplikacji podłączony do , który zapewnia metody zasięgu, które wywołują usługę, która zawiera dane auth. W ten sposób jest on nadal w zasadzie "globalny", ale nie jest w rootScope. Biorąc pod uwagę, że klient ma już całą aplikację, nie jest tak naprawdę lepiej czy bezpieczniej, koniecznie mieć rzeczy w usłudze vs rootScope, myślę, że sprowadza się to do miejsca i sposobu uzyskania dostępu do danych. Umieszczenie rzeczy w rootScope sprawia, że są one globalnie dostępne z Twoich widoków. – aet

Jeśli dane są naprawdę wspólne dla wszystkich zakresów, to $ rootScope jest idealnym miejscem do umieszczenia tych danych. – mccainz

Nice rootScope-altnerative @aet. Prawdopodobnie nie skorzystam z tego, ale dobrze jest wiedzieć o alternatywach. – EricC

Najprawdopodobniej ze względu na sposób prototypowego dziedziczenia działa w JavaScript.

Na przykład: klient potrzebuje poświadczeń uwierzytelniających w całej aplikacji, co jest lepszym miejscem niż $rootScope? (z wyjątkiem tego, jeśli chcesz go w usłudze i wstawić tę usługę do wszystkich artefaktów). Działa to jak ASPECT, aby zaadresować funkcjonalność przenoszenia danych uwierzytelniających. Dodając dane związane z auth w $rootScope, można łatwo uzyskać szczegóły uwierzytelniania z dowolnego scope, który najwyraźniej dziedziczy po $rootScope (z powodu prototypowego dziedziczenia).

To jest dobre dla dyrektyw nie z izolowanym lunetą, ale dla pojedynczego teleskopu i ściany do wspinaczki będą małe, ponieważ otrzymasz efektywny mechanizm 2-way binding.

Źródło

2014-04-11 18:43:02 dmahapatro

Dziękuję i dziękuję wszystkim za opinie :) Praktyczny wynik dla mnie polega na umieszczeniu obiektu auth/session na $ rootScope, ponieważ będzie on używany na prawie wszystkich stronach, ale mój obiekt-profilu, którego nie dodam do tego obiektu auth/session, ponieważ użyję go tylko na kilku stronach/widokach (w rzeczywistości będzie on widoczny na wszystkich stronach przez nagłówek (np. "Hi, EricC"), ale nagłówek jest pojedynczym szablonem). – EricC

Ktoś może zmienić nazwę zmiennej w bliższym zakresie, co może ukryć korzeńc. W zależności od tego, jak to działa, nie jest dobre dla dużych aplikacji. Ktoś będzie musiał wstrzyknąć wszędzie korzeń, aby uniknąć takich konfliktów, więc dlaczego nie zrobić globalnej usługi lub stałej zamiast? –

Istnieje pewny komentarz, aby nie zanieczyszczać korzeni. Ale nie dostałem żadnych szczegółów dotyczących tego, dlaczego nie powinniśmy zanieczyszczać korzeni i dlaczego tak się dzieje? –

Kiedy można przechowywać obiekt na $ rootScope w AngularJS

Odpowiedz

Powiązane problemy