2016-03-08 11 views
15

Załóżmy, że masz interfejs z paskiem narzędzi, bocznym i siatkowym. Pasek narzędzi zawiera menu rozwijane, w którym po zmianie użytkownika zmienia się zawartość paska bocznego i siatki. Po powrocie do Angular 1 użyłbym usługi, aby mieć wszystkie moje dynamiczne dane. Gdy coś zmieni się w usłudze, wszystkie składniki korzystające z tej usługi również zostaną zaktualizowane.Angular2 - udostępnianie danych/zmiana między komponentami

Cóż w Angular 2 wygląda na to, że ludzie używają różnych metod. Chciałem uzyskać twój wkład, który jest preferowany.

  • Static serwisowe
  • OnChanges
  • Wejścia i Wyjścia

Zaktualizowane - 03/09/16

Wygląda na to, że najlepszym rozwiązaniem jest wątek, który Thierry Templier wysłał: Delegation: EventEmitter or Observable in Angular2

Pozostało mi pytanie, czy najlepiej jest utworzyć nową usługę dla każdego elementu danych, który jest współużytkowany przez komponenty, czy też możemy mieć jedną usługę, która ma obiekt przechowujący wszystkie udostępnione dane.

See Plnkr for code 

Original Plunker - Każda zmiana będzie mieć swój własny serwis

Revised Plunker for example - Tylko jedna usługa, która przechowuje wszystkie dane w obiekcie. Typ zostanie przekazany do każdego detektora w celu sprawdzenia, czy musi on coś zrobić na podstawie tego typu.

+1

Inni warunkiem dobrych odpowiedzi, ale chciał, aby pamiętać, że istnieje punkt z dokumenty na temat [Component Interaction] (https://angular.io/docs/ts/latest/cookbook/component-communication.html), które ma y też warto przeczytać. – jandersen

Odpowiedz

21

Można Dźwignia Shared Service do tego. Może zawierać zarówno dane, jak i obserwowalne, aby subskrybować, aby otrzymywać powiadomienia, gdy dane są aktualizowane.

  • usługi

    export class ListService { 
        list1Event: EventEmitter<any> = new EventEmitter(); 
    
        getLists() { 
        return this.http.get(url).map(res => res.json()) 
         .subscribe(
         (data) => { 
          this.list1Event.emit(data.list1); 
         } 
        ); 
        } 
    } 
    
  • Komponent

    @Component({ 
        selector: 'my-component1', 
        template: ` 
        <ul> 
        <li *ngFor="#item of list">{{item.name}}</li> 
        </ul> 
        ` 
    }) 
    export class MyComponent1 { 
        constructor(private service:ListService) { 
        this.service.list1Event.subscribe(data => { 
         this.list = data; 
        }); 
        } 
    } 
    
  • bootstrap

    bootstrap(AppComponent, [ ListService ]); 
    

Zobacz to pytanie Więcej szczegółów:

+0

Doskonała odpowiedź, jednak jak zauważono na forum eventemitter-or-obserwowalnym, z którym się łączyłeś, wygląda na to, że lepszy jest sposób obserwowania. Wypróbuję to teraz i zobaczę, jak to działa dla mnie. –

2

W twoim przypadku użycia będę korzystać z usług. Usługi służą do przekazywania danych do innych komponentów. Jeden komponent mógłby zaktualizować te dane do usługi, a inny komponent mógłby z niego odczytać. Albo oba komponenty mogą po prostu z niego odczytać, a sam serwer pobiera dane z "zewnętrznego świata".

Używasz input do przekazywania danych z rodzica do dziecka i używasz output do wysyłania zdarzeń od dziecka do rodzica.

Używasz ngOnChanges do zrobienia czegoś, gdy coś się zmienia w samym komponencie, ale ja wolę używać do tego funkcji get() i set().

Przynajmniej takie jest moje spojrzenie na to :)

+0

Dziękuję za doskonały opis, kiedy należy korzystać z każdego z nich. To będzie bardzo przydatne w przyszłości. Mam zamiar zastosować podejście obserwowalne, wspomniane w wątku EventEmitter vs Observable, o którym wspomniał @Thiery. –

+0

Mam więc pytanie uzupełniające na temat twojego opisu, kiedy należy używać zdarzeń vs ngOnChanges. Załóżmy więc, że mam element nadrzędny, który używa współużytkowanej siatki childComponent. Przez współdzielenie rozumiem, że wiele innych komponentów używa tej siatki do wyświetlania własnych danych. Więc jeśli chcę, aby komponent macierzysty wywoływał funkcję wewnątrz tego potomka (siatki), ale tylko w tym przypadku nie wszystkie inne, czy NgOnChanges byłby najlepszym użytkiem dla tego przypadku? –

Powiązane problemy