Flux란 애플리케이션의 데이터 흐름을 관리하는 패턴을 말한다.
Flux에서 중요한 것은 데이터의 흐름이 단방향으로 흐른다는 것이다.
Front-End에 사용되는 프레임워크의 대부분은 MVC(Model-View-Controller) 디자인 패턴을 채택했었다.
그런데 MVC 패턴이 한계 명확하게 보여지면서 Flux 아키텍쳐가 등장하게 되었다.
✅ 그럼 MVC 패턴을 먼저 살펴보자
기존의 어플리케이션 환경에서 보편적으로 사용되는 패턴은 MVC였다.
Model에 데이터를 정의해 두고, Controller를 이용해 Model 데이터를 생성 / 조회 / 수정 / 삭제(CRUD)하고, 변경된 데이터는 View에 출력되면서 사용자에게 전달되며 그림처럼 model과 view가 양방향 통신이 가능하다.
MVC 패턴의 문제점
문제는 대규모 애플리케이션의 경우 MVC가 너무 빠르고 복잡해 진다는 점에 있다.
그래서 코드 예측이나 테스트의 어려움, 유지보수 비용 증가 등 여러가지 문제가 발생한 것이다.
가장 대표적인 사례로 Facebook 웹 앱에서의 MVC 구조는 앱이 커지면서 굉장히 복잡해졌다고 한다.
View가 다양한 상호작용을 위해 여러개의 Model을 동시에 업데이트하는 상황이 나타났기 때문이다.
이렇게 많은 의존성을 가지게 되면 개발 시에 당연히 예측불가능한 상황이 많이 나온다.
👍Flux
facebook은 위의 mvc 패턴의 문제를 해결하기 위해 flux라는 패턴을 만들었다.
Model이 View를 반영하고, View가 Model을 변경하는 양방향 데이터 흐름에서 벗어나 단방향으로만 데이터를 변경할 수 있도록 만든 것이다.
Flux의 가장 큰 특징은 단방향 데이터 흐름이다.
데이터 흐름은 항상 Dispatcher에서 Store로, Store에서 View로, View는 Action을 통해 다시 Dispatcher로 데이터가 흐르게 된다.
이런 단방향 데이터 흐름은 데이터 변화를 휠씬 예측하기 쉽게 만들고 Flux는 크게 Dispatcher, Store, View 세 부분으로 구성되어있다.
디스패처(Dispatcher)
디스패처는 Flux 애플리케이션의 모든 데이터 흐름을 관리하는 허브 역할을 한다.
액션이 발생하면 디스패처로 메세지나 액션 객체가 전달되고 디스패처에서는 등록된 콜백함수를 통해 이 메세지를 스토어에 전달하며 다른 구성요소와 달리 디스패처는 전체 애플리케이션에서 한 개의 인스턴스만 사용한다.
스토어(Store)
스토어는 애플리케이션 상태를 저장한다.
Flux의 스토어는 상태를 다루기 때문에 무엇이든 저장할 수 있고 단순한 Object로 구성되어 있다.
모든 상태변경은 스토어에 의해서 결정되어야만 하며, 상태변경을 위한 요청을 스토어에 직접 보낼 수 없으며 무조건 액션 생성자를 통해 디스패처를 통해 액션을 보내야먄 수정이 가능하다.
뷰(View)
Flux의 View는 화면에 나타내는 것 뿐만이나라, 자식 View로 데이터를 흘려 보내는 뷰 컨트롤러의 역할도 함께 한다.
액션(Action)
디스패처 특징 메소드를 실행하면 스토어에 변화를 일으킬 수 있다.
이때 이 데이터 묶음을 액션이라 하고, 전달할 액션 객체는 액션 생성자라는 함수를 통해 만들어진다.
뷰에서 액션생성자(Action creator)를 실행하여 전달할 메세지을 생성하고, 디스패처에 전달하여 스토어에 저장되어 있는 상태를 변경하는 것이다.
🌞flux의 데이터 흐름
1. Action이 Dispatcher에게 특정 사용자 Action 전달
2. Dispatcher는 특정 Action Type 파악 후 Store에 전달
3. Store는 Dispatcher에게 요청에 내부 상태를 수정
4. View는 Store의 변화가 감지되면 View를 업데이트
참고
https://bestalign.github.io/translation/cartoon-guide-to-flux/
https://beomy.tistory.com/44
https://lemontia.tistory.com/637