질문
개인적으로 파일 구조에 대해 이해하면서,
•
Store는 서버와 직접 맞닿는 코드,
•
ViewModel은 Store의 메서드를 가공해서 View와 직접 맞닿는 코드라고 이해를 했습니다.
그래서 Firebase Authentication으로 로그인/회원가입을 구현할 때 AuthStore에서는
•
Firebase의 Auth.auth()의 메서드를 직접 호출하고 처리하는 메서드(회원가입, 로그인, 로그아웃, 닉네임변경, 프로필사진 변경 등)들을 작성했고,
•
각각의 메서드가 AuthResponse 라는 구조체 인스턴스(성공여부(Bool), 성공여부에 따른 메세지(String), currentUser(현재 로그인한 유저)를 리턴하도록 설계했습니다.
그리고 ViewModel에서는
•
authResponse 프로퍼티를 Published 하고,
•
ViewModel 내의 메서드들은 store에 있는 메서드를 조합해서 만들었습니다.
(예를 들면, 회원가입 버튼을 누르면 회원가입 → 로그인 → 닉네임변경 메서드를 모아서 하나의 메서드로 만듦)
그런데 궁금한 부분이, 일단 메서드 사용까지는 어렵지 않은데
로그인한 User 객체에 접근하려면, ViewModel 객체 → AuthResponse 객체 → currentUser 프로퍼티 이렇게 점 표기법의 뎁스가 깊어지는데요.
코드 구조가 이렇게 되는게 개인적으로는 비효율적인 것처럼 느껴집니다.
•
store나 View모델에 대해 제가 이해한 것이 맞나요?
•
ViewModel 객체 → AuthResponse 객체 → currentUser 프로퍼티 로 접근해야 하는 이 구조에 대한 코드리뷰 부탁드리고 싶습니다!
◦
현업에서는 어떻게 하는지도 궁금합니다!
화면캡쳐(예시)
위 질문에 해당하는 질문의 링크나 스크린샷을 여기에 추가해 멘토분들이 참고할 수 있도록 하세요.
프로젝트 주소
위 질문에 해당하는 질문의 링크나 스크린샷을 여기에 추가해 멘토분들이 참고할 수 있도록 하세요.
멘토링 진행 내용
멘티 스스로 알아보기로 한 것
1.
점 표기법의 뎁스가 깊어질 때 대응 방안, 현업에서 사용하는 방식 (중간 객체에 internal 프로퍼티 생성)
2.
프로젝트 내 Store 타입, ViewModel 타입의 역할
•
Repository 개념도 있으나 좀더 복잡도 높은 프로젝트를 경험한 뒤 찾아보기
3.
추가적인 코드리뷰
•
String extension 구현해보기
•
API Response Model - 기본값을 지정하는 방법 vs. 옵셔널 타입으로 지정하는 방법의 차이점
•
여러 개의 ViewModel에서 공통적으로 접근하는 사용자 데이터 (UserManager) 관리 방법으로 싱글턴 패턴 사용해보기 (싱글턴 패턴의 특징, 장단점, static 사용 시 메모리 특징 알아보기)
•
사용자 데이터 저장 - UserDefaults 알아보기, 앱 재실행 후 로그인 정보가 남아있는 이유 알아보기
•
폴더링
•
README, PR 작성 예시 공유
