인프런 커뮤니티 질문&답변
작성한 질문수
Context 관련 상태관리도구 질문있습니다!
해결된 질문
작성
·
40
·
수정됨
0
안녕하세요! 회사에서 프론트엔드업무도 맡게되어 강사님 강의로 잘 배우고 있습니다!😍😍
Context=props driling을 방지하려고 데이터를 꺼내쓰는 저장소를 만든다고 이해했습니다.
만약 Context.Provider로 "최상위 컴포넌트"를 감싸주면 그게 "전역" 저장소 역할을 하는거 아닌가요?!..
Redux나 zustand? 같이 전역저장소 역할을 하는 툴들이 있다고 하던데
조사해보니 value={{todos,b,c]} 일때 redux는 구독이라는 개념으로 todos의 "길이변화"를 감지해서 "특정 컴포넌트만 리렌더링" 시킬수있다..? 이런 정밀한 작업의 차이밖에 없는걸로 이해돼서요! 좀더나은 Provider로 이해됐습니다.
로그인 정보라던가 현재 선택한 메뉴정보, 장바구니정보 이런데이터들을 담기위해 앱최상단에 Provider로 감싸는건 안좋은 방법일까요? 굳이 Redux나 zustand같은 툴들을 사용하는 이유나 적절한 사용법이 궁금합니다!
답변 1
0
안녕하세요 seulgi980님 이정환입니다.
우선 말씀하신 것 처럼 Context Provider로 전체 컴포넌트를 감싸면, 해당 Context를 전역 상태 저장소로 사용할 수 있습니다.
그러나 Context는 Provider에게 제공하는 value Props가 변화할 경우, 쉽게 말해 공급하는 데이터가 변화할 경우 리렌더링이 발생하여 그 하위 컴포넌트들이 모두 리렌더링되는 한계점이 있습니다. 물론 이런 문제는 강의에서 안내드렸듯이 memo나 useMemo, useCallback을 활용해 최적화 할 수 있지만 앱이 커지고 구조가 복잡해 질 수록 신경써야 할 부분이 많아져 프로젝트의 난이도가 급 상승하게 될 수 있습니다.
따라서 보통은 말씀하신 Redux나 Zustand를 활용해 전역 상태를 관리하게 됩니다. 이런 도구들은 보통 전역 상태가 변화하더라도 전체 컴포넌트의 리렌더링을 유발하지 않습니다. 그 대신 특정 상태를 구독하고 있는(특정 상태를 사용하고 있는) 컴포넌트만 선택적으로 리렌더링 시킵니다.
또 코드 구조 측면에서도, Context로 전역 상태를 확장해 나가다 보면 Provider가 점점 비대해지거나(Provider가 많아지게 됨), 여러 Context를 분리하면서 Provider가 중첩되는 구조가 되기도 합니다. 반면 Zustand 같은 도구는 스토어를 하나로 두고 필요한 곳에서 꺼내 쓰는 방식이라 상태의 위치와 변경 지점이 더 명확해지고, 팀 단위로 협업할 때도 규칙을 잡기가 쉽습니다. 코드도 굉장히 간단하죠!
혹시나 Zustand를 활용하는 방법에 대해 더 공부해보시고 싶다면 Zustand 공식문서를 정독하시거나 이후에 진행되는 제 강의 "한입 실전 프로젝트 - SNS편"을 수강해 보시길 권장드립니다 😀
정성스런 답변 감사합니다!! 이해가 완전 됐습니다😍😍