Redux를 시작하기전 필요한 배경지식

MVC

mvc

  • 어떤 Action이 입력되면 Controller는 그걸 받아서 Model이 지니고 있는 데이터를 조회하거나 업데이트 할 수 있다
    그 변화는 View에 반영된다. 또한 뷰에서 모델데이터에 접근하여 업데이트 할 수 있는 상호연관 구조를 가진 아키텍쳐 모델이다.

  • 하지만 app의 규모가 커지면 model과 view의 갯수가 많아지면 무한반복에 빠질 가능성이 크다.

  • 그래서 개발된 것이 아래 그림의 FLUX 아키텍쳐

FLUX

flux

  • 시스템에서 어떤 action을 받았을 때 dispatcher가 받은 action을 통제하여 store에 있는 데이터를 업데이트 한다.

  • 변경된 데이터가 있다면 뷰에 리렌더링 함.

  • 그리고나서 뷰에서 dispatcher로 action을 보냄.

  • 작업이 중첩되지않도록 해줌 어떤 action이 dispatcher를 통하여 스토어에 있는 작업을처리하고 끝나기전까지 action을 대기시킴.

  • 링크 : FLUX로의 카툰 안내서

REDUX

  • Redux는 Flux가 해결하는 문제점에다가 추가적인 문제점을 더 해결할 수 있다.

  • Flux와 같이 Redux도 애플리케이션의 상태를 더욱 예측 가능하게 만들어준다. 만약에 상태를 변경하고 싶다면 액션을 발생시켜야 한다. 상태를 저장하고 있는 스토어(store)는 접근자(getter)만 있고 설정자(setter)는 없으므로 직접적으로 상태를 바꿀 방법이 존재하지 않는다. 이런 기본적인 점은 Flux와 Redux가 아주 비슷하다.

  • 그럼 왜 다른 패턴이 필요할까? Redux를 만든 Dan Abramov는 Flux를 더 향상시킬 수 있다는 사실을 찾아냈다. 그는 더 나은 개발자 도구(developer tool)를 사용하길 원했고, Flux에서 몇몇 부분을 조금 바꾸면 더 나은 개발자 도구를 쓸 수 있으면서도 Flux와 같은 예측 가능성을 가질 수 있다는 것을 발견했다.

  • 링크 : REDUX로의 카툰 안내서