Best Practice für winkelförmige 2-Komponenten

Question

Ich habe eine Anwendung mit einem Benutzerobjekt, in dem alle Benutzerinformationen gespeichert sind und mit einer Observable aktualisiert werden, die von userService angegeben wird. Nun frage ich mich, was ist die beste Praxis für die Verwendung dieses Benutzers mit Komponenten beobachtbar?

Ich habe eine Seite (TestPage) mit einer Kalenderkomponente (Kalender). Der Kalender verwendet das Benutzerobjekt, weil es wissen muss, dass es die Wochenansicht oder die Monatsansicht anzeigt.

Option 1: Die erste Option ist eine beobachtbare in der Testseite zu erstellen und gibt das Benutzer-Objekt mit einer Eigenschaft und dann im Kalender, wird es den Nutzer @input.

Testseite Typoskript-Datei:

export class TestPage { 
    private user: User; 
    private userSubscription: Subscription; 

    constructor(private usersService: UsersService) { 
     this.log('constructor'); 
     this.userSubscription = this.usersService.$currentUser.subscribe((user: User) => { 
      this.log('$currentUser: user update', user); 
      this.user = user; 
     }); 
    } 

    ngOnDestroy(): void { 
     this.log('ngOnDestroy: unsubscribing userSubscription'); 
     this.userSubscription.unsubscribe(); 
    } 
} 

Testseite html:

<flex-calendar [user]="user"></flex-calendar>

Kalender:

export class Calendar { 
    @Input() user: User; // Got the user from the TestPage 
} 

Option 2: ein OB erstellen Servable in der TestPage und im Kalender. Diese Option hat den Vorteil, dass der Kalender weniger Verbindung mit der Seite hat.

Kalender:

export class Calendar { 
    private user: User; 
    private userSubscription: Subscription; 

    constructor(private usersService: UsersService) { 
     this.log('constructor'); 
     this.userSubscription = this.usersService.$currentUser.subscribe((user: User) => { 
      this.log('$currentUser: user update', user); 
      this.user = user; 
     }); 
    } 

    ngOnDestroy(): void { 
     this.log('ngOnDestroy: unsubscribing userSubscription'); 
     this.userSubscription.unsubscribe(); 
    } 
} 

Kann jemand erklären, was die beste Option wäre, und warum?

Answer 1

Eine alternative Option, die ich einige Male erfolgreich verwendet habe, ist die Übergabe einer Konfigurationsklasse/eines Objekts, das eine Rückruffunktion enthalten kann. Auf diese Weise erhalten Sie das Beste aus beiden Welten; Die Kalenderkomponente kann den Dienst direkt abonnieren und trotzdem dumm bleiben.

Es würde wie folgt aussehen:

Testseite

----Template---- 
<flex-calendar [calendarCallback]="calendarCallback"></flex-calendar> 

----TS---- 
export class TestPage implements OnInit { 
    private calendarCallback: Function; 
    private userSubscription: Subscription; 

    constructor(private usersService: UsersService) { 
     this.log('constructor'); 
    } 

    ngOnInit(): void { 
     this.calendarCallback = this.getUser.bind(this); 
    } 

    getUser(){ 
     let currentUser = new Subject<User>(); 
     this.usersService.$currentUser 
      .subscribe(
       (user: User)=> { 
        this.log('$currentUser: user update', user); 
        currentUser.next(user); 
       } 
      ); 
     return currentUser.asObservable(); 
    } 
} 

Kalender

----TS---- 
export class Calendar implements OnInit{ 
    private calendarCondition; 
    @Input("calendarCallback") calendarCallback; 

    getCalendarDependancy(){ 
     this.calendarCallback.subscribe(
      (result) => { 
       this.calendarCondition = result; 
      } 
     ) 
    } 
} 

Es ist am besten, wie Chandermani angegeben, zu halten Komponenten so dumm wie möglich .Der Hauptvorteil dieses Ansatzes besteht darin, dass die Kalenderkomponente nicht länger von der übergeordneten Komponente abhängig ist, um das Ergebnis der Subskription bereitzustellen, was im vorliegenden Beispiel kein Problem darstellt, sondern möglicherweise zu einer solchen werden kann Nachschlagen wird innerhalb der Kalenderkomponente selbst ausgelöst (z. B. beim Klicken).

Grüße

Answer 2

Ich glaube, die erste Option ist besser als die zweite Option wie bei der ersten Option sind die Abhängigkeiten explizit und nur die Komponente ist nur abhängig vom Eingabemodell. Solange die Eingabe bereitgestellt werden kann die Kalenderkomponente überall verwendet werden. Die Kalenderkomponente fungiert eher als eine dumme Komponente.

Suchen Sie über die intelligente und dumme Komponente Muster, um eine bessere Idee zu erhalten, wie Komponenten für komplexe UI entworfen werden können.