Redux의 전체적인 흐름
- 리듀서 / 디스패처를 통해서만 store에 있는 데이터 상태를 수정할 수 있다.
- dispatch는 reducer를 호출할 때 2개의 값을 전달한다.
- 1번째는 현재의 state 값을 전달한다.
- 2번째는 action data, 즉 dispatch를 통해 보낸 action 데이터이다.
- dispatch가 호출한 reducer에서 리턴해주는 객체는 state의 새로운 값이 된다.
- 즉 reducer는 state를 입력값으로 받고, action을 참조해서 새로운 state값을 만들어서 리턴해준다. 즉, state를 가공하는 가공자역할이다.
- dispatch가 subscribe에 등록되어 있는 구독자들을 다 호출해준다. -> 그럼, render가 호출이 되면서 -> getState로 가서 state 값을 가져온 다음에 다시 render에게 보내주고, render가 최종적으로 화면을 갱신해주게 되면서, 새로운 state값으로 화면 UI가 바뀌게 된다.
- store에 있는 state 값을 변경하는 데 있어서 이 같은 과정을 거치는 이유는, state 값을 직접 조작하는 것이 금지되어 있기 때문이다(for make more predictable application).
- 정리하자면, getState를 통해서 state값을 가져오고 dispatch를 통해 값을 변경시키고,
subscribe를 이용해서 값이 변경 되었을 때 구동될 함수들을 등록해준다.
또 하나의 핵심은 바로 'state의 값을 직접적으로 변경하는 작업'은 'reducer를 통해서 작업한다'라는 점이다.
Redux를 쓰는 이유 (리덕스가 좋은 이유)
1. 복잡도가 굉장히 낮아져서, 애플리케이션이 상당히 단순해진다. (more simple more predictable)
버튼을 클릭하면 해당 색깔로 나머지 모든 사각형의 색깔을 바꿔주는 프로그램을 리덕스를 사용해서와 사용하지 않고 둘 다 만든다고 가정해보자.
리덕스를 사용하지 않고 구현한 예시:
동일 기능을 리덕스를 적용해서 구현한 예시:
2. 시간여행이 가능하다.
일반적인 개발자 도구를 통한 디버깅을 통해 애플리케이션의 상태를 보는건 보통 현재의 상태가 기준이다. 하지만, 리덕스에서 Time traveling이라고 하는 시간 여행 도구를 이용하게 되면, 시간을 기준으로 각각의 변화가 생겼을 시점마다의 어플리케이션이 내부적으로 어떤 상태인지를 볼 수 있다.
정리하자면, 중앙 집중적인 데이터 스토어를 통해서 어플리케이션을 쉽게 개발할 수 있다는 점과(이건 리덕스가 아닌 다른 툴들도 가지고 있는 부분이다) 시간여행을 할 수 있다(이건 리덕스만이 가지고 있는 기능이다)는 점이 Redux를 사용하는 이유이다.
RM_young