父子組件通訊：使用 ngOnChanges 和 @ViewChild 解決循環依賴

問題回顧：父子組件循環依賴

在投票系統專案中，我們遇到了一個循環依賴問題：

子組件接收父組件的輸入數據
用戶在子組件中進行選擇
子組件通知父組件（通過 @Output 事件）
父組件更新狀態並再次傳遞給子組件
引發不必要的重新渲染和計算，導致 UI 顯示錯誤

方案：使用 ngOnChanges 和 @ViewChild

原本是用 @Input set 來解決循環問題，後來改成這個方案。

基於以下兩個 Angular 核心功能：

ngOnChanges：監聽輸入屬性變化的生命週期鉤子
@ViewChild：讓父組件直接訪問子組件的引用

實現步驟

1. 子組件實現 OnChanges 接口

// option.component.ts
import { Component, Input, OnChanges, SimpleChanges, output } from '@angular/core';

@Component({
  selector: 'app-option',
  //...
})
export class OptionComponent implements OnChanges {
  // 輸入屬性
  @Input() voteRecords: VoteRecord[] = [];
  @Input() initialSelectedOptionId: string | null = null;
  
  // 本地狀態（使用 signal）
  selectedOptionId = signal<string | null>(null);
  localVoteRecords = signal<VoteRecord[]>([]);
  
  // 監聽輸入屬性變化
  ngOnChanges(changes: SimpleChanges): void {
    // 處理 voteRecords 變化
    if (changes['voteRecords'] && changes['voteRecords'].currentValue) {
      // 確保只在真正需要更新時才更新本地數據
      this.localVoteRecords.set(
        // 使用 map 處理數據，避免直接引用
        this.voteRecords.map((record) => ({
          ...record,
          user: { ...record.user },
        }))
      );
    }
    
    // 處理 initialSelectedOptionId 變化
    if (changes['initialSelectedOptionId']) {
      this.selectedOptionId.set(this.initialSelectedOptionId);
    }
  }
  
  // 其他方法...
}

2. 父組件使用 @ViewChild 訪問子組件

// event-detail.component.ts
import { Component, ViewChild, OnInit } from '@angular/core';
import { OptionComponent } from './components/option/option.component';

@Component({
  selector: 'app-event-detail',
  //...
})
export class EventDetailComponent implements OnInit {
  // 使用 ViewChild 獲取子組件引用
  @ViewChild(OptionComponent) optionComponent!: OptionComponent;
  
  // 移除 @Output 事件處理器
  // 原先的代碼：
  // onOptionSelected(event: { optionId: string; voteRecords: VoteRecord[] }) {
  //   this.userSelectedOptionId = event.optionId;
  // }
  
  // 使用子組件引用替代輸出事件
  onVote() {
    const pollId = this.eventData.id;
    // 直接從子組件獲取選中的選項 ID
    const optionId = this.optionComponent.selectedOptionId();
    
    if (pollId && optionId) {
      this.votingSystemService.userVote(pollId, optionId)
        .subscribe({
          // 處理成功和錯誤...
        });
    }
  }
  
  // 同樣對編輯投票使用相同模式
  onEditVote() {
    const pollId = this.eventData.id;
    const optionId = this.optionComponent.selectedOptionId();
    
    if (pollId && optionId) {
      this.votingSystemService.userEditVote(pollId, optionId)
        .subscribe({
          // 處理成功和錯誤...
        });
    }
  }
  
  // 其他方法...
}

核心變更摘要

移除循環通訊：父組件不再通過 @Input 回應子組件的事件
子組件使用 ngOnChanges：更精確地控制何時更新本地狀態
父組件使用 @ViewChild：直接訪問子組件的方法和屬性
直接數據流：保持單向數據流，避免不必要的循環

與其他方法的比較

特性

ngOnChanges + @ViewChild

@Input setter

effect

數據流向

單向 + 直接訪問

單向

可能導致循環

代碼複雜度

中等

低

高

封裝性

較弱（父組件可直接訪問子組件）

較強

循環依賴風險

低

高

性能

較好

好

較差

組件重用性

略受限

高

數據同步

明確控制

自動

自動但可能過度同步

方案優勢

性能高效：避免了不必要的渲染和計算循環
明確的數據流向：保持清晰的父子關係和數據流動方向
細粒度的變更控制：在 ngOnChanges 中可以精確控制對每個輸入屬性的響應
直接訪問：父組件可以直接獲取子組件的最新狀態
減少通訊開銷：減少了事件訂閱和處理的複雜度

方案缺點

組件耦合增加：父組件對子組件的實現細節有更多依賴
封裝性降低：子組件的內部狀態對父組件更加開放
生命週期管理：需要確保子組件初始化完成後才能使用 @ViewChild
代碼組織：可能導致父組件承擔更多職責
測試複雜性：父子組件更加緊密耦合，可能增加單元測試的複雜度

最佳實踐建議

明智選擇使用場景：
- 當父子組件關係緊密且需要大量雙向通訊時，考慮 ngOnChanges + @ViewChild
- 對於通用組件或需要良好封裝的組件，優先考慮 @Input setter
避免過度使用 @ViewChild：
- 限制父組件可以訪問的子組件方法和屬性
- 為子組件提供明確的公共 API
保持良好結構：
- 在 ngOnChanges 中組織清晰的輸入處理邏輯
- 避免在 ngOnChanges 中產生副作用
性能考量：
- 對於複雜的數據處理，考慮使用 trackBy 函數
- 避免在 ngOnChanges 中進行深度複製大型對象

結論

使用 ngOnChanges 和 @ViewChild 的組合提供了一種有效的方法來解決父子組件間的循環依賴問題。這種方法特別適合於緊密相關的組件，它們需要共享多種狀態但又要避免循環依賴帶來的問題。

在選擇解決方案時，需要權衡封裝性、性能和代碼組織等因素。不同的場景可能需要不同的方法，理解各種方法的優缺點將幫助你做出更明智的設計決策。

Previous與後端的時區處理 NextAngular Material Pagination 條件渲染

Last updated 5 months ago