[React] Redux 사용하기전 알아야할 Flux 개념

Front-End에 사용되는 프레임워크의 대부분은 MVC(Model-View-Controller) 디자인 패턴을 채택했었습니다. 그런데 MVC 패턴이 명확하게 보여지면서 Flux 아키텍쳐가 등장하게 되었습니다. 우선 MVC 모델을 우선 살펴볼게요.

MVC 패턴에서 컨트롤러(Controller)는 모델(Model)의 데이터를 조회하거나 업데이트하는 역할을 하며, 모델(Model)의 값인 뷰(View)에 반영됩니다. 그리고 뷰를 통해 데이터를 입력하면, 즉각 모델에 영향을 주면서 데이터를 관리하게 됩니다.

문제는 대규모 애플리케이션의 경우 MVC가 너무 빠르고 복잡해 진다는 점에 있습니다. 그래서 코드 예측이나 테스트의 어려움, 유지보수 비용 증가 등 여러가지 문제가 발생한 것입니다. 가장 대표적인 사례로 페이스북의 안 읽은 글 갯수 표시인데, 사용자가 읽지 않았던 글을 읽으면 그만큼 숫자를 빼는 단순한 기능임에도, MVC로 구현하게 되었을때 모델별로 데이터를 가지고 있는게 달랐기 때문에 이것들을 싱크하거나 동시 업데이트 해야해서 매우 불편한 관계가 있엇던 것이죠.

그래서 페이스북 개발팀은 MVC를 버리고 Flux 아키텍처를 적용하기로 합니다.

Flux 란?

Flux는 MVC의 문제를 해결할 목적으로 고안한 애플리케이션 아키텍쳐입니다. Flux 애플리케이션은 디스패처(Dispatcher), 스토어(Store), 뷰(View) 등 세 부분으로 구성됩니다. 여기서 말하는 뷰는 단순히 화면에 보여지는 것을 넘어 자식 뷰로 전달도 하는 컨트롤 역할도 병행합니다. 그래서 컨트롤러 뷰 라고 불리기도 합니다.

Flux 아키텍처의 큰 특징은 단방향 데이터 흐름(unidirectional data flow)입니다. 데이터 흐름은 디스패처 => 스토어 => 뷰 로 흘러가며 뷰에서 입력되는 데이터가 발생하면 액션(Action)을 이용해 디스패처로 향하도록 합니다. 

이러한 흐름의 장점은 데이터를 직접 수정할 수 없고 반드시 액션을 통해서만 수정이 일어나기 때문에 교통정리가 가능해 진다는 점입니다. 

개략적인건 이정도로 넘어가고 각 구성별 역할을 알아보겠습니다.

디스패처(Dispatcher)

디스패처는 Flux 애플리케이션의 모든 데이터 흐름을 관리하는 허브 역할을 합니다. 액션이 발생하면 디스패처로 메세지나 액션 객체가 전달되고 디스패처에서는 등록된 콜백함수를 통해 이 메세지를 스토어에 전달합니다. 다른 구성요소와 달리 디스패처는 전체 애플리케이션에서 한 개의 인스턴스만 사용합니다.

스토어(Store)

스토어는 애플리케이션 상태를 저장합니다. MVC 패턴과 유사하지만 애플리케이션의 특정 도메인에 해당하는 상태를 다룬다고 보면 되겠습니다. Flux의 스토어는 상태를 다루기 때문에 무엇이든 저장할 수 있고 단순한 Object로 구성되어 있습니다. 스토어는 마치 정부관료와 같다고 표현하기도 하는데요, 모든 상태변경은 스토어에 의해서 결정되어야만 하며, 상태변경을 위한 요청을 스토어에 직접 보낼 수 없습니다. 즉 무조건 액션 생성자를 통해 디스패처를 통해 액션을 보내야먄 수정이 가능해집니다.

액션(Action)

디스패처 특징 메소드를 실행하면 스토어에 변화를 일으킬 수 있습니다. 이때 이 데이터 묶음을 액션이라 하고, 전달할 액션 객체는 액션 생성자라는 함수를 통해 만들어집니다. 뷰에서 액션생성자(Action creator)를 실행하여 전달할 메세지을 생성하고, 디스패처에 전달하여 스토어에 저장되어 있는 상태를 변경하는 것입니다.

뷰(View) 또는 컨트롤러 뷰(the Controller view)

상태를 가져와서 보여주고 입력받을 화면을 보여줄 역할을 맡습니다. 컨트롤러 뷰는 스토어와 뷰 사이의 중간관리자같은 역할을 하며, 상태가 변경되었을 때 스토어가 그 사실을 컨트롤러 뷰에게 알려주면, 컨트롤러 뷰는 자신 아래에 있는 모든 뷰에게 새로운 상태를 넘겨줍니다.

위의 구성을 토대로 초기화 할 때 한번의 준비과정을 가집니다.

준비단계(the setup)

1. 스토어는 디스패처에게 액션이 들어오면 알려달라고 말해둔다.

2. 컨트롤러 뷰는 스토어에게 최신 상태를 묻는다.

3. 스토어가 컨트롤러 뷰에게 상태를 주면 렌더링을 하기 위해 모든 자식 뷰에게 상태를 넘겨준다.

4. 컨트롤러 뷰는 스토어에게 상태가 바뀔때 알려달라고 다시 부탁한다.

위의 준비과정이 끝난 후, 입력받았을 때 데이터 흐름을 살펴보겠습니다.

데이터의 흐름(the data flow)

1. 뷰는 액션 생성자에게 액션을 준비하라고 말합니다.

2. 액션 생성자는 액션을 포멧에 맞게 만들어서 디스패처에 넘겨줍니다.

3. 디스패처는 들어온 액션의 순서에 따라 알맞은 스토어로 보냅니다. 각 스토어는 모든 액션을 받게 되지만 필요한 액션만을 골라서 상태를 필요하게 맞게 변경합니다.

4. 상태 변경이 완료되면 스토어는 자신을 구독(subscribe)하고 있는 컨트롤러뷰에게 그 사실을 알립니다.

5. 연락 받은 컨트롤러 뷰들은 스토어에게 변경된 상태를 요청합니다.

6. 스토어가 새로운 상태를 넘겨주면, 컨트롤러 뷰는 자신 아래의 모든 뷰에게 새로운 상태에 맞게 랜더링하라고 알립니다.

아래 사이트를 참조하시면 많은 도움이 됩니다.

참조사이트:

Flux로의 카툰 안내서

https://bestalign.github.io/2015/10/06/cartoon-guide-to-flux/