[기술적 의사 결정 과정] 위젯 에디터 스타일 테마 설정의 상태 관리

[iamheroine]

에디터 스타일 테마 설정 상태 관리

🤔테마 정의 위치?

다른 디렉토리에서는 사용할 일이 없을 것 같아 shared에 만들지 않고 해다 기능을 사용하는 www에 작성했다.

🤔전역 상태 관리가 필요한가?

props-drilling으로 처리하는 것보다 전역 상태 관리해주는 것이 적합한 선택인 지 알아보자.

문제점

1. 통상적인 props-drilling의 복잡성
   • 여러 계층의 컴포넌트를 통해 테마 정보를 전달해야 할 때 코드가 지저분해지고 유지보수가 어려움
   • 컴포넌트 계층이 깊어질수록 불필요한 props 전달 발생
2. 상태 동기화 문제
   • localStorage에 테마를 저장했다가 가져올 때, 상태 동기화 문제가 발생 가능
   • 컴포넌트가 로드되기 전에 테마를 가져와야 하므로 비동기 초기화 로직 필요
3. 다른 컴포넌트에서 실시간 테마 변경 반영 문제
   • props-drilling만으로는 테마 변경 시 모든 컴포넌트에 즉각 반영이 어려움

🤔그렇다면 전역 상태 관리는 무엇으로?

에디터의 테마 상태를 생성된 위젯들과 공유하기 위해 전역 상태 관리가 필요해졌다. 컬러, 폰트, 텍스트 사이즈 정도만 공유하면 되기 때문에 간단한 상태 관리 툴을 사용하려고 한다.

Zutand와 Context API를 두 가지 중 어떤 것이 적합할 지 비교해보았다.

기준	Context API	Zustand
React 통합	React 내장 기능, 별도 설치 불필요	외부 설치 필요
상태 디버깅	React DevTools로 디버깅 용이	React DevTools에서 덜 직관적
상태 범위 제한	Provider로 상태 범위 제한 가능	Provider 없이 제한 없음
리렌더링 최적화	불필요한 리렌더링 발생 가능	잘 최적화됨
React 외부에서 상태 접근	어려움	가능
테스트 복잡성	복잡함	간단함
보일러플레이트 코드	적당함	최소화됨
미들웨어 지원	기본적으로 지원되지 않음	지원됨
라이브러리 의존성	외부 라이브러리 불필요	외부 의존성 있음

처음에는 아래와 같은 이유로 Context API를 사용하는 것을 먼저 고려했다.

• 테마 설정은 global state이지만, 상태 업데이트가 자주 일어나지 않을 것 같음
• Context API는 React 내장 기능으로, 추가 의존성 없이 간단한 전역 상태 관리가 가능
• 간단한 상태라 성능에 크게 민감하지 않은 작업으로 오버 헤드 발생을 줄이기 위함
• Provider에 담기지 않은 외부에서는 테마 상태 접근이 없을 것 같음

💡하지만 아래와 같은 이유로 Zustand를 사용하는 것으로 최종 결정했다.

• 테마 설정을 로컬스토리지에 저장하고 불러오는 기능 필요
• 다른 전역 상태들과 함께 관리됨
• 다른 컴포넌트들에서 불필요하게 리렌더링 발생 시 최적화를 위해 별도 처리 필요

특히나 해당 페이지는 다른 위젯들이 리렌더링 되게 하고 싶지 않았고, 새로고침 되어도 선택한 테마 상태가 달라지지 않아야 했기 때문에 Zustand를 사용하고자 한다.

[eunohhh]

확인했습니다! 저도 모달을 구현하면서 zustand 를 썼지만 이러한 의사 결정 과정을 정리하지 않았었는데, 이렇게 의사 결정 과정을 명확하게 정리해 주시니 좋은 것 같습니다. (저도 모달 구현시 같은 고민을 했던 것 같습니다!)