Flux 패턴이란?

• Flux 패턴은 애플리케이션의 상태 및 데이터 흐름을 관리하기 위해 프런트엔드 웹 개발에 사용되는 소프트웨어 아키텍처 패턴입니다.
• Flux 패턴은 데이터의 단방향 흐름을 적용합니다.
• 여기서 액션은 스토어에서 업데이트를 트리거하고 뷰에 UI 업데이트를 알립니다.
• Flux 패턴은 다음과 같은 몇 가지 주요 구성 요소로 구성됩니다.

1. Dispatcher: 다양한 출처로부터 조치를 받아 등록된 매장으로 발송하는 중앙 허브 역할을 합니다. 작업이 순차적으로 처리되도록 하고 여러 작업이 동시에 처리되는 것을 방지합니다.
2. store: 스토어는 애플리케이션의 상태를 유지하며 데이터 업데이트 및 관리를 담당합니다. Dispatcher가 발송한 작업에 응답하고 그에 따라 상태를 업데이트합니다. 스토어는 데이터가 변경되었음을 뷰에 알리기 위해 변경 이벤트도 내보냅니다.
3. view: 보기는 스토어에서 받은 데이터를 기반으로 사용자 인터페이스를 렌더링하는 역할을 합니다. 스토어의 데이터가 변경되면 애플리케이션의 업데이트된 상태를 반영하기 위해 보기가 그에 따라 업데이트됩니다.
4. action: 액션은 애플리케이션에서 이벤트 또는 사용자 상호 작용을 나타내는 일반 JavaScript 개체입니다. Dispatcher로 발송되며 상점에서 업데이트해야 하는 항목에 대한 정보를 포함합니다.

Flux 패턴은 왜 사용할까?

(좌: 기존의 Container-Presenter 패턴에서의 Props Drilling Problem)

(우: Flux)

• Facebook에서 애플리케이션의 복잡한 데이터 흐름을 처리하기 위한 솔루션으로 도입했습니다.
• 단방향 데이터 흐름은 문제를 명확하게 분리하고 제어되지 않은 방식으로 데이터 변형이 발생하는 것을 방지하므로 애플리케이션에서 데이터가 어떻게 변경되는지 쉽게 추론할 수 있습니다.
• 전반적으로 Flux 패턴은 프런트엔드 애플리케이션에서 상태 및 데이터 흐름을 관리하기 위한 구조화되고 조직화된 접근 방식을 제공하므로 예측 가능한 동작으로 복잡한 UI를 더 쉽게 개발하고 유지 관리할 수 있습니다.

Flux와 MVC의 차이점

• FLUX 패턴은 View를 각각의 MVC 컴포넌트 관점으로 보는 것이 아니라 하나의 큰 View로 이해하고 View에서는 Dispatch를 통해서 Action을 전달하면 Action은 Reducer를 통해서 Data가 Store에 보관이 되고 Store에 들어있는 데이터는 다시 View로 연결이 되는 방식을 지향합니다.

기존의 컴포넌트 단위의 MVC개념에서 완전히 비지니스 로직과 View를 분리하면서 이 분리된 개념을 **상태관리(State Management)라고 부르게 됩니다.

MVC에서 FLUX으로 오면서 달라진 부분

• 공통적으로 사용되는 비지니스 로직의 Layer와 View의 Layer를 완전히 분리되어 상태관리라는 방식으로 관리한다.
• 각각의 독립된 컴포넌트가 아니라 하나의 거대한 View 영역으로 간주한다.
• 둘 사이의 관계는 Action과 Reduce라는 인터페이스로 분리한며 Controller는 이제 양방향이 아니라 단반향으로 Cycle을 이루도록 설계한다.
• FLUX 패턴은 각 프레임워크 진영에게 많은 영감을 주었으며 프레임워크와 더불어 본격적인 상태관리 라이브러리들이 만들어지기 시작하게 되었습니다.
• Redux, Vuex 등이 대표적인 상태관리 라이브러리입니다.

Flux 패턴은 어떻게 사용할까?

• 예시 코드(상당히 깁니다!)
• 아주 간단하게만 써보자면
  • 액션타입을 지정해주고
  • 액션생성자를 지정해주고
  • 리듀서 폴더에 초기상태를 지정해주고
  • 각각의 리듀서들을 정의해주고
  • Redux의 'combineReducers'를 사용하여 리듀서들을 결합하여 Redux store를 만든다.
  • react-redux라이브러리의 Provider컴포넌트를 사용하여 Redux 스토어로 메인 컴포넌트를 래핑하고
  • connect기능을 사용하여 컴포넌트를 Redux 스토어에 연결한다.
• 장점은 분명하지만 단점 또한 명확합니다.

Flux 패턴의 단점은 무엇일까?

• 의도는 충분히 좋지만 사용하기 위해서

높은 학습곡선
장황한 문법

이 지적되었습니다.

• 간단한 구조에서는 앞에서 언급한 Props Drilling Problem이 치명적이지 않았고 상태를 관리하기 위해서 Action, Dispatch, Reducer를 만들고 관리하는데 들어가는 많은 부수적인 코드들로 인해 관리가 되려 어려워 진다는 문제가 있었습니다.

출처

https://velog.io/@teo/프론트엔드에서-MV-아키텍쳐란-무엇인가요#프롤로그