프론트엔드 개발에서의 상태 관리
React는 상태 관리를 위한 라이브러리가 아닙니다. 하지만 상태 관리 주요 원칙을 배우고 따라가면, 컴포넌트 간 서로 느슨하게 결합된 아름다운 코드를 작성할 수 있습니다.
상태 변화?
상태는 변하는 데이터입니다. (동적으로 표현되는 데이터)
Side Effect
함수의 입력 외에도 함수의 결과에 영향을 미치는 요인
- 네트워크 요청
- API 호출
React의 주요 개발 원칙 중 하나가 UI를 페이지 단위가 아닌 컴포넌트 단위로 보는 것입니다.
상태를 구분할 때 절대적인 기준이나 법칙이 있는 것은 아닙니다.
로컬 상태
특정 컴포넌트 안에서만 관리되는 상태
전역 상태
프로덕트 전체 혹은 여러가지 컴포넌트가 동시에 관리하는 상태
일반적으로 전역 변수를 남용하는 것은 좋지 않다고 배웁니다. 하지만 경우에 따라서 전역 상태는 필요합니다.
서로 다른 컴포넌트가 동일한 상태를 다룬다면, 출처는 오직 한 곳이어야만 합니다. 두 데이터는 sync(동기화)하는 과정이 필요하고 한 곳에서만 상태를 저장하고 접근해야 합니다.
Why Redux?
Redux에서는 컴포넌트와 상태를 분리하는 패턴을 배웁니다. 상태를 다루기 위해 컴포넌트 안에서 상태 변경 로직이 복잡하게 얽혀있는 경우가 많습니다.
상태 변경 로직을 컴포넌트로부터 분리하면, 표현에 집중한 단순한 함수 컴포넌트를 만들 수 있게 됩니다.
Redux는 상태 관련 라이브러리 입니다.
Redux 세 가지 원칙
- Single source of truth: 상태가 관리되는 오직 하나의 공간
- State is read-only: Action 객체를 통해 데이터 변경 가능
- Changes are made with pure functions: 순수 함수!
Action: 데이터 운반을 하는 역할!
Reducer
현재 상태와 Action을 이용해 다음 상태를 만들어 낸다.
Action, Dispatch => Reducer => New State
(Action 객체는 Dispatch에게 전달되고, Dispatch는 Reducer를 호출해 새로운 State를 생성)
Redux의 장점
- 상태를 예측 가능하게 만들어 준다.
- 유지보수
- 디버깅에 유리하다
- 테스트가 쉽다.
Redux Architecture
Action => Dispatcher => Store => View
