앞서만든 Observer Pattern에는 문제점이있다. 만약 10명의 구독자가 100개의 신문사를 구독한다고 했을 경우, 구독 관련 코드가 기하급수적으로 늘어날 것이다.

앞서 작성한 코드를 리팩토링 해보자.

• 코드를 리팩토링 후 DOM에 적용해보자.

• 구조화를 해보자

• 고민해보자

  Component 내부에서 관리되는 State에 observable을 씌워 사용할 경우 만들 경우 setState를 사용하는 방식이랑 크게 다르지 않다고 느낄 수 있다. setState 또한 state가 변경될 때 마다 render를 실행하는 방식이기 때문이다.

  observer는 컴포넌트 상태에 사용하기 보다는 중앙 집중식 저장소를 관리할 때 매우 효과적이다.

• 컴포넌트 외부에 상태를 만들어 주기

  Vuex나 Redux 같은 프레임워크를 사용하기 전에, 매우 간단하게 Store를 만들어 관리해보자.

1. 최적화

   • 상태가 변경되어 render를 해야하는데, 만약 변경된 상태가 이전 상태와 값이 같을경우 다시 렌더링 되지 않도록 방어로직을 작성하자.

   • 상태가 연속으로 변경되는 경우 DOM으로 렌더링 되는 경우 requestAnimationFrame과 debounce를 이용하여 한 프레임에 한 번만 렌더링되도록 만들어줘야한다.

   requestAnimationFrame

   MDN 문서 (opens new window)에 나와있는 내용은 다음과 같다.

   브라우저에게 수행하기를 원하는 애니메이션을 알리고 다음 리페인트가 진행되기 전에 해당 애니메이션을 업데이트하는 함수를 호출하게 합니다. 이 메소드는 리페인트 이전에 실행할 콜백을 인자로 받습니다.

   화면에 새로운 애니메이션을 업데이트할 준비가 될때마다 이 메소드를 호출하는것이 좋습니다. 콜백의 수는 보통 1초에 60회지만, 일반적으로 대부분의 브라우저에서는 W3C 권장사항에 따라 그 수가 디스플레이 주사율과 일치하게됩니다.

   쉽게 말해서 requestAnimationFrame은 1프레임에 1회 호출된다. 보통 1초에 60프레임이고, 1프레임은 약 16ms 정도 된다.

2. Proxy

   • 사실 Object.defineProperty는 IE를 지원하기 위해 사용하는 API이다. 최신 브라우저에서는 Proxy (opens new window)를 이용한다면 더 쉽게 Observable을 만들 수 있다.

상당히 어렵다.. 이해하는데 시간이 필요했으며 돌아서면 금방 잊어버릴수 있으니 반복적으로 학습하도록 해야겠다.

참조 :

https://junilhwang.github.io/TIL/Javascript/Design/Vanilla-JS-Store/#_1-%E1%84%8C%E1%85%AE%E1%86%BC%E1%84%8B%E1%85%A1%E1%86%BC-%E1%84%8C%E1%85%B5%E1%86%B8%E1%84%8C%E1%85%AE%E1%86%BC%E1%84%89%E1%85%B5%E1%86%A8-%E1%84%89%E1%85%A1%E1%86%BC%E1%84%90%E1%85%A2%E1%84%80%E1%85%AA%E1%86%AB%E1%84%85%E1%85%B5