왜 Flux 아키텍쳐란 개념이 나왔을까?

Facebook에서 개발한 아키텍쳐이자, 단방향 데이터 흐름을 가지는 아키텍쳐

Flux 아키텍쳐를 알기 전에, MVC 아키텍쳐에 대해서

우선 MVC 아키텍쳐는 양방향으로 데이터가 오간다.

아키텍쳐 구조를 말하자면,

1. Controller : Model의 데이터를 조회하거나 업데이트하는 역할
2. Model : 데이터를 View를 통해 반영하는 역할 (Back으로부터 받은 데이터 or Back으로 보낼 데이터)
3. View : 사용자로부터 데이터를 입력받고 보여주기도 하는 역할

이 구조가 가지는 문제점을 깨닫기 시작한 페이스북.. 🤦‍♂️

“기능을 추가하면 할수록 MVC 패턴의 복잡성이 기하급수적으로 증가한다!”

즉, 거대한 어플리케이션을 대상으로 한 프로젝트에 대해서는 너무 복잡해진다고 말한다.

사용자와의 상호작용이 ‘View’에서 일어나면서

사용자의 입력에 따라 Model을 업데이트 해주어야 하는 경우가 생기고

의존성의 이유로 한 Model 뿐만 아니라 다른 Model까지 업데이트 해야 하는 상황도 생긴다.

like pingpong game..🏓 하나의 공을 주고 받는 것은 어렵지 않지만 많은 공을 주고 받는다는 것은..?

그래서 Flux 아키텍쳐가 뭔데? 🤷🏻‍♀️

🚇 단방향 데이터 흐름을 가지는 구조

데이터는 단방향으로만 흐르고 새로운 데이터를 넣으면 처음부터 다시 시작되는 방식이다.

데이터의 흐름은 Dispatcher → Store → View → Action → Dispatcher → …

아키텍쳐 구조를 보자면,

1. Action : 기존 상태를 변경하기 위한 어떤 행동, 이 행동으로부터 넘겨받은 값들을 가진 하나의 객체 (데이터 묶음)

   // Redux
   export const setTable = item => ({
     type: SET_TABLE, // 액션 이름(어떤 액션인지를 가르킴)
     payload: item, // 넘겨받은 값
   })

2. Dispatcher : 모든 데이터의 흐름을 관리하는 일종의 허브 역할로, 액션 발생 시 디스패쳐로 메세지나 액션 객체가 전달되면 콜백 함수를 통해 스토어로 전달한다. 스토어에 접근하기 위한 일종의 단계

3. Store : 모든 액션을 받아서 적합한 액션이 어떤 건지 필터링해주고, 상태 값을 변경하고 연결된 컨트롤러 뷰에게 상태 변화를 알리는 역할이다. 상태 변경을 위한 요청을 스토어에 직접 할 수는 없다! (접근하기 힘든 당신..Store..)

4. View Controller & View : 상태를 가져와서 보여주고 사용자로부터 입력 받을 화면을 보여주는 역할이다. View Controller는 스토어와 뷰의 중간 매개체 역할이고, View는 컨트롤러 뷰에게 변화된 상태를 받아 그 상태에 따라 다시 렌더링한다.

여기서 탄생한 라이브러리, Redux 🐣

페이스북이 Flux 아키텍쳐를 발표한 후에 Flux에 대한 구현체도 같이 공개했는데, 여기에는 디스패쳐만 구현되어 있어 완전한 Flux 프레임워크라고 부르기엔 무리가 있었다. (14년도 Flux가 발표되고, 15년도 10월에 발표한 버전에서야 스토어를 지원했기 때문에 사실상 완전한 공식 Flux 구현체가 없던 셈)

이 시기에 많은 Flux 구현체들이 나타났는데, 지금까지 널리 사용되는 것 중 하나가 Redux 라이브러리이다!

기존의 Flux 아키텍쳐에 ‘Reducer’ 개념을 추가해, 상태 변경의 개념을 조금 바꿔 등장했다.

리덕스의 구조는 이렇다.

1. Action : 사용자가 요청한 액션 (기존 상태를 변경하기 위한 행동과 데이터)이며, 뷰에서 useDispatch를 사용하여 액션을 발생시킨다.

2. Reducer : Flux 아키텍쳐의 Dispatcher 대신 상태 변화 로직을 담당하는 역할로, 전체 리듀서를 관리하는 Root Reducer가 있고 하위 Sub Reducer가 있다. 여기서 Redux의 키포인트는 💡 이전 상태 자체를 변경하지 않고 상태를 복사한 다음 상태를 변경한다는 것

3. Store : Flux 아키텍쳐의 스토어는 다수의 스토어가 존재하는데 비해 리덕스에서는 단 하나의 스토어를 가지며, 상태 트리라고 불리는 상태 값을 유지한다.

4. View : 스토어와 뷰를 연결해놓은 Provider Component를 통해 스토어가 뷰에 상태를 공급한다.

   

✨ 정리

• 요즘 리액트는 Flux 아키텍쳐가 점령했기 때문에(👽) 꼭 살펴봐야 하는 개념이었다..
• 프로젝트의 크기에 따라서 상태 값이 많지 않다면 꼭 Redux를 사용하지 않고 리액트의 Context API와 useReducer와 같은 기능을 사용할 수도 있지만, 프로젝트 크기가 점점 커지고 복잡함이 늘어나면 Redux를 사용하는 편이 프로젝트 상태들을 관리하는데 있어서 더 좋을 것 같다 😎
• 프로젝트를 진행하면서 리덕스를 코드로 접하고 구현만 해봤지, 어떻게 만들어졌는지, 이게 FLUX 아키텍쳐에서 파생된 라이브러리인지 알지도 못한 채 쓰고 있었다. 이제서야 조금 알게 되었으니, 앞으로 리덕스의 개념을 더 확실하게 설명할 수 있는 그 날까지 공부를 열심히 해야겠다.

---

참고 내용

FLUX 아키텍쳐란?

Flux와 Redux에 대한 이해