2024.1.5 회의록

1. network 요청 시의 파라미터를 구조체로 만들어서 network에서 도메인 레이어에 대한 의존을 만들지 않고 어떻게 구현을 할 수 있었을까?

   • network 파라미터만 따로 주입할 수 있는 Interface를 생성
   • 따로 구조체를 만들지 않고 toDictionary() 함수 이용(현재 사용 방법)

2. 이전에는 서버로부터 응답받은 데이터를 Single generic 형태로 리턴을 했었는데, 현재는 Observable 제네릭으로 되어 있음. Single과 기본 Observable의 차이가 무엇일지?

   • Single은 응답 2가지(fail, success)로 떨어져서 에러 핸들링이 더 효율적
   • 현재는 응답 데이터를 Observable로 리턴받는데, Single로 받고 에러 핸들링까지 구현할 것
   • 에러 핸들링을 어디서 할 지? ⇒ Data Layer Repo에서 서버에 요청 후, 응답받은 데이터, Error로 핸들링

3. 아래 코드가 어떤 역할을 하는 지 궁금

   • Diffable DataSource 사용할 때 타입이 hashable이어야함

public struct ProfilePhotoDomain: Hashable {
    public let identifier = UUID()

    { ... }

    public func hash(into hasher: inout Hasher) {
        hasher.combine(identifier)
    }
}

4. 'LikeRepositoryInterface', LikeUseCaseInterface 동일한 로직의 두 프로토콜을 나눈 이유

   • LikeRepositoryInterface는 실제 Like 화면에 진입했을 때 서버에 요청을 보내기 위한 프로토콜
   • LikeUseCaseInterface API가 구현되지 않았을 때, 테스터블하게 사용할 수 있도록 만든 프로토콜

5. LaunchRouter > URLHandling 프로토콜은 언제 사용하는지

   • 딥링크용

6. use cace에서 protocol을 파라미터로 받을 때는 weak var로 설정 안 하는 이유

   1. 프로토콜은 테스터블하고 느슨하게 연결(모든 구현체를 다 가지고 있을 필요 없음)해서 사용하기 위함
   2. like 기능을 하는 가짜 객체를 만들어서 하고 싶을 때도 구현 가능
   3. 피처를 여러 명이 작업할 때도 mocking 한 repo를 만들 수 있음.

7. mainViewControllable -> TabBarControllable이어야 하지 않나?

   • 참고한 레포들에서 TabBar라고 명칭짓지 않음.

8. Feature > Falling이 앱 이름이랑 같은데 상관없을지?

   • Display name만 Failling이기 때문에 상관 없을 듯

9. Like > Src > Home이라고 되어있는데 LikeHome 이런식으로 하면 어떨지

   • 오케이

10. 시작할 때, splashLottieView 0.7배로 설정하신 이유?

    1. 기기 별 대응을 위함
    2. Super Class에서 색상을 주석처리해서 발생
       • TFLaunchViewController에 loadView() 함수에서 view의 background color 변경하는 방식으로 수정