Flux의 등장 배경

• Facebook은 기존에는 MVC 패턴을 사용하고 있었는데 Facebook에서 계속 발생하는 알림 버그를 해결할 방법을 찾고 있었다. 이 버그는 업데이트를 해도 계속 발생하였고 Model과 View 사이의 의존성에 의해 원인을 찾기 쉽지 않았다. 이에 개발팀은 근본적으로 데이터를 예측가능하게 만들어서 문제점을 완전히 없애기 위해 단방향 데이터 흐름의 Flux 아키텍쳐를 개발하였다.

Flux란?

• Flux는 Facebook에서 개발한 어플리케이션 아키텍쳐로, 단방향 데이터 흐름을 활용해 View 컴포넌트를 구성하는 React를 보완하는 역할을 한다. 기존의 프레임워크와는 달리 패턴과 같은 모습을 하고 있기 때문에 Flux 패턴이라고도 하며, 단방향 데이터 흐름을 통해 상태의 일관성을 유지하고, 복잡한 상태 관리를 간소화하는 것을 목표로 한다.

Flux 요소의 개념과 작동 원리

기본 구조

View에서 사용자의 상호작용에 응답하기 위해 새로운 Action을 만들어 시스템에 전파한다.

• Flux 패턴은 View, Action, Dispatcher, Store의 4가지 요소로 이루어져 있다.

• View(React 컴포넌트)
  View는 사용자 인터페이스를 구성하는 컴포넌트이다. 사용자가 상호작용을 하면 View는 Action Creator 메서드를 통해 새로운 Action을 만들어 Dispatcher에 전파하게 된다.
• Action
  Action은 type과 payload 속성을 포함하는 간단한 객체로서, 사용자가 버튼을 클릭하거나, 서버로부터 데이터를 가져오는 등 어떤 이벤트 발생했는지에 대한 정보를 가지고 있다.
• Dispatcher
  Flux 아키텍처의 중앙 허브로, 애플리케이션에서 발생하는 모든 액션을 처리하고, 이를 각각의 Store에 전달하는 역할을 한다. Dispatcher에는 모든 Store에 대한 콜백이 등록되어 있는데, 이 콜백이 등록된 순서대로 동기적으로 Store에 Action을 전달한다. 또한 waitFor 메서드를 통해 의존성이 있는 Store 간의 업데이트 순서를 정할 수 있다.
• Store
  애플리케이션의 상태와 상태변경 로직을 관리하는 저장소이다. 모든 Store는 Dispatcher를 통해 모든 Action을 전달 받고, 해당 Action을 처리할지, 무시할지 결정한다. 만약 처리해야할 Action이라면 이 Action을 Controller-View에 전달하고, Controller-View는 하위에 있는 모든 View의 상태를 변경한다.

• 데이터 흐름
  사용자가 상호작용을 함 > View는 Action Creator를 통해 새로운 Action을 생성하여 Dispatcher로 전달 > Dispatcher는 콜백이 등록된 순서대로 Action을 모든 Store로 전달 > Store는 변경 사항을 Controller-Views에게 전달 > Controller-View는 변경된 데이터를 기반으로 자식 컴포넌트 전체를 리렌더링

Flux 아키텍처를 사용할 때 지켜야 하는 사항

• 단방향 데이터 흐름
  Flux 어플리케이션에서 데이터는 단방향으로 흐른다. View -> Action-> Dispatcher -> Store 그리고 다시 View로 데이터가 전달되는 일련의 과정에서 각 요소는 입력과 출력이 구분되어 단방향 데이터 흐름을 구성할 수 있어야 하고, 각각의 역할이 제대로 구현되어 있어야 한다.
• 만약, 상태 변경 로직을 View 컴포넌트에서 처리하는 경우, 코드의 재사용성이 떨어지고 컴포넌트의 역할이 애매해질 수 있다.

• 데이터의 불변성
  상태를 변경할 때, 기존 상태를 변경하는 것이 아니라 새로운 객체를 생성하고 Store에 저장하여 상태를 변경하여야 한다. 이는 상태의 불변성을 유지하기 위한 것으로, 이를 통해 예측 가능하고 안정적인 상태 관리를 할 수 있다.
• 만약, Store 객체가 제대로 구현되지 않아 기존의 상태를 직접 변경하는 경우 불필요한 데이터가 쌓여 렌더링 속도가 느려지고, 상태 변경 원인을 찾기 어려워진다.

Flux 아키텍처의 장점

• 단방향 데이터 흐름으로 복잡도를 낮출 수 있다.
• 불변성 데이터로 인해 상태 관리가 용이해진다.
• View와 상태의 분리로 재사용성이 향상되고 유지보수가 용이해진다.

Flux 아키텍처의 단점과 한계

• 상태 관리 및 데이터 흐름을 다루는데 복잡한 작업이 필요하기 때문에 진입장벽이 높고 효과적으로 구현하기 위해서는 많은 경험과 지식이 필요하다.
• Store가 많아지면 Store간의 의존성이 발생할 수 있어서 Dispatcher를 통해 의존성 관리를 별도로 해주어야 한다.
• 상태 변경 로직을 초기화 하기 위해 리로딩을 하려면 Store의 상태가 초기화 된다.
• 서드파티 모듈을 적용하기 어렵다.

+

Redux의 데이터 흐름

1. 액션 생성자 함수를 통해 상태에 대한 업데이트를 요청하는 액션 객체를 생성한다.
2. 액션 객체는 Reducer 함수에 전달된다. Reducer 함수는 현재 상태와 액션 객체를 받아 새로운 상태를 반환한다.
3. Store는 Reudcer 함수를 이용해 상태를 업데이트한다. 이 때, 기존 상태를 직접 수정하지 않고 새로운 상태 객체를 생성하여 업데이트한다.
4. Store는 상태의 변경을 뷰 레이어 바인딩을 통해 UI를 업데이트한다.