리액트 등장 전 Angular JS와 같은 프레임워크는 MVC 패턴을 유지하고 있었다. 이후 MVC 패턴의 문제점을 해결하기 위해 Flux 패턴이 등장했다.
먼저 MVC 패턴에 대해 알아보고 Flux 패턴에 대해 알아보자.
MVC 패턴이란?
Model, View, Controller 의 약자로 Model에 상태를 저장하고 Controller가 Model를 변경시킨다. 또한 Model이 변경되면 View를 업데이트 시킨다. 또한 View 에서도 Model를 변경시킬 수 있다.
프론트에서 MVC 패턴
[Frontend] View 에서 일어나는 일들
사용자가 입력을 하거나, 화면을 선택 및 클릭, 서버와 통신 등 View에서 많은 일들이 일어난다. 이는 View와 Model이 서로 영향을 줄 수 있음을 의미한다.
💡 1. View → Model
ex) 사용자 입력으로 Model 변경
2. View ← Model
ex) 서버로부터 데이터를 받아서 View 에 데이터 출력
결국, View ↔ Model 이 양방향으로 데이터가 흐르는 것을 알 수 있다.
많은 View를 가지는 프론트
하지만 프론트엔드에서는 View 개수가 매우 많다 (물론 1~2개 있을 수 있지만 View 규모가 커질 것이다. 따라서 우리는 View를 분리하여 여러 개의 작은 뷰를 만든다). 그리고 Model 도 다수 존재할 수 있다.
이는 View 와 Model 간 의존성과 복잡도가 증가시킨다. 그리고 이를 보안하기 위해 많은 View 와 Model 를 상호 연결하는 매우 큰 Controller 가 필요하다.
MVC 패턴의 한계
이렇게 되면 다수의 View와 Model이 존재하고 한 View에서 여러 Model를 변경시키고 한 Model에서 여러 View를 변경시키는 문제가 발생한다. 이는 어떤 View에서 상태를 변경시키면 다른 View에도 상태가 업데이트가 표시되는 등 추적하기 어려워 진다.
결국, 복잡도가 증가하고 데이터의 흐름을 파악하고 예측하기 힘들어진다.
이를 해결하기 위해 고안된 것이 Flux 패턴이다.
Flux 패턴
Flux 패턴은 Facebook에서 개발된 애플리케이션 아키텍처로, 단방향 데이터 흐름을 통해 애플리케이션의 상태 관리를 단순화하고 예측 가능하게 한다. Flux 패턴은 주로 대규모 애플리케이션에서 상태 관리의 복잡성을 줄이기 위해 사용된다.
구성 요소
- Action (액션):
- 사용자나 다른 소스로부터 발생하는 이벤트이다.
- 액션 객체는
type필드와 함께 데이터를 포함하여 디스패처에게 전달한다. - ex)
{ type: 'ADD_TODO', payload: { text: 'Learn Flux' } }.
- Dispatcher (디스패처):
- 모든 액션이 중앙 디스패처를 통해 전달된다.
- 디스패처는 액션을 받아서 등록된 모든 스토어에 전달하여 스토어 상태를 조작한다.
- 단일 디스패처를 사용하여 데이터 흐름을 중앙에서 관리한다.
- Store (스토어):
- 애플리케이션의 상태와 상태를 변경하는 로직을 가진다.
- 스토어는 액션에 따라 상태를 업데이트한다.
- 디스패처에 의해 상태가 변경되면 스토어는 뷰에게 변경사항을 알린다.
- 스토어는 상태를 보유하고 있으므로 컨트롤러 역할을 한다.
- View (뷰): 사용자에게 데이터를 표시하는 UI 컴포넌트.
- 뷰는 스토어로부터 상태를 받아와서 렌더링한다.
- 뷰에서 이벤트(사용자 입력 등)를 발생시키면 액션을 생성하여 디스패처에 전달한다.
각 요소들은 단방향 흐름에 따라 순서대로 역할을 수행하고 Action 이 View(사용자 입력 등)나 다른 소스(서버로부터 데이터 응답 등)로 부터 발생하면 처음부터 다시 순서대로 실행된다.
이로 인해 단방향 데이터 흐름으로 인해 상태 관리가 쉬워지고, 디버깅이 용이해지며, 애플리케이션의 복잡성이 낮아진다.
데이터 흐름 도식화
ex) To Do List에서 flux 패턴 적용
참고
