23.07.21(금)
하루 요약
- 10:30 ~ 16:00 : Gloddy 개발 & 상태 관리 공부
- 16:00 ~ 21:00 : Frontend 공부
- CSS
- frontend 스터디 준비 - DOM, Virtual DOM
- 전역 상태 관리 Library vs Context API
- Typescript - ComponentProps
Today I Worried
Funnel 패턴에서의 상태 관리
Slash 23 - 쏟아지는 페이지 한 방에 관리하기를 수강했다. 회원가입처럼 페이지를 넘어가며 정보를 수집할 때 상태 관리를 어떻게 하는 지에 대한 영상이었다. 이 영상을 내가 지금 프로젝트의 회원가입을 구현하기 전에 봤더라면 어떗을까.. 하는 생각이 들었다.
페이지가 다르니 당연히 page를 구분하고, page를 넘어갈 때 상태관리를 위해서는 localStorage나 전역 상태관리 라이브러리를 사용해야 한다고 생각했다. 이 영상을 보고 머리를 띵 맞은 기분이었다.
기존 방법을 떠올려 보면, 상태값을 서버에 넘겨주는 페이지는 하나인데 상태값을 관리하는 페이지는 여러 페이지이다. 하나의 목적을 위한 상태가 흩어져 있다는 점이 있다. 그리고, 페이지 흐름을 각 페이지에서 router.push()를 이용하여 페이지를 넘겨주어야 하여 페이지 흐름이 흩어져 있다는 점이 있었다. 이러한 점들이 모여 낮은 응집도를 가지고 있었다.
이러한 점들에 대한 고민을 토스도 하였는 지, 이에 대한 해결책을 제시하였다. 페이지를 page단위로 구분하는 것이 아니라, step이라는 상태값을 바꾸는 것이다. 전화번호 step > 이메일 step이런 식으로 말이다. 이렇게 하면, 상태값을 관리하는 페이지는 하나이고, 페이지 흐름도 한 곳에서 관리할 수 있게 된다. 입력값의 상태 관리는 Context API를 활용했다.
한 페이지에서 step상태값이 바뀌는 것이라면, 한 페이지이기 때문에 입력값의 상태 관리는 useState를 사용하면 되지 않을까? 라는 생각을 잠깐 했지만, 그렇게 되면 각 step별 컴포넌트가 다르기에 state, setState를 모든 컴포넌트에 넘겨주어야 한다. 이러한 불편한 점들을 해결해줄 수 있는 것이 Context API라는 점을 깨달았다.
내가 평소에 짰던 코드들이 떠오르며, 무분별하게 전역 상태 관리 라이브러리를 사용하고, state, setState를 props로 넘겨주었던 기억들이 떠올랐다. 이러한 점들을 꼭 리팩토링을 통해 개선해야겠다는 생각이 들었다.
어제 주혁님이 알려준 링크인데, 이 Slash의 useFunnel패턴을 활용한 프로젝트이다.
Context API vs 전역 상태 관리 라이브러리
그렇다면, 언제 Context API를 쓰고, 언제 전역 상태 관리 라이브러리를 써야 할까?
JBEE님은 테마, 다국어 처리 처럼 전역에서 사용하는, 모든 컴포넌트에 변화가 생기는 상태만 전역 상태로 관리해야 한다고 이야기하신다. 너무 극단적인 의견 아닐까?
그렇다면, Context API는 전역 상태 관리 툴이 아닐까? Context API는 컴포넌트 트리 안에서 전역 상태를 공유할 수 있는 것으로, Provider로 감싼 컾모넌트 안에서만 context를 사용이 가능하다. 이는 종속성을 주입하기 위한 도구이기에 전역 상태 툴이라기엔 다소 에매한면이 있다.
Context API는 Context 값이 변경되면 해당 값이 useContext를 사용하는 컴포넌트가 모두 렌더링이 일어난다는 치명적인 단점이 있다. 이에 Context API를 되도록이면 쓰되, 복잡한 상태 관리는 서드파티 전역 상태 라이브러리를 사용하면 좋을 것 같다. 앞으로 이러한 점들을 고민하며 상태 관리를 짜보도록 하자.