리덕스에 대해 다시 한 번 공부하던 중에 Flux패턴이 무엇인지 다시한번 짚고가야할 것 같아 정리하기로 했다.
MVC모델의 문제
모델과 뷰가 양방향으로 업데이트를 하게되는데 이는 어플리케이션의 복잡도를 높이고 확장을 어렵게 만들 수 있다.
작은 어플리케이션이라면 위와같은 구조로 되어있다 하더라도 쉽게 문제를 파악하거나 코드의 흐름을 파악할 수 있다.
위와 같이 되어있는 어플리케이션이라면 과연 데이터의 흐름이나 어떤 곳에서 문제가 발생했을 때 쉽게 찾을 수 있을까?
위와 같이 MVC의 양방향 데이터 바인딩은 확장할 수록 어플리케이션이 복잡해진다.
Flux 아키텍처가 왜 필요할까?
Facebook팀에서 만든 MVC의 문제를 해결할 목적으로 만든 클라이언트 사이드 웹 어플리케이션 아키텍처이다.
단방향 데이터 흐름을 통해 보다 예측가능하게 상태를 관리할 수 있도록 하기 위해서!
Flux?
단방향 데이터 흐름을 가지는 아키텍처 구조이다.
데이터의 흐름 : 디스패쳐 -> 스토어 -> 뷰
뷰에서 입력이 발생하면 액션을 통해서 디스패쳐로 향하게 된다..
디스패처
dispatcher는 Flux 어플리케이션의 중앙 허브로 모든 데이터의 흐름을 관리한다.
액션이 발생하면 디스패처로 메세지나 액션 객체나 전달되고 디스패쳐에서는 이러한 메세지 혹은 액션 객체를 콜백 함수를 통해 스토어로 전달한다. 스토어에 접근하기 위한 일종의 단계이고 액션을 통해 스토어에 접근하기 위해서는 디스패쳐의 단계를 거쳐야 한다.
스토어
스토어는 애플리케이션의 상태를 저장한다. 모든 상태 변경은 스토어에 의해 결정되며 상태 변경을 위한 요청을 스토어에 직접 할 수는 없습니다. 상태 변경을 위해서는 꼭 액션 생성자를 통해 디스패쳐 단계를 거친 후 액션을 보내야만 상태값 변경이 가능합니다.
뷰
뷰는 상태를 가져와서 보여주고 사용자로 부터 입력 받을 화면을 보여준다. 컨트롤러 뷰는 스토어와 뷰의 중간 관리자 같은 역할을 하고 스토어에서 상태 값 변경이 일어났을 때 스토어는 그 사실을 컨트롤러 뷰에서 전달하고 컨트롤러 뷰는 자신 아래에 모든 뷰에게 새로운 상태를 넘겨 준다..
