0910 Context API는 상태관리 툴이 아니다

곽민규

저는 최근에 비즈니스로직을 거의 모두 Context API에 몰아넣는 패턴을 자주 사용했었는데요, 저번 주말에 개발자 친구들이랑 술마시면서 얘기하다가 Context API의 단점을 듣고 나서 곰곰히 생각해보니까 그간 무지성으로 Context API에 짬때리던 관성을 반성하게 되었습니다. 물론 Context API 안에 있는 로직들이 사실상 상태들과 굉장히 강하게 결부돼있어서 Context API 내부에서 관리하는게 맞아 추가조치할 필요는 없었지만, Context API에 연결된 상태 하나가 바뀌면 Context API가 통째로 리렌더링된다는 꽤 크리티컬한 단점은 이제 앞으로 생각하면서 써야겠더라구요(아직까지 문제된 적은 없음). 그래서 제 개인적으로 정신차린 김에 여러분께도 공유드리면 좋을 것 같아 스레드를 파보았습니다. 가볍게 읽고 넘어가주시면 됩니다 ㅎ (편집됨)

김기쁨

요며칠 작업하면서 보니 hook과 react-query로 발라내면 더 좋을 것 같은 부분들이 좀 보이긴 하더라구요 아마 서비스특성상 비계층구조에서 수정가능해야하는 데이터가 워낙 많다보니 나타난 현상이 아닌가..

이동훈

좋은 인사이트 감사드립니다!
이 제품 초기 설계시 context api를 사용한 목적은

1. 한 페이지의 계층을 _section으로 표현하여 나누고
2. 페이지의 계층을 이해하기 쉽게 하고, 데이터의 흐름의 depth를 너무 깊게 하지 않으려면 prop drilling을 최소화 해야한다고 판단했고
3. 한 상태에 따라 바뀌어야 하는 뷰도 상당히 많은데, 이걸 단순화 시키기에 context api가 가장 적합하다 판단했음.
4. Context api는 그 범위를 페이지 단위로 좁힐수 있는 장점이 있었음.

이런 마크로한 관점에서 나온 설계였고, 마이크로한 단계는 민규님이 주신것처럼 이제 고민해야 하는 단계입니다.

현재 프론트의 시스템은 꽤나 단순(?)합니다.(실제 제품에 굴러가는 데이터들은 복잡하지만)
이건 초기에 의도한 바가 맞고, 앞으로 개선하고 만들어가야 할 시스템은 무궁무진 하다 생각합니다. ~~(라고 표현했지만,~~
~~실상은 오더에 나오는 수많은 인풋 관리하기가 너무 힘들어서 이렇게 한 측면이....ㅋㅋㅋㅋㅋ)~~