React의 Flux 아키텍쳐

Front-End에 사용되는 프레임워크의 대부분은 MVC(Model-View-Controller) 디자인 패턴을 채택했다. 그런데,

MVC패턴이 명확하게 보여지면서 Flux아키텍쳐가 등장하게 되었다.

1) Q. 그럼 React는 MVC 프레임워크일까?

A. React는 MVC 프레임워크는 아니고 View만 신경쓰는 라이브러리이다.

음..리엑트는 페이스북과 인스타그램에서 사용자 경험을 향상하기 위해 만든 라이브러리이다.

React의 작동 및 구성

• 이벤트 요청 시 서버에서 코드를 받아 다시 렌더링해야 하는 문제를 해결하기 위해 만들어졌다.
• 프레임워크가 아니다. 사용자 인터페이스 라이브러리이다.
• UI컴포넌트를 만드는 일만 한다. MVC와 달리 그저 뷰만 신경쓴다.
• 캡슐화를 잘 시켜줘서 재사용성이 높다.
• 그래서 React를 사용하기 위해서 기존 코드를 모두 바꿀 필요 없이 필요한 부분부터 조금씩
  사용 가능하다.
• 다른 웹 프레임워크와는 달리 Ajax, 데이터 모델링, 라우팅 같은 것이 없다.
• React는 단방향 데이터 흐름으로 데이터 변경에 관한 DOM객체만 변경해주는 체계이다.
  데이터가 변경되면 양방향 데이터 바인딩처럼 모델 변경 -> 뷰 변경이 아니라
  특정 함수를 실행시킴으로써 DOM객체를 갱신한다.

2) React는 왜 MVC프레임 워크가 아니지?

페이스북은 MVC는 확장이 어렵고 거대한 시스템에 어울리지 않는다고 결론을 내렸다.

대규모 애플리케이션의 MVC 패턴 적용 시 단점

• 너무 빠르고 복잡해진다.
  (새로운 기능 추가시 시스템의 복잡도 증가)

• 그래서 코드 예측이나 테스트(테스트 코드)의 어려움

• 유지보수 비용 증가 등 문제 발생

• ex) 페이스북의 안 읽은 글 갯수 표시 사례,
  -> 사용자가 아직 읽지 않은 글을 읽으면 그만큼 갯수를 빼는 단순한 기능이지만,
  이를 MVC로 구현하게 되었을 때 모델별로 데이터를 가지고 있는게 달라서 싱크하거나 업데이트 해야 하므로 매우 불편했다.

• 모델과 뷰의 수가 커지고 데이터의 흐름이 양방향으로 이루어질 수록
  복잡도는 더욱 증가하고 디버깅 및 코드를 이해하기 어려워진다.

페이스북의 결론: MVC는 작은 앱에 어울린다.

그렇다면, React의 MVC 패턴 대안은?

좀 더 예측 가능하도록 코드 구조화에 대한 목표로

데이터 흐름이 단방향인 시스템 아키텍쳐 Flux를 제안한다.

3) Flux?

MVC의 단점을 해결할 목적으로 고안한 애플리케이션 아키텍쳐이다.

FLux의 요점은 단방향 데이터 흐름(undirectional data flow)을 적용하고 기존 패턴의 복잡성을 줄이는 것이다.

Flux 애플리케이션은 디스패처(Dispatcher), 스토어(Store), *뷰(View)등 세 부분으로 구성된다.

*여기서 말하는 뷰는 단순히 화면에 보여지는 것을 넘어 자식 뷰로 전달도 하는 컨트롤러 역할도 병행한다. 그래서 뷰 또는 컨트롤러 뷰 라고 부른다.

• 단방향 데이터 흐름: 데이터는 단방향으로 흐르고 데이터 계층이 자기가 영향을 미치는
  View 업데이트 완료 후 다음 작업을 진행한다.
  단방향 데이터의 흐름은,
  디스패처 -> 스토어 -> 뷰 로 흘러가며, 뷰에서 입력되는 데이터가 발생하면
  액션(Action)을 이용해 디스패처로 향하도록 한다.

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

Flux의 구성

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

• Store: 스토어는 애플리케이션 상태를 저장한다.
  MVC패턴과 유사하지만 애플리케이션의 특정 도메인에 해당하는 상태를 다룬다.
  Flux의 스토어는 상태를 다루기 때문에 무엇이든 저장할 수 있고 단순한 Object로 구성되어 있다. 모든 상태변경은 스토어에 의해 결정되어야만 한다.

• View(뷰, 컨트롤러 뷰): 상태를 가져와서 보여주고 입력받을 화면을 보여주는 역할.
  Store가 변경된 경우 같이 변경된다.

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

Flux 아키텍처의 큰 특징은 단방향 데이터 흐름(*undirectional data flow)이다.

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

준비단계(the setup)

1. 스토어는 디스패처에게 액션이 들어오면 알려달라고 말해둔다.
2. 컨트롤러 뷰는 스토어에게 최신 상태(State)를 묻는다.
3. 스토어가 컨트롤러 뷰에게 상태를 주면 렌더링을 하기 위해 모든 자식 뷰에게 상태를 넘겨준다.
4. 컨트롤러 뷰는 스토어에게 상태가 바뀔때 알려달라고 다시 부탁한다.

위의 준비과정이 끝난 후, 입력을 받았을 때 데이터 흐름

데이터 흐름(the data flow)

1. 뷰는 액션 생성자에게 액션을 준비하라고 말한다.
2. 액션 생성자는 액션을 포멧에 맞게 만들어서 디스패처에 넘겨준다.
3. 디스패처는 들어온 액션의 순서에 따라 알맞은 스토어로 보냅니다.
   각 스토어는 모든 액션을 받게 되지만 필요한 액션만을 골라서 상태를 필요에 맞게 변경한다.
4. 상태 변경이 완료되면 스토어는 자신을 구독하고 있는 컨트롤러뷰에게 그 사실을 알린다.
5. 연락 받은 컨트롤러 뷰들은 스토어에게 변경된 상태를 요청한다.
6. 스토어가 새로운 상태를 넘겨주면, 컨트롤러 뷰는 자신 아래의 모든 뷰에게 새로운 상태에 맞게 랜더링하라고 알린다.

참고
https://blog.gaerae.com/2016/04/hello-react.html
https://lemontia.tistory.com/637
https://brunch.co.kr/@eight-two-five/14
https://react.vlpt.us/basic/04-jsx.html