unnnyong

iOSアプリ設計パターン入門 의 Flux에 관한 내용을 대부분 참고한 95%의 번역글입니다.
번역 글의 모든 권한은 저에게 없습니다 🙏

---

Flux?

https://facebook.github.io/flux/

Flux는 Facebook의 기술 컨퍼런스인 F8에서 발표되어서
Facebook WEB 앱에서 사용되고 있는 GUI 아키텍쳐예요.

Flux는 라틴어의 Fluxus(Flow, 흐름)을 어원으로
데이터의 흐름이 단일방향인 것이 특징으로 만들어진 아키텍쳐입니다.

React에서 많이 사용되는 Redux도 Flux를 활용한 패턴이죠.

단일 방향 데이터 흐름 (단일방향 Data flow)

위의 흐름도를 보면 Action부터 View까지 데이터가 한 쪽 방향으로만 흐르고 있어요.
Action, Dispatcher, Store, View의 4가지 구성요소가 존재해요.

Action : 실행하는 관리를 특정하기 위한 type과 실행하는 관리를 연결하는 data를 가지는 Object
Dispatcher : Action을 받으면 자신이 등록된 Store에 전달.
Store : state를 가지고 Dispatcher로부터 전해진 Action의 type과 data를 따라서 상태를 변경.
View : Store의 state를 구독하고, Store의 state의 변화에 따라 화면을 업데이트.


Dispatcher에 Action을 주입시키는 것부터 데이터흐름이 시작되고,
Dispatcher는 Action을 Store에 전달해요.
Store는 받은 Action을 기반으로 자신의 상태를 업데이트하고
Store의 상태를 구독(subscribe)하고 있던 View가 상태 변화에 따라 화면을 업데이트합니다.

단일 방향은 Flux 아키텍쳐에서 절대적인 것이라서 반대로 View에서 Store를 직접 변경하는건 안돼요 🤢

View 에서 시작되는 단일방향 데이터 흐름

View에서 Store로 직접 변경하는게 불가능하기 때문에
View는 Dispatcher에게 Action을 넘기는 걸로 Store에 무언가를 알릴 수 있습니다.

유저에게 터치(혹은 무언가의 입력)을 받은 View는 입력을 Action으로 만들어서 Dispatcher에게 전하고,
Dispatcher는 받은 Action을 Store까지 전달해요.
Store에서는 Aciton을 통해 상태가 변경되고,
그 Store의 상태를 구독하고 있는 View의 화면이 업데이트 됩니다.

View에서 시작된 데이터 흐름이 시작되었다고 해도,
Dispatcher가 중심점이 되어서 데이터 흐름을 단일방향으로 구현하는게 가능해요 !




Flux 아키텍쳐는 Action, Dispatcher, Store, View의 4가지 구성요소와
데이터 흐름이 단일방향이라고 하는 제약으로 구성되어있어요.

---

iOS 어플리케이션에서
Flux를 사용할 때의 구성과 데이터 흐름

View의 구성과 데이터 흐름

그림의 아래 쪽의 초록색 계열의 부분이 View 구성요소의 데이터 흐름이에요.
iOS의 경우, View는 UIViewController, UIView가 되어요. (SwiftUI에서는 View)


View → 🔥🔥 = UserInteraction → → → Store (🔥)
View에서 데이터 흐름이 시작되는 User Interaction == 유저의 터치(입력)
View가 상태를 갖으면 안돼요 !!!!!!! 유저가 Action을 만들어서 Store로 전달해서 Store가 갖도록 해야해요.

Store(🔥🔥) → → → View
View로 향하는 데이터 흐름은 Store의 상태를 View가 반영하기 위한 데이터 흐름.
Store의 상태는 RxSwift, KVO, NotificationCenter로 (구독을 통해) 받게 된다.

Action의 구성과 데이터 흐름

Action Creator의 역할
– 무언가의 실행을 하고, 그 결과로부터 Action을 만든다.
– 만들어낸 Action을 Dispatcher로 보내기.


Action Creator와 함께하는 데이터 흐름
1. View에서 발생한 UserInteraction의 처리를 ActionCreator에서 실행한다.
2. ActionCreator는 Web API Util을 통해 Web API로 통신하고, 통신결과를 Action으로 만들고 Dispatcher 에게 전달한다.


Action Creator는 필수인가
아님다 ! 🙅‍♂️
View가 Action을 직접 Dispatcher에 줄 때도 있지만 Action을 만드는 일까지 UIViewController(UIView)가 해야해서 UIViewController가 거대져버려서 잘 생각해서 구성해야해요.
반대로 간단 UIViewController라면 적절하게 사용하는게 좋겠지요 !

Dispatcher의 구성과 데이터 흐름

Dispatcher는 ActionCreator가 만들어준 Action을 받아서 Store에 전달해주는 친구죠

하나의 App에는 하나의 Dispatcher만 존재할 수 있답니다
– App과 동일한 LifeCycle로 존재하거나 Singletone 으로 존재하는 경우가 많아요


Dispatcher가 Action을 Store에 전달하는 방법
0. Dispatcher에 register(callback:) 함수가 존재.
1. register 함수를 Store에서 불러서 Callback을 등록하고 Action을 (구독)받는다.

ActionCreator가 Dispatcher에게 Action을 보내기.
0. Dispatcher에 dispatch(_:) 함수가 존재.
1. dispatch(_:) 함수를 ActionCreator가 사용.

ActionCreator → dispatch(🔥) → Dispatcher(🔥🔥) → callBack(🔥) → Store[🔥]

Store의 구성과 데이터 흐름

Store는 Dispatcher로부터 Action을 받아서 Action의 type과 data로 자기자신을 업데이트해요.
업데이트된 Store는 최종적으로 View에 반영되어요.

Store는 Dispatcher의 register 메소드로 Callback을 등록하고,
Store는 Callback으로부터 Action을 받습니다.
새로운 Action으로 Store에 변화가 있을 때에는 구독되어있는 View에게 알려쥬죠.


Store는 Dispatch와 다르게 여러개가 존재할 수 있어요.

Store의 초기화, register 타이밍과 Dispatcher에서 Action를 보내는 타이밍에 주의해야해요 !
타이밍이 맞지않으면 아무리 좋은 Action을 보내더라도 Store가 받을 수 없답니다 😓

iOS App 에서의 Flux 구성과 데이터 흐름

---

장점

• 데이터 흐름이 단일 방향이기 때문에 흐름의 추측이 가능하다.
• View, Action, Dispatcher, Store의 역할이 나뉘어져있기 때문에 어디서 실행되어야하는 일인지 파악하기 쉽다.
• Dispatcher가 App의 중심(허브)이기 때문에 테스트 결과, 테스트 Mock 데이터 주입이 간단하다.
• 앱이 거대해져도 확장성이 있다.

단점

• Action을 Dispatch할 때, Store가 아직 생성되지 않는 경우가 있으므로 Store의 LifeCycle을 신경쓸 필요가 있다.
• 앱의 규모가 커질수록 Action도 거대해진다.
• Store를 변경하기 위해서는 Action을 생성해서 Dispatcher를 통과해야만해서 때에 따라서 번거로울때가 있다.
  
  
  
  

---

원래부터가 웹 중심으로 만들어진 아키텍쳐다보니
iOS에서 사용하는 Flux에 대한 최신 한글 자료가 없었어서 번역 자료가 되어버렸네요.

Flux는 ReactorKit의 기반이 되는 내용이라 한 번 정리해보고 싶었어요.

이 글에서 정리된 글을 바탕으로 다음 글에서는 Flux 를 사용한 토이프로젝트를 만들어봅니다 💪


오늘도 즐거운 iOS 개발 되세용