리액트의 단방향 데이터 흐름 패턴

---

useReducer 에 대해서 알아보기전에 리액트의 단방향 데이터흐름 패턴에 대해서 간단하게 살펴보자.

Flux 아키텍처란?

페이스북에서만든 데이터 흐름 패턴으로, 데이터의 단방향 흐름을 파악하여 상태관리를 쉽게 할 수 있도록 이해를 높여준다.

Flux 아키텍처 구성요소

1️⃣ 액션 (Action)

• 사용자의 입력이나 이벤트가 해당됨
• 예: 버튼클릭, 데이터 추가 등

2️⃣ 디스패처 (Dispatcher)

• 모든 액션을 받아 스토어에 전달하는 중간 관리자역할
• 함수가 위치하는 곳

3️⃣ 스토어 (Store)

• 실제 데이터와 상태를 저장하는 곳
• 디스패처로부터 받은 액션을 데이터로 변경 액션 → 데이터

4️⃣ 뷰 (View)

• 사용자에게 보여지는 화면
• 스토어에서 받아온 데이터를 화면에 렌더링

Flux 아키텍처를 바탕으로 데이터가 어떻게 한 방향으로 흐르는지 살펴보면 다음과 같다.

Flux 아키텍처 데이터 흐름

사용자 입력
   ↓
Action : { type, payload } 객체 구성
   ↓
Dispatcher : Action 전달
   ↓
Store : 전달된 Action으로 데이터 변경
   ↓
View : 변경된 데이터로 다시 렌더링

[사용자 입력] → [Action] → [Dispatcher] → [Store] → [View]

디스패처라는 단어를 보니 디스패치 가 생각이 나면서...
데이터 흐름을 조금 더 쉽게 이해하기위해 나는 이렇게 비유해서 이해해보았다.

단계	비유
액션 (Action)	사건 발생(예를들면 열애설)
디스패처 (Dispatcher)	디스패치 기자가 사건정보를 수집
스토어 (Store)	정보를 전달받은 방송국, 기사를 쓰기시작
컨트롤러 뷰(Controller View) & 뷰 (View)	인터넷에 기사가 올라가고 확인가능한 상태가 됨

위 비유는 단순히 각 단계를 이해하기위한 내용이고, 애플리케이션의 데이터 흐름관점으로 단계를 살펴보면 다음과 같다.

먼저, 애플리케이션이 초기화될 때 첫 번째 준비과정을 거친다.

1. 스토어 → 디스패처 : "액션이 들어오면 알려줘!"
2. 컨트롤러 뷰 → 스토어 : "업데이트된 최신 상태있어? 이거 맞아?"
3. 스토어 → 컨트롤러 뷰 : "여기 업데이트된 최신 상태가 있어! 전달할게!"
4. 컨트롤러 뷰 → 뷰 : "(자식)뷰들아, 최신 상태 전달할게 받으렴"
5. 뷰 : "전달받은 최신 상태를 렌더링 해볼까나"

위와같은 준비과정이 끝나면 애플리케이션은 사용자 입력을 받아들일 준비가 완료된 것이다.

🪄 이제 사용자 입력을 통해 액션(Action)이 발생했을 때의 데이터 흐름을 살펴보자.

1. 사용자 입력 발생!
2. 뷰 → 액션 : "준비해! (레뒤)"
3. 액션 → 디스패처 : "여기 사건(액션)이 발생했어!"
4. 디스패처 → 스토어 : "(전달된 액션 순서대로) 여기 발생한 액션 전달할게~"
5. 스토어 : "(필요한 액션만 골라서) 보자보자 상황에 맞게 좀 바꿔볼까"
6. 스토어 → 컨트롤러 뷰 : "나 구독하고 있지? 여기 니가 필요할만한 것들을 모아봤어. 선물이야😎"
7. 컨트롤러 뷰 → 뷰 : "자, 업데이트된 데이터(상태)가 들어왔어! 상태에 맞게 화면 렌더링 시작하자구"
8. 뷰 : "업데이트된 데이터(상태)로 렌더링을 시작하지"

리액트는 이러한 Flux 아키텍처의 원리를 활용하여 복잡한 상태관리를 하는 훅인 useReducer 를 제공한다.

다음 글에서는 복잡한 상태를 관리하는 훅인만큼 조금은 복잡한 useReducer 에 대해서 살펴보자!

---

정리하자면,

Flux 아키텍처의 전체 흐름
1. 사용자 요청 → 액션 생선
2. 액션을 디스패처에 전달
3. 디스패처가 액션을 스토어에 전달
4. 스토어가 상태 업데이트 및 콜백 실행
5. 뷰가 상태 변경 감지 및 상태 전달요청
6. 뷰가 전달받은 새로운 상태로 리렌더링

---

🔗 참고자료
https://facebookarchive.github.io/flux/
https://www.youtube.com/watch?v=i__969noyAM&t=125s