[react-redux] 리덕스 기초

리덕스에 대해 자세히 기술한 이 페이지를 참고하여 공부 목적으로 요약 정리함

 

등장 배경

- 너무 많은 상태 관리

- 복잡한 코드

- 변화와 비동기(asynchronous, 위임, *)의 혼용

=> 상태 변화가 일어나는 시점에 제약, 상태 변화 예측 가능하게

 

 

3가지 원칙

- 모든 state(상태)는 하나의 store 안에 하나의 객체 트리 구조로 저장

- state를 변화시키는 방법은 action 객체의 전달 외에 없다. (store.dispatch)

- action에 의해 상태 트리가 어떻게 변화되는지 순수 함수로 작성해야 한다.

  이 순수 함수가 바로 reducer다.

  이전 state를 변경하는 것이 아니라 새로운 state 객체를 생성, 반환

 

 

action

- "무언가 일어난다" 기술 (간단한 소식들이라고 생각하면 좋다)

- 애플리케이션에서 store로 보내는 데이터 묶음

- store의 유일한 정보원

- store.dispatch()로 action을 보낼 수 있음

- 자바스크립트 객체

- 어떤 형태의 action이 수행될지를 뜻하는 type을 반드시 가져야 함 (type은 일반적으로 문자열 상수)

- 각 action에는 가능한 적은 데이터

 

 

reducer

- "(action의 결과로) 애플리케이션 상태가 어떻게 바뀐다" 고 특정

- 이전 state, action 받아 다음 state 반환하는 순수 함수

- 순수하다? 인수 변경 X, API 호출 X, routing 등의 side effect X, 순수하지 않은 함수 호출 X

  즉 인수가 주어지면 다음 상태를 계산해서 반환하면 되고 예기치 못한 일은 없어야 한다.

  오로지 계산만 가능하다. 알 수 없는 action에 대해서는 이전의 state를 반환

 

 

store

- action과 reducer를 함께 가져오는 객체

- 1 리덕스 앱, 1 스토어

- 하는 일: 앱의 모든 스테이트 저장, getState()로 스테이트 접근, dispatch(action)으로 상태 수정, subscribe(listener)로 리스너 등록

 

 

리덕스의 데이터 흐름

- 엄격한 일방향

- 모든 데이터가 같은 생명주기, 로직 예측 가능

- store.dispatch(action)호출 => redux store가 reducer 호출=> root reducer가 하나의 트리 상태로 만듦

 

 

리덕스와 리액트-리덕스는 다르다.

- react-redux를 사용하면 store를 리스닝 하고 있는 컴포넌트에 대해 componentWillUnmount를 정의하지 않아도 된다.

- 더 이상 this.state = {...}를 constructor에 정의 할 필요가 없어진다.

(출처)