🚀 4단계 - 회원가입(리팩터링)

[ChaMinZi]

안녕하세요! 3단계 피드백과 4단계 미션 구현하였습니다!

3,4 단계 미션을 진행하면서 궁금한 점이 생겨 질문드려봅니다~ 🙏

3단계 미션에서 아래와 같은 피드백을 주셨는데요~ 해당 부분을 구현하면서도 각 컴포넌트별로 나누는게 나을지 고민이 많이 되었어요!
말씀주신 것처럼 테스트 용이성을 위해서는 컴포넌트가 나누어지는 것이 좋은 것 같은데… 
각 TextField 컴포저블 내부 구조는 거의 비슷한데 나누는 이유를 테스트 용이성 말고는 잘 모르겠어서요! 해당 이유만으로도 충분한걸까요??


UserInputTextField 컴포넌트를 활용하는 각각의 입력 텍스트 필드 컴포넌트를 만들어보는 건 어떨까요?
EmailInputField, UserNameTextField 등 역할에 맞는 컴포넌트를 각각 만들어보시면 좋겠어요 :)
그렇다면 테스트도 프로덕션과 테스트에 중복적인 코드를 작성하지 않고,
컴포넌트 단위로 적절하게 파일을 나눠 테스트해볼 수 있을거라 생각해요 :)

4단계 리뷰 잘 부탁드립니다. 😃

---

Changes

• 3단계 리뷰 사항 반영

  • ErrorMessage 존재 여부로 에러 표시 결정
  • TextFiedl를 각 역할에 맞는 컴포넌트로 분리

• 모든 필드가 에러 없이 채워진 경우 Sign up 버튼 활성화

• Sign up 버튼을 클릭하면 회원가입 완료 스낵바 노출

• 유효성 검사 로직과 뷰 테스트 로직 분리

Screen shot

Screen_recording_20250307_102617.mp4

[malibinYun]

4단계 미션 고생 많으셨어요!
여러 코멘트와 질문해주신 것에 대한 답변도 같이 남겨두었어요 :)
이만 미션을 마무리 짓고 싶으시다면 코멘트 메시지 남겨주시고, 더 시도해보고 싶으신 게 있으시다면 반영 후 다시 리뷰 요청 부탁드려요!

[malibinYun]

유닛 테스트를 진행해주셨네요!
각 컴포넌트를 역할에 맡게 나누어 주셨으니, 각 컴포넌트도 UI Test를 작성해보시면 좋겠네요 :)

[malibinYun]

비밀번호 검증 로직도 비밀번호 입력 컴포넌트에 응집도있게 모아보는 건 어떨까요?

입력 검증 클래스도 각각 입력 값 마다 interface - 구현체로 나누어서 역할별로 쪼개 보셔도 좋겠어요.

@Composable
fun PasswordTextField(
    value: String,
    onValueChange: (String) -> Unit,
    modifier: Modifier = Modifier,
    passwordValidator: PasswordValidator = DefaultPasswordValidator,
    errorMessage: String? = null,
    imeAction: ImeAction = ImeAction.Unspecified,
) {
    ...
    val isPasswordValid = passwordValidator.validate(...)

    if(isPasswordValid ){
        ...
    }

    ...

이런식으로 구성한다면 검증 로직이 바뀌더라도 외부에서 새로운 구현체를 주입 받아서 이 컴포넌트의 변경점을 최소한으로 줄일 수 있겠어요. 새로운 컴포넌트를 만들지 않으면서요!

[malibinYun]

3단계 미션에서 아래와 같은 피드백을 주셨는데요~ 해당 부분을 구현하면서도 각 컴포넌트별로 나누는게 나을지 고민이 많이 되었어요!
말씀주신 것처럼 테스트 용이성을 위해서는 컴포넌트가 나누어지는 것이 좋은 것 같은데… 
각 TextField 컴포저블 내부 > 구조는 거의 비슷한데 나누는 이유를 테스트 용이성 말고는 잘 모르겠어서요! 해당 이유만으로도 충분한걸까요??


UserInputTextField 컴포넌트를 활용하는 각각의 입력 텍스트 필드 컴포넌트를 만들어보는 건 어떨까요?
EmailInputField, UserNameTextField 등 역할에 맞는 컴포넌트를 각각 만들어보시면 좋겠어요 :)
그렇다면 테스트도 프로덕션과 테스트에 중복적인 코드를 작성하지 않고,
컴포넌트 단위로 적절하게 파일을 나눠 테스트해볼 수 있을거라 생각해요 :)

테스트 뿐만 아니라, 컴포넌트의 구현을 일일이 보여주기 보다 한 단계 추상화 함으로써 필요한 정보만을 외부에서 받아 사용하도록 구성할 수 있다고 생각해요.
TextField를 처음부터 써서 어떠한 값들을 주르륵 쓰다보면, 그래서 이 TextField는 무엇을 나타내고 싶은지 알기에는 시간이 오래걸릴 수 있다고 생각해요. 추상화를 함으로써 그런 인지를 위한 시간을 생략하고 바로 의도를 나타낼 수 있는 방법이라 생각해요.

또, 각 컴포넌트가 모두 직접 TextField를 사용하는데요,
이전 피드백 처럼 UserInputTextField를 활용하게끔 구성해보셔도 좋겠어요.
각 입력에 대한 컴포넌트가 공통적으로 갖고 있는 입력 디자인을 기본적으로 가지는 텍스트 필드 컴포넌트가 가장 아래에 깔리고,
각 특성에 맞는 컴포넌트는 그 디자인 요소가 적용되어있는 컴포넌트를 활용하는 것이지요.
그렇다면 각 컴포넌트가 각자에 맞는 관심만을 가지게 추상화 할 수 있다 생각해요 :)

[malibinYun]

Regex 객체는 생성 비용이 비싸니, 매번 생성하기 보다 미리 만들어두고 재활용해보는 건 어떨까요?

[malibinYun]

이 컴포넌트에게는 비교군과 대조군 텍스트를 둘 다 넘겨서 내부에서 검증을 수행하도록 구성해보는 건 어떨까요?