개발자

react 전역 상태 관리 도구 사용

2024년 06월 07일조회 72

안녕하세요~! 최근에 프론트엔드를 배우게 되어서 여쭤봅니다.. react 를 사용하면서 props drilling 을 겪고, 복잡한 코드가 되어 가는 중입니다. 궁금한 점은 zustand를 전역 상태 관리 도구로 사용하고 있는데 zustand를 어떻게 사용해야 잘 사용하는 것 일까요? 렌더링을 조금 깔끔하게 하고 싶어서 문의드립니다. 상황에 따라 다르겠지만 zustand를 많이 써서 state를 store 형태로 보관해서 사용하는게 좋을까요? 전문가들의 고견 부탁드립니다.(_ _)

이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.

답변 1

상현님의 프로필 사진

글의 항간이 느껴져서 zustand를 잘 사용하는 법보다는 store를 보다 더 잘 쓸 수 있는 방법에 대해서 말씀드리고 싶은데요. react는 한마디로 "중첩 스코프의 세계"라고 말할 수 있습니다. 보통 App이라는 스코프 아래에 Layout이라는 스코프가 있고, 그 스코프 아래에 다시 여러 Component 스코프가 켜켜이 쌓일 겁니다. 이런 중첩 구조에서는 동등한 서열 간의 스코프나 분기되어 서로 다른 곳으로 뻗어나간 스코프 사이에서 어떠한 값을 공유하려면 분기되기 전의 상위 스코프에 그 값이 놓여있어야 합니다. 그래야만 참조가 가능하죠. react의 초기 문서에는 이것을 두고 "끌어올리기"라는 표현을 썼습니다. zustand를 사용한다고 해서 이 구조를 바꿀 수 있는 것은 아닙니다. state 도구의 provider는 늘 App을 감싸는 것이 보통인데, 이는 분기 이전의 스코프가 필요하다는 구조적인 이슈는 바뀌지 않으니 끌어올리기를 극단적으로 맨꼭대기까지 한 결과입니다. 이렇듯 react의 구조를 바꾸지 못하고 편승함에도 store라는 스코프를 사용하는 이유는, 실질적인 구조는 바꾸기 때문입니다. store 이하의 모든 컴포넌트는 실질적으로는 중첩이 아닌 모두 평행 상태가 됩니다. App으로부터 30개 이상의 중첩을 거친 스코프에서나 App 바로 아래의 스코프나 모두 store와 직접 연결할 수 있고, 어느 단계의 스코프에서도 set과 get이 가능하고 그 값을 공유할 수 있습니다. 이로 인해서 각 스코프는 자신이 참조해야 할 값과 그 값을 변경시켜야 할 파이프라인만을 지니는, 자기 성격이 매우 강한 형태가 될 수 있습니다. 따라서 props 의존성이 대폭 줄어들죠. 이를 돌려말하면 의존성을 주입받는 것이 아니라 스코프 자신이 의존성을 결정하는 방식으로 가버린다는 의미입니다. 쉽게 말하면 용도가 뚜렷해서 다른 것으로 확장하거나 전환하기 어려워집니다. 그래서 사용하는 데에 있어 안배가 필요합니다. props 의존성을 가지고 있어야 하지만, 그걸 받아오기 위한 drilling의 정도가 심하다면 store를 사용하되 그 부모 컴포넌트가 값을 참조하여 내려주도록 조정하시고, props 의존성이 없어도 되고 특정 값을 오롯이 사용한다면 store와 직접 연결하도록 만드세요. 만약 store부터로 값을 참조하고, 그 값을 다루어야 하는 이벤트들이 얽혀있다면 state 계층을 분리해서 hook으로 만들어 view로부터 떼어내는 것도 한 방법입니다. store가 코드의 복잡성이나 불가분한 것들을 해결해주는 만능은 아니라는 점에 유의하시면 좋을 것 같습니다.

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

AI 답변
커리어리 AI 봇 프로필 이미지

커리어리 AI 봇

GPT가 달아주는 답변입니다.

2024년 06월 07일

Zustand는 전역 상태 관리 도구 중 하나로, 작은 크기와 간단한 API를 가지고 있어서 학습 곡선이 상대적으로 낮습니다. Zustand를 효과적으로 사용할 때의 몇 가지 원칙들은 다음과 같습니다: 1. **필요할 때에만 Zustand를 쓰세요**: Zustand는 전역 상태 관리에 유용하지만, 모든 상태가 전역상태일 필요는 없습니다. 컴포넌트 내부에서만 사용되는 로컬 상태는 그냥 useState나 useReducer를 사용하세요. 2. **각 Store는 한 가지 Concern(관심사)을 담당하게 만드세요**: 주로 비즈니스 로직에 따라 나눠집니다. 예를 들어 사용자 인증 정보, 노트 데이터, UI 상태 등 각각 별도의 Store로 관리 할 수 있습니다. 3. **Store 내부에서 구체적인 Action을 만들어서 로직을 숨기세요**: 이렇게 하면 컴포넌트 코드가 단순해지고 테스트하기도 편해집니다. 4. **같이 사용하는 데이터들을 한 곳에서 업데이트하시길 추천드립니다**: 하나의 action이나 reducer 안에서 변경이 일어나야 할 여러 상태들을 한번에 업데이트 할 수 있습니다. 5. **컴포넌트에서는 가능한 최소한의 정보만 Subscribe 하세요**: Zustand를 사용하면 컴포넌트가 필요로 하는 상태만 선택적으로 구독할 수 있습니다. 이 방식은 리렌더링을 최소화하는데 도움이 됩니다. 결국, Zustand을 얼마나 많이 사용하느냐는 학습 비용, 프로젝트의 복잡성, 팀원들의 의견 등 여러 요인을 고려하여 결정해야 합니다. Zustand를 가지고 양질의 코드를 작성하기 위해서는 전역 상태 관리에 대한 깊은 이해와 함께 명확한 아키텍처 전략이 중요합니다. 주어진 상황에서 최선의 결정을 내리기 위해서는 계속해서 배우고 실험해 보는 것이 중요합니다!

목록으로

지금 가입하면 모든 질문의 답변을 볼 수 있어요!