Basic 진성진 sprint4

[cozy-ito]

요구사항

기본

로그인

• 이메일 input에서 focus out 할 때, 값이 없을 경우 input에 빨강색 테두리와 아래에 “이메일을 입력해주세요.” 빨강색 에러 메세지를 보입니다.
• 이메일 input에서 focus out 할 때, 이메일 형식에 맞지 않는 경우 input에 빨강색 테두리와 아래에 “잘못된 이메일 형식입니다” 빨강색 에러 메세지를 보입니다.
• 비밀번호 input에서 focus out 할 때, 값이 없을 경우 아래에 “비밀번호를 입력해주세요.” 에러 메세지를 보입니다
• 비밀번호 input에서 focus out 할 때, 값이 8자 미만일 경우 아래에 “비밀번호를 8자 이상 입력해주세요.” 에러 메세지를 보입니다.
• input 에 빈 값이 있거나 에러 메세지가 있으면 ‘로그인’ 버튼은 비활성화 됩니다.
• input 에 유효한 값을 입력하면 ‘로그인' 버튼이 활성화 됩니다.
• 활성화된 ‘로그인’ 버튼을 누르면 “/items” 로 이동합니다

회원가입

• 이메일 input에서 focus out 할 때, 값이 없을 경우 input에 빨강색 테두리와 아래에 “이메일을 입력해주세요.” 빨강색 에러 메세지를 보입니다.
• 이메일 input에서 focus out 할 때, 이메일 형식에 맞지 않는 경우 input에 빨강색 테두리와 아래에 “잘못된 이메일 형식입니다” 빨강색 에러 메세지를 보입니다.
• 닉네임 input에서 focus out 할 때, 값이 없을 경우 input에 빨강색 테두리와 아래에 “닉네임을 입력해주세요.” 빨강색 에러 메세지를 보입니다.
• 비밀번호 input에서 focus out 할 때, 값이 없을 경우 아래에 “비밀번호를 입력해주세요.” 에러 메세지를 보입니다
• 비밀번호 input에서 focus out 할 때, 값이 8자 미만일 경우 아래에 “비밀번호를 8자 이상 입력해주세요.” 에러 메세지를 보입니다.
• 비밀번호 input과 비밀번호 확인 input의 값이 다른 경우, 비밀번호 확인 input 아래에 “비밀번호가 일치하지 않습니다..” 에러 메세지를 보입니다.
• input 에 빈 값이 있거나 에러 메세지가 있으면 ‘회원가입’ 버튼은 비활성화 됩니다.
• input 에 유효한 값을 입력하면 ‘회원가입' 버튼이 활성화 됩니다.
• 활성화된 ‘회원가입’ 버튼을 누르면 “/signup” 로 이동합니다.

심화

• 눈 모양 아이콘 클릭시 비밀번호의 문자열이 보이기도 하고, 가려지기도 합니다.
• 비밀번호의 문자열이 가려질 때는 눈 모양 아이콘에는 사선이 그어져있고, 비밀번호의 문자열이 보일 때는 사선이 없는 눈 모양 아이콘이 보이도록 합니다.

주요 변경사항

• 로그인/회원가입 페이지의 주요 자바스크립트 로직을 구현합니다.

스크린샷

• 로그인

• 회원가입

멘토에게

• 함수가 너무 세분화 되거나 커지지 않도록 분리를 시도해봤습니다! 그런데 에러 메시지 데이터를 파라미터를 통해 깊은 수준까지 끌고 가도록 구현이 되었습니다. 그러다 보니 함수 사이의 의존성이 너무 강하게 결합되도록 구현한 것이 아닐지 고민이 됩니다! 필요에 따라서는 괜찮은 구현방법일지 또는 너무 깊어지지 않게 그 수준을 조율해야 할 지 궁금합니다.

• common/validate.mjs

  • validate 함수에서 message 받음 -> checkValidation 함수 전달 -> onInputError 함수 전달 -> addErrorMessage 함수에서 실제 사용
  • resetErrorMessage 함수
    • .error-message 클래스를 가지고 있는 요소가 존재하는지 여부에 따라서 에러메시지 요소를 삭제하는 로직입니다. 해당 요소를 찾을 때, document.querySelector를 통해서 DOM 트리를 차례차례 탐색하는 것보다 이벤트 발생 노드에서 바로 탐색을 하는 것이 효율적이지 않을까 생각이 들어 e.target.parentElement.parentElement.lastElementChild 라는 방식으로 에러 요소를 찾도록 구현했습니다. 물론 탐색 속도에서 큰 차이가 없을 수 있을 것 같긴 하지만 제가 작성한 이벤트 타겟부터의 탐색이 더 효율적인지 궁금합니다.
  • addErrorMessage 함수
    • 에러 메시지를 추가하는 로직입니다. 로그인/회원가입 Input 요소에서 에러 상태를 발생시키기 위해 에러 메시지를 위한 p태그를 생성한 뒤, 해당 요소를 추가하는 방식으로 구현했습니다. 이렇게 구현한 이유는 1. 에러메시지를 나타내기 위한 노드 요소를 DOM 트리에 항상 두는 것 보다는 굳이 필요하지 않은 노드까지 탐색하는 것을 최소화 하고자 함이었습니다. 이런 접근방식으로 구현 하는 것은 괜찮은 방식일까요?

• common/signin.mjs, common/signup.mjs

  • 로그인/회원가입의 input요소에서의 유효성 검사를 위한 이벤트 핸들러 함수 내부 로직에서 validate 함수를 별도로 만들어 각 유효성 검사 항목 마다 호출을 하는 방식으로 구현했습니다. 항목마다 유효성 검사를 수행하는 콜백함수와 실패 시 에러메시지를 전달하게 되어 코드가 좀 길어지는 것 같은 생각이 들었습니다. 이런 방식으로 구현해도 괜찮을지 궁금합니다!

[dongqui]

성진님 이번 미션도 잘 마무리 해주셨군요!

대체로 코드를 구조화 하시려는 모습이 너무 좋습니다 :) 함수나 상수 등을 잘 분리해주셨어요. 함수명이나 역할을 조금 더 명확히 하면 더욱 좋을 거 같습니다~~!

클린 코드는 사실 애매한 영역입니다. 어제는 맞았던 것이 오늘은 틀릴 수 있고, 나에게는 맞지만 다른 사람에게는 틀릴 수도 있죠. 정답이 없기 때문에 응집도, 추상화, 단일 책임 같은 몇 가지 원칙을 기반으로 상황에 맞게 판단하는 것이 중요합니다.
결국 성진님의 코드가 근거를 가지고 있는지 가 중요한데, 지금처럼 계속 고민하시는 태도를 유지하신다면 성장에 많은 도움이 될 거 같아요 :)

함수가 너무 세분화 되거나 커지지 않도록 분리를 시도해봤습니다! 그런데 에러 메시지 데이터를 파라미터를 통해 깊은 수준까지 끌고 가도록 구현이 되었습니다. 그러다 보니 함수 사이의 의존성이 너무 강하게 결합되도록 구현한 것이 아닐지 고민이 됩니다! 필요에 따라서는 괜찮은 구현방법일지 또는 너무 깊어지지 않게 그 수준을 조율해야 할 지 궁금합니다.
-> 괜찮습니다! 의존성 자체는 없어 보입니다 :) 다만, 추상화를 하실 때 로직을 너무 숨기면 오히려 코드를 파악하기 어려운 경우가 생깁니다. 예를 들어 checkValidation이 실행되는 부분만 보면 어떤 일이 벌어지고 있는지 알기가 힘들죠!

validate 함수에서 message 받음 -> checkValidation 함수 전달 -> onInputError 함수 전달 -> addErrorMessage 함수에서 실제 사용
resetErrorMessage 함수
.error-message 클래스를 가지고 있는 요소가 존재하는지 여부에 따라서 에러메시지 요소를 삭제하는 로직입니다. 해당 요소를 찾을 때, document.querySelector를 통해서 DOM 트리를 차례차례 탐색하는 것보다 이벤트 발생 노드에서 바로 탐색을 하는 것이 효율적이지 않을까 생각이 들어 e.target.parentElement.parentElement.lastElementChild 라는 방식으로 에러 요소를 찾도록 구현했습니다. 물론 탐색 속도에서 큰 차이가 없을 수 있을 것 같긴 하지만 제가 작성한 이벤트 타겟부터의 탐색이 더 효율적인지 궁금합니다.
-> 전반적으로 parentElement, lastElementChild 등을 많이 써주셨는데, 유지 보수에는 좋지 않은 코드 같습니다. html 구조가 조금만 바껴도 코드가 쉽게 깨지고 수정 사항이 너무 많이 발생할 거 같아요! (프론트엔드 코드는 비교적 수명이 짧습니다!) 또한 html 구조와 js 코드를 함께 봐야하기 때문에 이해하기 어려운 코드로 보입니다. 성능 차이는 거의 없을 거구요!
언제나 트레이드오프를 생각해보셔야 하는데, 만약 정말 성능상의 문제가 있다면 유지보수를 어느정도 포기할 수 있겠지만, 지금으로선 득보단 실이 훨씬 큰 거 같습니다 🤔

addErrorMessage 함수
에러 메시지를 추가하는 로직입니다. 로그인/회원가입 Input 요소에서 에러 상태를 발생시키기 위해 에러 메시지를 위한 p태그를 생성한 뒤, 해당 요소를 추가하는 방식으로 구현했습니다. 이렇게 구현한 이유는 1. 에러메시지를 나타내기 위한 노드 요소를 DOM 트리에 항상 두는 것 보다는 굳이 필요하지 않은 노드까지 탐색하는 것을 최소화 하고자 함이었습니다. 이런 접근방식으로 구현 하는 것은 괜찮은 방식일까요?
common/signin.mjs, common/signup.mjs
-> 이것도 위와 비슷한 맥락인데, 저라면, 정말 성능 문제가 있는 것이 아니라면 코드 복잡도를 줄이는 것을 선택할 거 같아요 :)

로그인/회원가입의 input요소에서의 유효성 검사를 위한 이벤트 핸들러 함수 내부 로직에서 validate 함수를 별도로 만들어 각 유효성 검사 항목 마다 호출을 하는 방식으로 구현했습니다. 항목마다 유효성 검사를 수행하는 콜백함수와 실패 시 에러메시지를 전달하게 되어 코드가 좀 길어지는 것 같은 생각이 들었습니다. 이런 방식으로 구현해도 괜찮을지 궁금합니다!
-> 길어지는 것은 괜찮습니다 :) 원하는 코드를 쉽게 찾을 수 있는 지, 이해하기 쉬운지 판단 해보시면 좋습니다. 충분히 잘 구조화 하신 거 같아요!👍

[dongqui]

constatns를 따로 정의하셨군요! 👍

[dongqui]

함수명에서 에러 UI를 다루는 것을 표현하면 더욱 좋을 거 같아요!

[dongqui]

같은 목적을 가진 코드는 모아두는 게 좋습니다! (응집도)

에러를 초기화 하는 코드라면 offInputError 쪾으로 가는 게 조금 더 나을 거 같습니다 :)

[dongqui]

이벤트 버블링을 활용해보셔도 좋을 거 같습니다 :)

[dongqui]

정규식을 써주셨네요! 👍

[dongqui]

함수의 역할을 분명히 하면 더욱 좋겠습니다!

dom 요소를 받아서 유효성을 검사하는 함수인데, 이벤트 객체를 받거나 targetEl이 들어오면서 복잡도가 증가된 거 같습니다! isMatch 때문인 거 같은데 관련 부분은 밖에서 처리 하는 것이 좀 더 나을 거 같아요.

isMatch: (value1) => (value2) => value1 !== "" && value1 === value2,
//...
validate(e.target, {
    validator: authValidator.isMatch($passwordInput.value),
    message: ERROR_MESSAGE.IS_NOT_MATCH_PASSWORD,
  });

이런식으로 할 수도 있겠네요!

(참고만 해주세요! 충분히 잘 하셨습니다~!)