탭바 모듈 구조에 대해 논의한다.

[meltsplit]

상황

• 탭바 모듈을 다른 피쳐 모듈과 일렬로 설계한다고 결정된 상황
• 일렬로 모듈 설계시 탭바 및 탭바 빌더, 탭바 코디네이터 구현체를 어떻게 설계할 지 논의가 필요
• 제가 생각한 탭바 모듈 분리시 수도 코드를 작성해봤습니다.
• 팀원분들의 의견이 궁금합니다!
• 아래 코드의 궁금한 점이나 개선할 점을 마구마구 남겨주세용

고민 지점

• 탭바 주입의 책임은 누가 지녀야 할까요?
• TabBarRegistreation을 protocol로 할까요 struct로 할까요?
  • protocol로 한다면 각 피쳐별로 이를 채택하는 struct를 만들고 빌더에서 이를 반환하고자 했음. 단 타입은 protocol로.
  • 근데 그닥 protocol의 효용이 없는 것 같아서 struct로 바꿨어요
• 특정피쳐에서 탭 스위치가 필요할 때 어떻게 구현해야할까요?
  • 구현시 의존성이 깨지는 상황은 발생하지 않을지
  • TabBarVC는 forEach문으로 등록하는데 selectedIndex를 특정할 수 있을지
  • 고유한 id값 같은게 필요할 것 같기도합니다.
• 코디네이터 로직은 크게 고려하지 않았는데 괜찮을까유~?>

수도 코드

// Root Module

class ApplicationCoordinator {
    
    func runTabBarFlow() {
        let fooTab = FooBuilder().makeTabBarRegisteration()
        let pooTab = PooBuilder().makeTabBarRegisteration()
        
        let coordinator = TabBarCoordinator(
            factory: MainTabBuilder(tabs: [fooTab, pooTab])
        )
        
        coordinator.start()
    }
}

// MainTab Module

class TabBarCoordinator {
    let factory: MainTabBuilder
    
    func start() {
        let tabVC = factory.makeTabVC()
        // 라우터 로직
    }
    
    init(factory: MainTabBuilder) {
        self.factory = factory
    }
}

class MainTabBuilder {
    private let tabs: [TabBarRegisteration]
    
    init(tabs: [TabBarRegisteration]) {
        self.tabs = tabs
    }
    
    func makeTabVC() -> TabBarController {
        return TabBarController(tabList: tabs)
    }
}

class TabBarController: UITabBarController {
    
    private let tabList: [TabBarRegisteration]
    
    init(tabList: [TabBarRegisteration]) {
        self.tabList = tabList
        super.init(nibName: nil, bundle: nil)
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        configureTabBarItems()
        configureViewControllers()
    }
    
    //MARK: - Custom Method
    
    private func configureTabBarItems() {
        tabList.forEach { factory in
            factory.rootVC.vc.tabBarItem = UITabBarItem(title: factory.title,
                                                        image: factory.image,
                                                        selectedImage: factory.selectedImage)
        }
    }
    
    private func configureViewControllers(){
        tabList.forEach { factory in
            viewControllers?.append(factory.rootVC.vc)
        }
    }
    
}

// Foo Module

class FooBuilder {
    func makeTabBarRegisteration() -> TabBarRegisteration {
        let vc = makeFooVC()
        return TabBarRegisteration(title: "Foo", image: UIImage(), selectedImage: UIImage(), rootVC: vc)
    }
    
    func makeFooVC() -> ViewControllable {
        FooVC()
    }
}

class FooVC: ViewControllable {
    let vc = UIViewController(nibName: nil, bundle: nil)
}

// BaseFeature

protocol ViewControllable {
    var vc: UIViewController { get }
}


struct TabBarRegisteration {
    let title: String
    let image: UIImage
    let selectedImage: UIImage
    let rootVC: any ViewControllable
}

[dlwogus0128]

안녕 ~~ 👋🏻 깔끔한 정리 감사합니다!

탭바 주입의 책임은 누가 지녀야 할까요?

책임 분리나 탭바 기능들을 캡슐화하는 것을 생각하면 메인탭에서 탭들을 등록해주는 게 낫겠다고 생각했는데, 저희는 ApplicationCoor가 모든 플로우를 관리하고 있으니까... 적어주신 수도 코드처럼 탭바 구성은 ApplicationCoor가 하는 게 낫지 않을까? 라고 갠적으로 생각합니다

근데 그닥 protocol의 효용이 없는 것 같아서 struct로 바꿨어요

저도 struct가 더 적절해보여요

특정피쳐에서 탭 스위치가 필요할 때 어떻게 구현해야할까요? 고유한 id값 같은게 필요할 것 같기도합니다.

enum으로 관리하면 될 것 같은데요! 좋아요

코디네이터 로직은 크게 고려하지 않았는데 괜찮을까유~?

ApplicationCoor가 있어서 괜찮을 것 같은데요 ..~?

으응 죠타~~~~~ 탭바 담당 윤서 웅니 출동!! 🤍 @yungu0010 ㅋ. ㅋ

[meltsplit]

ApplicationCoor가 하는 게 낫지 않을까

맞아요. 탭바에서 피쳐 인스턴스를 생성하면 되면 탭바가 다른 모듈들을 의존해야해서 외부에서 주입 받는 것이 더 좋다고 생각했어요. 근데 이러면 탭바가 다른 피쳐 인터페이스조차 몰라도 될 것 같기도 하네요

enum으로 관리하면 될 것 같은데요

해당 enum은 어느 모듈에 있는 게 좋을까요?

코디네이터 로직은 크게 고려하지 않았

탭바에서 FooFeature를 선택했을 때 FooFeatureCoordinator.start() 코드는 ApplicationCoord에게 맡기자는거죵?

[yungu0010]

깔끔한 정리 감사합니다~! 답변이 늦었네용. . ㅎㅎ

저도 탭바 주입의 책임은 ApplicationCoordinator에서 하고 탭바 구성은 MainTabModule에서 하는 것이 좋다고 생각합니다~!
탭바 관련 enum은 탭 바 아이템 정보라고 생각해서 탭바를 구성하는 TabBarModule에 있는게 좋다고 생각해요 !

탭바에서 FooFeature를 선택했을 때 FooFeatureCoordinator.start() 코드는 ApplicationCoord에게 맡기자는거죵?

좋네요!_! 탭바 아이템을 누른 이벤트만 ApplicationCoordinator로 전달하고 RootFeature에서 탭 바 화면전환도 관리하면 좋을 듯 합니다! 그럼 특정 피쳐 모듈에 의존하지 않아도 돼서 좋을 듯~~

그러면 탭 바 모듈이 UI구성만 하는거 아닌가? 싶어 굳이 모듈을 나눠야할까.. 라는 생각이 갑자기 들지만 . .
회원/비회원일 때 탭바 동작 방식과 추후 구현하게 될 플러스 버튼이 있어 괜찮을 것 같네요 !!

[yungu0010]

모듈 이름에 대한 의견도 궁금합니다!
논의하기 전 구조에서는 Splash와 Auth 모듈을 제외한 앱 플로우를 탭 바 모듈이 모두 관리한다고 생각해 MainTabModule이 적절하다고 생각했는데, TabBar 구성만 담당한다면 TabBarFeature이 더 나을 것 같아서요!

[meltsplit]

탭 바 모듈이 UI구성만 하는거 아닌가? 싶어 굳이 모듈을 나눠야할까

저도 동의합니다잉. 마이크로피처 아키텍처에서 피처 모듈은 각각의 "기능"을 담당해야 한다고 생각하는데,
탭바가 기능인가..? 에 대한 의문이 들어요

회원/비회원일 때 탭바 동작 방식과 추후 구현하게 될 플러스 버튼이 있어 괜찮을 것 같네요 !!
ㅇㅈㅇㅈ!

[yungu0010]

그러면 아래 방식으로 작업 진행하겠습니다~! 모두 의견 감사드려요 !!

• 탭 바 모듈 생성
• 탭 바 UI 관련 작업은 탭 바 모듈에서 진행
• 화면 전환은 루트 모듈에서 진행