[Clone/Instagram] 🚩 LoginController MVVM 리펙터링(에러처리, clean code) with combine | LoginController Code Review 🖋️ | 마주한 에러 & 개선해야 할 기능 & 느낀점 & #13

[Yang seung hyun]

TODO: 이번엔 Never인 경우는 없다는 생각으로 LoginController 리펙터링.

구현 영상

---

간단한 LoginController 코드 리뷰 ( 시험 끝나도 까먹지 않기 위해.. )

👋 TODO: 사용자가 로그인 하는 과정을 컴바인으로 구현 with mvvm pattern + DI(Dependency Injection). 이때 발생할 수 있는 모든 오류 throws -> 처리.

• LoginController

• LoginViewModelProtocols

• LoginViewModel

사용자의 로그인 기능, 화면과 관련있는(회원가입 빼고!!) 소스코드는 위에 있는 단 3개로 구성했다.

1. LoginController에 관해 (LoginController Link)

• input/output pattern. DI

구현영상 초기 화면에서 보듯 LoginController의 view는 2개의 textfield(id, pw 입력) login button으로 구성되된다. RxSwift에서 MVVM 패턴을 사용할 때 input/ output pattern을 이용한다. 이를 이용하면 Dependency Injection(DI) 또한 가능하다. LoginController가 초기화 될 때 반드시 LoginViewModelType로 초기화 함으로 DI했다.

• input/output implement with error handling

LoginController는 viewModel을 사용할 때 많은 함수가 필요 없다. 그저 input, ouput을 바인딩 하기만 하면 된다. 따라서 LoginController에서는 viewModel 변수를 통해 transform 단 한개의 함수만 실행하도록 했다. 왜? input/output pattern을 통해서 LoginController에서 발생되는 모든 view의 Event flow handling을 viewModel에서 하기 때문이다.

• render(in:)

한가지 더! LoginController에서 주시할 함수는 render함수이다. LoginController에서 발생한 각각의 이벤트에 대해서 viewModel의 transform(input:) 함수를 통해 특정 publisher의 chains 함수를 통한 흐름 처리 이후에 값을 output로 받는다.

이때의 output 종류는 LoginControllerState에 따른 3가지가 있다. 주 역할은 view의 상태 변화를 위한 output을 enum으로 정의한 것 뿐이다. 그저 state에 따라 view의 상태 변화를 실행하면 된다.

2. LoginViewModelProtocols에 관해 (LoginViewModelProtocols Link)

LoginViewModel을 설명하기 전에 위의 protocols를 보면서 작업하면 편하다. 맨 처음에 delegate가 있는데 추후 없앨 계획이다. (델리게이트 때매 꼬이는 느낌이..)

• viewModel's all error type

LoginController의 upstream input로 오는 각각의 publisher에 대해 stream operator chains를 수행할 때 발생 할 수 있는 모든 오류를 정의했다. 맨 위 제목에서 보듯 Never타입이란 없다고 가정하고 발생할 수 있는 모든 에러에 대한 처리를 하고 싶었기에 정의 했다. 원래는 콘솔창에 단순한 출력이 아닌 특정 case에 따른 알림 or 다른 화면으로 이동해 다시 특정 로직을 수행하는 로직을 구현해야 한다. 방학때.. 할 것이다.

그래서 LoginController의 input, output publisher의 failure타입은 전부 LoginViewModelErrorType가 된다. ( 제네릭값들을 typealias로 바꾸면 얼마나 좋을까 찾아봤는데 없었다 ㅋㅋ,,)

// 여담

한가지 느낀점은 c언어로 테트리스 만들었을 때 각각의 enum은 숫자의 값만 갖을 수? 있었는데 swift는 특정 case자체를 string으로반환하거나 각각의 case에 대해 특정 타입으로 반환하는게 진짜 매력인듯 하다.

• LoginViewModelInput

다음은 LoginController에서 발생할 수 있는 이벤트들을 struct로 정의한 것이다. 이 각각의 publisher가 publised될 경우 viewModel에선 특정 input의 publiser에 대한 upstream publisher's operator chaining을 수행한 후 output으로 반환한다.

• LoginViewModelInputCase

다른 건 없다. 각각의 input's upstream publisher에 대한 결과 처리를 stream의 형태로 처리하는 실질적인 함수들이다. 이때 protocol로 구현한 이유는 코드를 모듈화 시켜 transform(input:)함수의 로직을 읽을 때 이해하기 쉽게 하기 위해서 그렇다. 물론 내가 생각한게 아니다.(언젠간 나만의 규칙을 꼭 만들 것이다... 대중적으로 인정받으면 좋고,,) (링크) 요기에서 보이는 책의 저자가 많은 세월을 코드와 함께 하면서 쌓은 노하우들을 바탕으로 클린 코드를 구현했다. 난 이 저자의 규칙이 정말 괜찮은 것 같아 클린코드의 규칙을 따라 구현을 했다!!!

• LoginControllerState

input -> transform(input:) -> LoginViewModelInput -> LoginViewModelInputCase 를 거친 후에 각각의 input에 대해서 Merge를 통해 최소한의 subscriber된 각각의 publiser 가 연산을 처리하면서의 결과를 반환한다. 크게 뷰의 상태 변화는 3가지이다. 사용자가 id, pw를 입력했는지 -> 둘다 입력했을 경우 loginButton enabled됨 else disabled. none, 실행중인 인디케이터 해제. 이 세가지다!!

• LoginViewModelNetworkServiceType

그 밖에 로그인 버튼을 통해 로그인 할 때 파이어베이스에 등록된 계정이 맞는지 여부 함수다. wwdc 2021에서 소개된 async, await 비동기 처리를 도입했다. 헤헤. 나중에 컴바인과 결합 할 코드를 구현할 것이다.

// 여담2 이번 방학때 Swinject 아니면 needle를 공부할 것이다. DI는 지난 3주간 컴바인 공부 때 머릿속으로만 계속 떠올리다가 학교 과제 ISS (링크)약 2주간 Instruction Set Simulator를 구현 할 때 의존성이 있는 코드를 도입 하고자 열심히 노력했다. iss 프로젝트 끝난 후 개념으로만 숙지하고 있던 Combine을 적용하고 있는데 protocol 관련은 나쁘지 않게 스위프트에 바로 도입할 수 있었다.
근데 C++에 interface가 지원이 안 된다는 것을 진짜 몰랐다. 그래서 define으로 정하긴 했다.. 근데 순수 가상함수를 선언 해도 결국엔 상속받는 하위 클래스에서 반드시 구현할 때 .h 파일에 재 선언 후 .cpp 파일에서 구현해야 한다는게 너무 아쉬웠다. swift 였다면 중첩 선언이 없는 깔끔한 코드였을 텐데.. 아무튼 ISS를 구현한 덕에 DI관련 개념을 적용하는 것은 나쁘지 않았다는 말!!

3. LoginViewModel (LoginViewModel Link)

이거는 직접 코드로 보는게 좋겠다.

원래 코드 리뷰를 정말 좋아한다. 그리고 주석 으로 부연설명하는 것을 굉장히 좋아한다.. 학교 교수님들이 시켜서 습관이 된 것이 있기도 했다. 클린 코드를 읽으며 코드를 직접 읽을 때 한번에 알 수 있도록 하는 네이밍이 굉장히 중요하다고 했다. 그래서 요즘은 주석 처리하는 습관 대신 깃헙의 issue에 개발하다가 느낀 경험이나 문제, 에러들을 문서화?로 작성하고 있다. 근데 코드리뷰, 주석 습관은 정말 좋다고 생각한다. 하지만 주석 없이 몇 번만에 코드를 이해하는 코드는 정말 훌룡한 코드이고 주석이 필요 없지만 중간에 마주한 상황, 배운점들은 주석이 아닌 issue에 기록하는 새로 습관을 들이고 있다. 그리고 최대한 네이밍을 자세히 해서 코드의 흐름을 정확하게 파악할 수 있도록 구현하는 것이 내 목표다. +_+

---

마주한 에러1

Combine의 publisher tryMap의 사용시 failure타입에 관한 에러.

tryMap을 사용해 error를 던질 수 있을 경우 publisher의 failure타입은 Never가 되면 안된다. Merge -> 그대로 eraseToAnyPublisher()로 변환한 subscription을 갖을 경우에 타입의 모호함 에러가 뜬다.

마주한 에러2

failure 타입이 Never가 아닌 경우

tryMap 은 any error 타입 반환한다. 내가 원하는 publisher failure type에 맞게 mapError를 사용해서 커스텀 error타입으로 에러를 캐스팅 해야 한다. 그래야 subscriber에게 failure를 던질 수 있다. publisher의 failure타입 Never가 아닌 경우에는 map이 아닌 tryMap같은 try 기능이 담긴 연산자를 사용해야 한다.

LoginController와 MainHomeTabViewController 간에 델리게이트를 이전에 작성했기에 살작 복잡했는데 publisher의 input output에 두개의 vc를 전달함으로 해결했다.

복습한 개념

A, B두 개의 publisher가 있다고 가정.
let myZip = A.zip(B)

• combineLatest
  얘는 A가 publish하고 B또한 publish해야만 myZip이 published된다. 약간 커플느낌? 한 쌍이 publish되야만 비로소myZip이 작동한다. 약간 내가 구현하는 id,pw둘다 입력해야만 로그인 버튼 해제되는 로직과 같음. 아래꺼는 약간 password 두번 입력해서 자기가 입력한 password 맞는지 확인할 때의 operator라고 보면 될 거같다.

• zip
  얘는 A가 publish하고 B가 publish해야만 myZip이 publised된다. 그리고 A가 publish되면 B의 최신 값과 함께 publish된다. 즉 둘다 published한 경우에 A만 publish해도 B는 최신 publis 값을 재사용한다. 반대의 경우도 같다.

추가, 개선 해야할 기능

• 검색하기 위해 서치바를 클릭할 때 tableView reloadData가 실행된다. 이것을 없애야한다.

• LoginController 비밀번호 최소 입력 개수 제한

• RegistrationController

또한 토스의 회원가입 절차처럼 만들어 볼 것이다.

새로 리펙터링 해야할 것

• Feed VC 관련
• Upload VC 관련

SearchController 를 SearchViewModel과 분리할 때 SearchViewModelProtocols 요기에서 이 두 함수를 꼭 UserViewModel로 분리해야한다. SearchViewModel에 의존적이다.

시험이 6일 남았다.. 정말 큰일났다.

느낀점

사실 에러 처리를 단순히 콘솔창에 출력했다. 방학이 내게 온다면 특정 상황에 맞는 알림이나 오류를 대체할 수 있는 로직을 구현할 것이다.

(시험만 끝난다면 컴바인 책으로 추가 공부할 텐데)

[Yang seung hyun]

MVVM 리펙터링 추가

ProfileHeaderView.
fetch Network ( async, await + combine)
MainHomeTabControler

---

추후 cache 공부해서 이미지 fetch 개선해야함.

[Yang seung hyun]

ProfileHeader, ProfileHeaderViewModel 리펙터링 완료.

개선해야 할 기능은 Network fetch 관련 부분적으로 리펙터링 했던 async/await 전체적으로 적용시키자 (사용자 팔로우, 팔로잉 관련만 하면 됨. + actor적용.