2016-04-29 19 views
9

Po prostu mam głowę wokół kątowej 2 i patrząc na projektowanie typu aplikacji kreatora. Komponenty na stronie 1 muszą przekazywać dane do komponentów na innych stronach. Myślenie o używaniu usługi do utrzymywania stanu/danych, które jest wstrzykiwane w następnym widoku/komponencie kreatora. Całość powinna być luźno powiązana. Nie sądzę, że warto zaprojektować możliwy do zaobserwowania wzór, ponieważ komponent znajdujący się na jednej z kolejnych stron/widoków nie jest jeszcze widoczny. Jakie nowe funkcje w kancie 2 mogą zostać użyte do rozwiązania tego problemu?Jak zachować stan w kanciastym 2?

+0

Proszę dodać trochę kodu, który pokazuje, co próbujesz osiągnąć. Angular dostarcza '@Input()', '@Output()' dla rodzicielskich relacji podrzędnych (w pewnym stopniu dla rodzeństwa) i usług dla wszystkich innych. –

+0

co ze starymi dobrymi parametrami przekazywania z jednej trasy do drugiej? – smnbbrv

+0

Możesz użyć usługi z 'BehaviorSubject RxJS', aby zachować pewność, że składniki, które nie są jeszcze widoczne, uzyskają najnowsze dane podczas inicjalizacji. https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/subjects/behaviorsubject.md – Harry

Odpowiedz

5

Sprawdź @ngrx/store

RxJS zasilany zarządzanie stan inspirowany Redux dla Angular2 aplikacje

7

Sugeruję utrzymanie centralnego stanu przy użyciu na przykład Redux. Następnie używałbyś @Input() i @Output() kątowej, aby propagować twój stan do komponentów i wywoływać zmiany stanu ze składników.

Użytkownik powinien mieć komponent najwyższego poziomu, który subskrybuje zmiany stanu i propagować te elementy przy użyciu komponentu potomnego @Inputs. Komponenty podrzędne będą wysyłały żądania zmian stanu za pomocą funkcji @Outputs() do komponentu najwyższego poziomu, który z kolei aktualizuje stan centralny.

W ten sposób twój indywidualny komponent nie musi wiedzieć nic o przechowywaniu i aktualizacji stanu, po prostu zapewnia funkcjonalność i akceptuje parametry wejściowe, które mogą mieć pożądany wpływ na ich funkcjonalność.

Jeśli masz wiele głęboko zagnieżdżonych komponentów, oni również używają funkcji @Input() i @Output() w celu zapewnienia funkcjonalności i nie komunikują się bezpośrednio z żadnym magazynem stanów.

Używam tej metody, która sprawia, że ​​każdy komponent jest bardzo chudy i nadaje się do wielokrotnego użytku, jednocześnie ułatwiając śledzenie stanu i redukując złożoność synchronizacji stanu między komponentami.

Powinieneś dodatkowo zapoznać się z ChangeDetectionStrategy i ChangeDetectorRef, ponieważ możesz uprościć wykrywanie zmiany komponentu za pomocą tej metody. Wszystkie komponenty potomne mogą na ogół korzystać ze strategii nazywanej "Sprawdzaniem na bieżąco", co oznacza, że ​​ich wykrywanie zmian będzie uruchamiane tylko po zmianie właściwości @Input(). Ponieważ jest to jedyny sposób, w jaki zmienia się stan, w tym przypadku możesz powiedzieć kątowy, a nie sprawdzić zmiany w przeciwnym razie. Pomoże to również w osiągach.

Zauważ, że możesz zachować stan przy użyciu zwykłej usługi angular2, ale coś takiego jak Redux daje ci pewne rzeczy za darmo, jak na przykład dostarczone narzędzia deweloperskie. Jeśli używasz Redux, zajrzyj również na Immutable.js, ponieważ ważne jest, aby nie mutować stanu bezpośrednio za pomocą Redux.

+0

Dzięki, to miłe podejście! W przypadku głęboko zagnieżdżonych komponentów potomnych, w jaki sposób zmienia się stan z powrotem do komponentu najwyższego poziomu z "głównym" stanem widoku/aplikacji? Czy masz łańcuch wyjść wychodzących na szczyt, czy też istnieje skrót, który może być użyty do ominięcia tego rodzaju łańcuchów? – Janne

+1

Ogólnie rzecz biorąc, masz łańcuch wyjść wychodzących na szczyt.Jeśli robi się zbyt zagnieżdżony, aby wygodnie pracować, warto zastanowić się nad podziałem odpowiedzialności komponentu najwyższego poziomu na więcej niż jeden komponent, który manipuluje i subskrybuje różne obszary scentralizowanego stanu. – jgranstrom

+1

Muszę jeszcze w pełni zrozumieć najlepszą praktykę i/lub sposób, w jaki "chce" mnie to zrobić. W przeważającej części polegałem na wielu wynikach wejść, ale ostatnio zdałem sobie sprawę, że mogę dodać pewne właściwości do usługi i wstrzyknąć ją do składników, których potrzebuję, aby zapisać stan z/między. Usługa zasadniczo jest bardziej "scentralizowanym sklepem" - może to właśnie robi Redux, po prostu bardziej wyrafinowana? Albo nie? Czy jest jakiś problem z moim podejściem do korzystania z usług i polegać na DI zamiast wielu wejść/wyjść. Po prostu łatwiej jest wstrzyknąć usługę. – JzInqXc9Dg

Powiązane problemy