Flux 패턴?
Flux 패턴은 2014년 페이스북 F8 컨퍼런스에서 발표된 아키텍처로, 단방향 데이터 흐름을 유지하는 아키텍처 디자인 패턴입니다. 사용자의 입력을 기반으로 액션(Action)을 만들고, 이를 통해 디스패처(Dispatcher)에 전달하여 스토어(Store)의 데이터를 변경한 뒤 뷰(View)에 반영합니다.
웹 개발 MVC 패턴 한계 리액트 Flux 패턴의 등장
React 등장 이전, 과거 웹 개발에서는 MVC 패턴을 사용하여 웹을 개발하였습니다.
MVC 패턴이란 Model, View, Controller라는 계층 구조로 나뉘어진 패턴입니다.
- Model : 애플리케이션의 데이터와 비즈니스 로직을 담당하며, 데이터베이스와 상호작용하여 데이터를 저장하고, 데이터를 처리하는 역할을 합니다.
- View : 사용자에게 데이터를 표시하는 역할을 하며, 사용자가 볼 수 있는 인터페이스를 제공합니다.
- Controller : Modal View 사이의 상호작용을 관리하며, 사용자의 입력을 처리하고, 모델을 업데이트 및 업데이트된 모델을 기반으로 뷰를 다시 렌더링합니다.
하지만 프론트엔드에서 많은 View가 등장하기 시작하면서 복잡해지기 시작했습니다.
View는 때로는 Controller의 역할도 같이 수행해야 하는 상황이 생기기 시작했습니다. 예를 들어, View의 변경이 Model을 바꾸는 경우와 Model의 변경이 View를 바꾸는 경우가 발생합니다. 즉, View와 Model의 관계가 양방향으로 이루어지는 복잡한 형태가 되어버립니다.
이런 양방향 관계를 처리하기 위해 Controller의 형태는 점점 비대해지게 됩니다.
이러한 문제를 해결하기 위해 View의 잦은 리렌더링을 제어하고, 계층적인 구조를 가지면서 DOM 구조를 활용해 리렌더링을 최소화하는 방법을 찾기 시작했습니다.
이를 해결하기 위해 복잡한 View와 Model 간의 관계를 단순화하고, View 계층을 효율적으로 처리하는 것이 필요했습니다. 이러한 배경에서 등장한 것이 Flux 패턴입니다.
Flux 패턴은 데이터를 단방향으로 처리하며, 데이터의 변경을 Action과 Dispatcher를 통해 나누어 처리합니다.
- Action : 애플리케이션에서 일어나는 모든 이벤트를 설명하는 객체입니다.
View에서 발생한 이벤트는Action계층으로 전달되며ACtion계층은 발생한 이벤트에 맞게Action객체를 생성하여Dispatcher객체로 전달합니다. - Dispatcher : 액션을 받아서 스토어로 전달하는 역할을 합니다.
Action객체를 받아 필요한 비즈니스 로직을 처리하고 해당 상태를Model에 해당하는Store에 저장합니다. - Stroe : 애플리케이션의 상태를 관리합니다.
View에게 제공하기 위한 정보들을 저장하고 있으며, 저장된 정보를View에게 제공합니다.
Flux 패턴으로 단방향 데이터 흐름 처리로 데이터의 이동 경로를 예측하기 쉽고, 모든 상태 변경이 Stroe에서 중앙에서 관리되므로 상태의 일관성이 높아졌습니다.
MVC 패턴과 Flux 패턴의 비교
MVC 패턴에서는 Controller에서 데이터를 View → Modal, Model → View 양방향으로 데이터 흐름을 갖는 계층이었습니다. 따라서 Controller 계층은 View , Model 모두 신경써야 하며 , 데이터의 흐름이 양방향이라 Controller 자체가 무거울뿐더러 코드의 흐름을 파악하기 쉽지 않습니다.
Flux 패턴는 각 계층의 데이터 흐름은 단뱡으로 흐르며, 이를 통해 데이터의 이동 흐름을 예측하기 쉬우며, 일관성있게 관리할 수 있습니다.
정리
과거 MVC 패턴을 이용한 웹 개발에서는 View와 Model의 양방향 데이터 흐름으로 인해 복잡한 형태로 이루어졌으며, 이로 인해 Controller가 무거워지고 코드의 흐름을 파악하기 어려웠습니다.
이를 해결하기 위해 등장한 Flux 패턴을 통해 각 계층의 데이터 흐름을 단방향으로 처리하고, 이를 통해 데이터의 흐름을 예측하기 쉽고, 일관성 있게 관리할 수 있었습니다.
React는 Flux 패턴을 통해 컴포넌트의 상태를 일관성 있게 관리하고, 예측 가능하도록 만들었습니다.
참고 사이트
