본문으로 건너뛰기

상태 관리

비공식 베타 번역

이 페이지는 PageTurner AI로 번역되었습니다(베타). 프로젝트 공식 승인을 받지 않았습니다. 오류를 발견하셨나요? 문제 신고 →

Redux FAQ: 상태 관리​

모든 상태를 Redux에 저장해야 할까요? React의 useState나 useReducer를 사용해도 될까요?​

이에 대한 '정답'은 없습니다. 어떤 사용자는 애플리케이션을 항상 완전히 직렬화 가능하고 제어된 상태로 유지하기 위해 모든 데이터를 Redux에 보관하길 선호합니다. 반면 다른 사용자는 '이 드롭다운이 현재 열려 있는지' 같은 중요하지 않거나 UI 관련 상태를 컴포넌트의 내부 상태로 유지하길 선호합니다.

로컬 컴포넌트 상태를 사용해도 괜찮습니다. 개발자로서 어떤 종류의 상태가 애플리케이션을 구성하며, 각 상태가 어디에 위치해야 하는지 결정하는 것은 _여러분_의 몫입니다. 여러분에게 맞는 균형점을 찾아 그 방식을 따르세요.

어떤 데이터를 Redux에 넣어야 할지 판단할 때 참고할 일반적인 경험 법칙은 다음과 같습니다:

  • 애플리케이션의 다른 부분이 이 데이터를 신경 쓰나요?

  • 이 원본 데이터를 기반으로 추가 파생 데이터를 생성해야 하나요?

  • 동일한 데이터가 여러 컴포넌트를 구동하는 데 사용되나요?

  • 특정 시점으로 이 상태를 복원할 수 있는 기능(예: 시간 여행 디버깅)이 가치가 있나요?

  • 데이터를 캐시하고 싶나요? (예: 이미 상태에 존재하면 재요청하지 않고 사용)

  • UI 컴포넌트를 핫 리로딩할 때 이 데이터를 일관되게 유지하고 싶나요? (컴포넌트 교체 시 내부 상태가 유실될 수 있음)

추가 정보​

아티클

토론

함수, 프로미스 또는 기타 직렬화 불가능한 항목을 스토어 상태에 넣을 수 있나요?​

스토어에는 일반 직렬화 가능 객체, 배열 및 원시 값만 넣는 것을 적극 권장합니다. 기술적으로는 직렬화 불가능한 항목을 스토어에 삽입할 수 있지만, 이렇게 하면 스토어 내용의 지속성(persist) 및 재수화(rehydrate) 기능이 손상될 수 있을 뿐만 아니라 시간 여행 디버깅에도 방해가 됩니다.

지속성이나 시간 여행 디버깅이 의도대로 작동하지 않을 수 있다는 점을 수용한다면, 직렬화 불가능한 항목을 Redux 스토어에 넣어도 전혀 무방합니다. 궁극적으로 이는 _여러분_의 애플리케이션이며 구현 방식은 여러분에게 달려 있습니다. Redux의 다른 많은 측면과 마찬가지로 어떤 절충점이 있는지 반드시 이해하시기 바랍니다.

추가 정보​

토론

상태에서 중첩되거나 중복된 데이터를 어떻게 구성하나요?​

ID, 중첩 또는 관계를 가진 데이터는 일반적으로 "정규화된" 방식으로 저장해야 합니다: 각 객체는 ID를 키로 한 번만 저장하고, 해당 객체를 참조하는 다른 객체들은 전체 객체 복사본 대신 ID만 저장해야 합니다. 스토어의 일부를 데이터베이스처럼 생각하고 항목 유형별로 개별 "테이블"을 구성하는 것이 도움이 될 수 있습니다. normalizr나 redux-orm 같은 라이브러리가 정규화된 데이터 관리에 도움과 추상화를 제공할 수 있습니다.

추가 정보​

문서

아티클

토론

폼 상태나 기타 UI 상태를 스토어에 저장해야 할까요?​

이전에 설명한 상태 저장 결정 규칙이 이 질문에도 동일하게 적용됩니다.

이 규칙에 따르면 대부분의 폼 상태는 Redux에 넣을 필요가 없습니다. 컴포넌트 간에 공유되지 않을 가능성이 높기 때문입니다. 하지만 이 결정은 항상 사용자와 애플리케이션에 따라 달라집니다. 원래 스토어에서 가져온 데이터를 편집 중이거나, 애플리케이션 내 다른 컴포넌트에서 작업 중인 값을 반영해야 하는 경우 폼 상태 일부를 Redux에 유지할 수도 있습니다. 반면 폼 상태를 컴포넌트 내부에 두고 사용자가 폼 작성을 마쳤을 때만 데이터를 스토어에 디스패치하는 것이 훨씬 간단할 수 있습니다.

이에 따라 대부분의 경우 Redux 기반 폼 관리 라이브러리도 필요하지 않을 것입니다. 다음과 같은 접근 방식을 순서대로 시도해 보시길 권장합니다:

  • 데이터가 Redux 스토어에서 오는 경우에도 먼저 폼 로직을 직접 작성해 보세요. 대부분의 경우 이 방법만으로 충분합니다. (이에 대한 훌륭한 가이드는 Gosha Arinich의 React 폼 작업 포스트를 참고하세요.)

  • 폼을 "수동으로" 작성하는 것이 너무 어렵다면 Formik이나 React-Final-Form 같은 React 기반 폼 라이브러리를 사용해 보세요.

  • 다른 접근 방식으로 부족하다고 확신해 Redux 기반 폼 라이브러리를 반드시 사용해야 한다면, 그제서야 Redux-Form이나 React-Redux-Form을 고려해볼 수 있습니다.

폼 상태를 Redux에 저장한다면 성능 특성을 고려해야 합니다. 텍스트 입력 시 매 키 입력마다 액션을 디스패치하는 것은 가치가 없을 수 있으며, 디스패치 전에 변경 사항을 로컬에 유지하기 위해 키 입력을 버퍼링하는 방법을 고려해보세요. 항상 애플리케이션의 전반적인 성능 요구사항을 분석하는 시간을 가지세요.

다른 종류의 UI 상태도 이와 같은 경험 법칙을 따릅니다. 대표적인 예로 isDropdownOpen 플래그 추적이 있습니다. 대부분의 경우 앱의 다른 부분은 이에 관심이 없으므로 컴포넌트 상태로 유지해야 합니다. 하지만 애플리케이션에 따라 Redux로 대화상자 및 팝업 관리, 탭, 확장 패널 등을 관리하는 것이 합리적일 수 있습니다.

추가 정보​

아티클