RxFlow 학습 정리

RxFlow 학습 정리

최근에 오픈소스 열풍이 불고 있는거 같은 느낌임.

오픈소스나 특정한 외부 규칙 없이도 적절하게 분리해서 개발을 잘 하고 있다고 생각했는데, 취업 요건에 하나 둘 추가되면서 학습해두고자 함.

 

최근에 사이드 프로젝트를 수행하면서 Coordinator Pattern을 활용해 화면 전환 방식을 설계 했음.

해당 프로젝트는 SwiftUI 일부 섞어서 사용하고 있어서 UIHostringController를 사용하고 있고, UIKit 기반으로 ReacotorKit을 활용하고 있음.

 

또한 RxSwift가 매우 익숙한데 최근에 Combine이 핫하다고 해서 보니까 RxSwift랑 오퍼레이터들이 대부분 비슷해서 학습을 위해 따로 투자할 정도는 아닌거 같음.

일부 오퍼레이터들이 이름이 같은데 약간 다른 동작성을 가진게 존재하고 Combine이 RxSwift랑 Demand?? 이 부분에서 처리 방식에 약간 차이가 있는거 같은데 사용하면서 하나 둘 알아가도 크게 문제 안될거 같음.

무엇보다도 Swfit Concurrency가 더 발전하면 Combine을 사용할 이유가 없는거 같아서 Combine은 조금 가볍게 지나가고자 함.

아 그리고 TCA를 많이 보고 있는데 RxFlow 사실 사용할 일 크게 없을거 같고, 이거 나중에 걷어내는 비용이 더 클거 같다는 생각이 들지만 학습이라고 생각하고 정복해보고자 함.

 

그래도 아직은 RxSwift 기반으로 작성하는 코드가 편하고, 화면전환에 있어서 RxSwfift는 RxFlow랑 잘 맞는다고 생각함.

 

오픈소스 링크

https://github.com/RxSwiftCommunity/RxFlow

GitHub - RxSwiftCommunity/RxFlow: RxFlow is a navigation framework for iOS applications based on a Reactive Flow Coordinator pat

 

 

Navigation concerns

요약하자면, 코드로 화면전환(커스텀 메커니즘)을 수행할 경우 디자인 패턴에(Coordinator, Router)에 따라 코드를 설정하기 어렵다는 문제가 있다고 함.

Regarding navigation within an iOS application, two choices are available:

• Use the builtin mechanism provided by Apple and Xcode: storyboards and segues
• Implement a custom mechanism directly in the code

The disadvantage of these two solutions:

• Builtin mechanism: navigation is relatively static and the storyboards are massive. The navigation code pollutes the UIViewControllers
• Custom mechanism: code can be difficult to set up and can be complex depending on the chosen design pattern (Router, Coordinator)

 

 

 

RxFlow 목적

요약하자면, RxFlow는 손쉽게 종속성 주입이 가능하고 모든 UIViewController에서 화면전환 메커니즘을 제거할 수 있음.

또한, 반응형 프로그래밍 및 선언적으로 방식으로 사용할 수 있게 되며, 논리 단위로 쉽게 나눌 수 있음.

• Promote the cutting of storyboards into atomic units to enable collaboration and reusability of UIViewControllers
• Allow the presentation of a UIViewController in different ways according to the navigation context
• Ease the implementation of dependency injection
• Remove every navigation mechanism from UIViewControllers
• Promote reactive programming
• Express the navigation in a declarative way while addressing the majority of the navigation cases
• Facilitate the cutting of an application into logical blocks of navigation

 

 

 

The key principles

There are 6 terms you have to be familiar with to understand RxFlow:

• Flow: each Flow defines a navigation area in your application. This is the place where you declare the navigation actions (such as presenting a UIViewController or another Flow).
• Step: a Step is a way to express a state that can lead to a navigation. Combinations of Flows and Steps describe all the possible navigation actions. A Step can even embed inner values (such as Ids, URLs, ...) that will be propagated to screens declared in the Flows
• Stepper: a Stepper can be anything that can emit Steps inside Flows.
• Presentable: it is an abstraction of something that can be presented (basically UIViewController and Flow are Presentable).
• FlowContributor: it is a simple data structure that tells the FlowCoordinator what will be the next things that can emit new Steps in a Flow.
• FlowCoordinator: once the developer has defined the suitable combinations of Flows and Steps representing the navigation possibilities, the job of the FlowCoordinator is to mix these combinations to handle all the navigation of your app. FlowCoordinators are provided by RxFlow, you don't have to implement them.

 

필요한 부분만 추려서 정리하자면

 

• Flow : 각 Flow 는 애플리케이션의 화면전환 영역을 정의. 화면전환 작업(예: UIViewController 또는 다른 Flow 표시)을 선언하는 위치
• Step : Step은 내비게이션으로 이어질 수 있는 상태를 표현하는 방법입니다. Flows 와 Steps 의 조합은 가능한 모든 탐색 작업을 설명합니다. Steps in Flow 에서 선언된 화면으로 전파될 내부 값(예: ID, URL 등)을 포함할 수도 있음
• Stepper : Stepper 는 흐름 내에서 Step 를 내보낼 수 있는 모든 것이 될 수 있음.
• Presentable : 표현될 수 있는 것의 추상화하여 사용(기본적으로 UIViewController 및 Flow 는 Presentable 임).
• FlowContributor : Flow 에서 새 Steps 를 내보낼 수 있는 다음 항목이 무엇인지 FlowCoordinator 에 알려주는 간단한 데이터 구조.
• FlowCoordinator : 개발자가 화면전환 가능성을 나타내는 Flows 과 Steps 의 적절한 조합을 정의하면 FlowCoordinator 의 작업은 이러한 조합을 혼합하여 앱의 모든 화면전환을 처리하는 것입니다. FlowCoordinator 는 RxFlow에서 제공하므로 구현할 필요가 없음

 

 

결론

이거 생각보다 많이 간단해서 코드로 정리할 필요는 없고, 사이드에 바로 적용하기에도 문제가 전혀 안되었음.

트리 기반 화면 전환 방식과 스택 기반 화면 전환 방식을 섞어서 쓰면 좋을거 같음.

 

Coordinator 패턴이 트리 기반으로 보이는데 이거 생각보다 서비스 정책이 트리 구조에서 벗어나면 정책을 대응하기 어려워서 이거 단점이 너무 크다고 느낌.

 

개인적으로는 스택 기반 화면전환 방식을 메인으로 사용하고, 경우에 따라 트리 구조가 필요한 경우 서브로 코드로 녹여내는게 제일 좋지 않을까 싶다.