Angular: Setters vs ngOnChanges - 어느 것이 더 낫습니까?

이 게시물은 원래 Angular Bites에 게시되었습니다.

Angular 구성 요소의 속성 변경에 대한 알림을 받는 것은 일반적으로 두 가지 방법으로 수행됩니다.

속성에 세터 추가

ngOnChanges 수명 주기 후크 사용

그러나 ... 모범 사례가 있습니까?

이 논의는 최근 우리 코드베이스에서 표준 사례를 확립하려고 시도하는 동안 동료들과 함께 제기되었습니다. 우리는 어느 것이 더 나은지 이해하기 위해 객관적인 주장을 찾으려고 노력했습니다.

평소와 같이 대답은 시나리오에 따라 다릅니다.

스타일

스타일은 매우 주관적인 요소이지만 setter를 사용하는 것이 제가 가장 좋아하는 접근 방식입니다. 일반적인 시나리오를 살펴보겠습니다.

class MyComponent {
  private subject$ = new Subject<string>();

  @Input()
  set name(name: string) {
    this.subject$.next(name);
  }
}

간결하고 형식이 안전하며 Observables의 사용을 권장합니다. 싫어할 게 별로 없어, 임호.

하지만 게터를 추가할 수 없습니까?

예. Angular는 속성에서 getter를 호출하여 이전 값을 확인하지 않고 해당 값을 구성 요소의 논리적 보기에 저장합니다.

이런 일이 발생하는 소스 코드를 읽고 싶다면 check this out .

class MyComponent implements OnChanges {
  @Input() name: string;

  private subject$ = new Subject<string>();

  ngOnChanges(changes: SimpleChanges) {
    // changes.name.currentValue is typed as `any`
    this.subject$.next(changes.name.currentValue);
  }
}

반대로 ngOnChanges 수명 주기 후크는 그다지 좋지 않습니다(제 생각에는). 가장 중요한 것은 유형이 약하다는 것입니다.

또한 세터를 사용하면 일반적으로 코드가 덜 필요하므로 항상 좋은 점임을 언급할 가치가 있습니다.

성능

성능이 많이 바뀌나요? 처음에는 ngOnChanges가 Angular의 수명 주기 후크의 일부가 되어 속성이 변경되는 시기를 인식하는 것이 더 효율적일 것이라고 생각했습니다.

그러나 Angular는 바인딩이 새 인스턴스일 때만 속성을 변경한다는 것이 밝혀졌습니다. 물론 변경 감지가 OnPush 인 것을 고려하고 있습니다.

내 테스트에 따르면 성능 측면에서 더 좋은 방법은 없으며 어떤 방법을 사용할지 결정할 때 요인이 되어서는 안 됩니다.

다중 입력 다루기

여러 입력에 대한 변경 사항을 고려할 때 상황이 변경됩니다.

class MyComponent implements OnChanges {
  @Input() name: string;
  @Input() email: string;

  private username$ = new Subject<string>();

  ngOnChanges({ name, email }: SimpleChanges) {
    const username = name.currentValue || email.currentValue;
    this.username$.next(username);
  }
}

이 경우 한 번에 모든 입력을 받는 것이 매우 간단하고 간단합니다.

그러나 이러한 상황은 매우 드물고 때로는 코드 냄새의 징후이기 때문에 대부분의 시간에 세터를 사용하고 싶어할 것입니다.

하루가 끝나면 이 결정은 항상 귀하와 귀하의 팀의 선호 사항에 달려 있음을 기억하십시오.

이 게시물을 즐겼기를 바랍니다. 차오!