개인 프로젝트 진행 중 상태관리에 대한 고민과 상태변화에 따른 웹페이지의 동적 렌더링 방식을 개선하기 위해 디자인 패턴을 조사하고 적용해 보는 과정을 기록하려고 합니다. 그리고 적용 전, 후의 달라진 부분과 제가 느끼는 장단점을 다뤄보고자 합니다.
기존의 상태관리와 동적 렌더링의 큰 흐름
1. 상태관리 방식
특정 View를 구현하고 있는 Typescript 파일 전역에 state라는 객체를 선언해 그 안에서 필요한 상태들을 관리했습니다.
- currentPageNum: 페이지네이션을 위한 현재 페이지의 인덱스를 저장하는 상태
- currentField: 카테고리 탭의 기능을 위한 현재 카테고리의 인덱스를 저장하는 상태
- progressBarAnimationInstance: 애니메이션 중복을 막기 위한 애니메이션 인스턴스를 저장하는 상태
2. 함수와 상태들의 관계
3. 상태 변경과 리렌더링 흐름
이벤트 발생 -> 상태 변경 -> 리랜더링할 요소 제거 -> 리랜더링
개선의 필요성
1. 전역 스코프에 상태 관리
2. 상태 변경과 리렌더링 과정이 분리되지 않아 생기는 문제
왜 Observer Pattern를 선택했는가?
처음에는 Singleton Pattern을 사용해 보려고 했습니다. 왜냐하면 외부에 클래스의 인스턴스로 분리해 상태 관리하려 의도에 따라 하나의 뷰에서는 하나의 인스턴스를 이용해서 상태 관리할 수 있기 때문에 혹시나 생길 혼동을 막을 수 있기 때문입니다. 무엇보다 구현이 제일 쉬워보였습...
아쉽게도 Singleton Pattern은 진행 중인 프로젝트의 규모와 개선 의도에는 맞지 않았습니다. 개념적으로 하나의 인스턴스만 존재해 상태관리할 수 있게 하는 점은 적절하다고 생각했습니다. 그러나 진행 중인 프로젝트의 규모가 여러 파일에서 하나의 상태관리를 목적으로 하는 인스턴스를 여러 번 생성할 경우가 매우 희박하기에 Singleton Pattern의 본래 의도와 장점과 어긋난다고 생각했다. 그리고 상태관리와 동적렌더링의 과정을 모두 효율적으로 개선해 보고자 하는 의도에는 상태변화가 일어날 경우를 감지하고 구독한 함수를 실행해 주는 Observer Pattern이 적절하다고 생각했습니다.
Observer Pattern 적용 후 변화와 장점
Observer Pattern 적용 후 흐름 자체는 이벤트 발생 -> 상태 변경 -> 리랜더링할 요소 제거 -> 리랜더링으로 동일했습니다. 그리고 함수와 state의 관계 또한 달라지지 않았습니다. 그런데 흐름을 구조적으로 구분할 수 있게 되면서 몇 가지 장점이 존재했습니다.
상태 변경과 리렌더링 흐름
달라진 부분은 이벤트 핸들러의 콜백 안에서 각각의 스텝을 담당하는 함수들이 순서가 섞여 문제가 생길 가능성 존재 했는데, 구조적으로 분리하니 이런 문제가 방지가 가능해졌습니다.
이벤트 발생 -> 상태 변경부분: 이벤트 핸들러에 콜백으로 등록 및 이벤트 발생 시 실행리랜더링할 요소 제거 -> 리랜더링부분: Observer 인스턴스에 구독해 상태변화 감지 시 실행
그리고 더불어 기존에는 콜백 자체에서 순환적으로 다른 함수들을 부르다 보니 그 흐름이 직관적으로 파악하기 힘들어 기능구현이나 디버깅에 어려움이 있었는데 이를 개선 가능했습니다.
