재사용 가능한 상태 패턴(각도)

This series explores how we can keep our code declarative as we adapt our features to progressively higher levels of complexity.

레벨 4: 재사용 가능한 상태 패턴

상태를 관리하는 개체를 제거하면 어떤 일이 발생하는지 살펴보십시오.

export class ColorsComponent {
  adapter = createAdapter<string[]>({ // Added `createAdapter`
    changeColor: (colors, [newColor, index]: [string, number]) =>
      colors.map((color, i) => i === index ? newColor : color),
    selectors: {
      colors: state => state.map(color => ({
        value: color,
        name: color.charAt(0).toUpperCase() + color.slice(1),
      })),
    },
  });

  store = createStore('colors', ['aqua', 'aqua', 'aqua'], this.adapter);
}

이 간단한 변경으로 어떻게 더 많은 복잡성을 처리할 수 있는지 아십니까? 여러 독립적인 색상 목록에 대해 여러 상점을 쉽게 만들 수 있습니다.

  favoriteStore = createStore('colors.favorite', ['aqua', 'aqua', 'aqua'], this.adapter);
  dislikedStore = createStore('colors.disliked', ['orange', 'orange', 'orange'], this.adapter);
  neutralStore = createStore('colors.neutral', ['purple', 'purple', 'purple'], this.adapter);

StackBlitz

그것은 꽤 끔찍하지만 그것은 우리가 아니라 디자이너에게 있습니다.

NgRx가 엔티티 상태 관리자adapter를 호출하기 때문에 상태 관리자 객체entityAdapter를 호출했습니다.

NgRx/Entity은 NgRx의 고급 패턴으로 생각되지만 우리의 경우 색상 어댑터를 만드는 것이 colors의 상태를 설명하는 가장 최소한의 간단한 방법이었습니다. 먼저 인라인으로 정의했습니다. 최소한의 코드는 유연합니다.

모든 웹 앱은 결국 동일한 페이지에 동일한 유형의 상태에 대한 여러 인스턴스가 있는 지점까지 복잡성이 증가할 수 있습니다. 나는 그것을 몇 번 만났습니다. 매번 빨랐다. 우리는 단지 색상을 다루고 있지만 대규모 프로젝트에서 한 디자이너가 같은 페이지에 두 번째로 필터링되고 페이지가 매겨진 데이터 그리드를 추가하도록 했습니다. 갑자기 상태 관리 솔루션이 특정 사용자 이벤트, 특정 상태 인스턴스 및 상태 변경 및 파생된 상태에 대한 비즈니스 로직은 모두 함께 대규모 리팩토링 프로젝트가 되었습니다. 액션 페이로드는 변경되어야 했고 상태 객체는 더 깊게 중첩되어야 했습니다. 시간이 걸리고 코드를 더 추하고 이해하기 어렵게 만들었습니다.

상태 논리에 대해 상태 어댑터 이외의 것을 사용하는 것은 구문상 막다른 골목입니다. 다른 문제만큼 자주 발생하지 않을 수도 있지만 발생하며 일반적으로 예측할 수 없습니다. 따라서 어떤 상태 관리 라이브러리를 사용하든 관계없이 상태 로직을 함께 번들로 유지해야 하며 이벤트나 부작용 로직에 너무 밀접하게 연결되지 않아야 합니다. 개인적으로 어댑터 구문이 가장 좋다고 생각합니다.
createAdapter는 유형 유추를 제공하는 것으로 제가 구현한 것입니다. 구현하기는 매우 간단하지만 실제로 필요한 것은 상태 변경 기능과 선택기를 보유하는 객체뿐입니다. 이를 위해 라이브러리가 필요하지 않습니다.

다음으로 비동기 상태 소스에 대해 이야기하겠습니다.