-
Notifications
You must be signed in to change notification settings - Fork 26
[이연수] Sprint4 #82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[이연수] Sprint4 #82
The head ref may contain hidden characters: "Basic-\uC774\uC5F0\uC218-sprint4"
Conversation
- auth(회원인증) 디렉토리 생성 및 스타일 분리 - 경로 관리 개선
- (공통) 폼 공통 컴포넌트 스타일 수정 - (로그인/회원가입) 입력 검증 함수 구현, 이벤트 동작 추가
- (로그인/회원가입) 비밀번호 표시/숨기기 동작 이벤트 구현
|
스프리트 미션 하시느라 수고 많으셨어요. |
커밋 메시지 좀 더 자세히 써도 될 것 같아요 !"스프린트 미션 4 기본 요구사항 작업 완료" 라고 한다면 해당 커밋이 어떤 작업을 수행했는지 알기가 어렵습니다 ! |
배웠던 import export 문법을 처음 응용해보면서 코드를 모듈화 해서 관리해보려고 시도했는데요. 😀👍👍👍 작은 프로젝트에서는 파일 나누는 기준을 정하는게 어려운 것 같아요. . . 이렇게 파일을 분리할 때 제일 우선적으로 고려하는 기준이 있을까요?사실 이건 “경험”으로 익혀가는 부분이지만, 아래와 같은 신호가 있다면 분리를 고려해볼 수 있어요:
|
|
비슷한 패턴의 로직을 반복할때 고민해서 네이밍 하는데도 변수나 함수 파라미터 이름이 겹치게 되는 경우가 생깁니다. 만약 같은 네이밍이 필요한 일이 발생한다면 "진짜 필요한 변수인가?"를 먼저 고민해보셔야 해요. function isRightCalc(num1, num2, result) {
const rusult2 = num1 + num2;
return result2 === result;
}이 때
서로 다른 두 함수에 작성된 로직이 다르면 두 함수의 목적이 다르다고 볼 수 있습니다. |
(이어서) 작명 꿀팁..?그리고 개발자에게 작명은 숙명입니다... 아마 철학관 같이 작명 사업 하시는 분들보다 개발자가 이름을 더 많이 지을거예요... 😅 1. 이럴 때 좋은 방법은 다음과 같이 아주 대충 지어놓고:function _(num1, num2, result) {
const rusult2 = num1 + num2;
return result2 === result;
}2. GPT한테 추천 받아보면 됩니다 😉:GPT. 다음 함수를 봐줘: function _(num1, num2, result) {
const rusult2 = num1 + num2;
return result2 === result;
}함수 이름이 안떠오르는데 3가지만 추천해줄래 ? 물론이죠! 이 함수는 두 숫자의 합이 기대값(result)과 같은지를 비교하는 함수이므로, 아래와 같은 이름을 추천드립니다: 짧고 직관적인 이름을 원한다면 isSumEqual이 가장 깔끔합니다. 실제로 저도 안떠오를 때 하는 방법이고, GPT 이름 짓는 인사이트 넓히기도 좋아서 함수명 안떠오르면 물어보고 사용합니다. 😉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
오호 경로만 봐도 어떤 목적의 스타일인지 알겠네요 👍👍
| export const validateEmail = (email) => { | ||
| const pattern = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/; | ||
|
|
||
| if (!email) { | ||
| return { message: "이메일을 입력해주세요.", status: "error" }; | ||
| } | ||
| if (!pattern.test(email)) { | ||
| return { message: "잘못된 이메일 형식입니다.", status: "error" }; | ||
| } | ||
|
|
||
| return SUCCESS; | ||
| }; | ||
|
|
||
| // 닉네임 입력 검증 | ||
| export const validateNickName = (nickname) => { | ||
| if (!nickname) { | ||
| return { message: "닉네임을 입력해주세요.", status: "error" }; | ||
| } | ||
| return SUCCESS; | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
와우.. 🫢🫢 유효성 검사 함수가 일관된 타입을 반환하고 있네요.
훌륭합니다 연수님. 반환하는 타입을 일관되게 하고자 객체로 만들어서 상태, 메시지를 구분하셨군요.
정말 멋진시도예요. 감탄했습니다 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(선택) 또한, throw를 사용하는 방법도 있을 것 같아요. 😉
| export const validateEmail = (email) => { | |
| const pattern = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/; | |
| if (!email) { | |
| return { message: "이메일을 입력해주세요.", status: "error" }; | |
| } | |
| if (!pattern.test(email)) { | |
| return { message: "잘못된 이메일 형식입니다.", status: "error" }; | |
| } | |
| return SUCCESS; | |
| }; | |
| // 닉네임 입력 검증 | |
| export const validateNickName = (nickname) => { | |
| if (!nickname) { | |
| return { message: "닉네임을 입력해주세요.", status: "error" }; | |
| } | |
| return SUCCESS; | |
| }; | |
| export const validateEmail = (email) => { | |
| const pattern = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/; | |
| if (!email) { | |
| throw new Error("잘못된 이메일 형식입니다."); | |
| } | |
| if (!pattern.test(email)) { | |
| throw new Error("잘못된 이메일 형식입니다."); | |
| } | |
| return SUCCESS; | |
| }; | |
| // 닉네임 입력 검증 | |
| export const validateNickName = (nickname) => { | |
| if (!nickname) { | |
| throw new Error("닉네임을 입력해주세요."); | |
| } | |
| return SUCCESS; | |
| }; |
해당 코멘트 적용은 선택입니다 ! (그냥 넘겨도 됩니다 ~!)
throw로 해당 함수를 만들든, 연수님께서 작성하신 방법으로 하든 기능상 차이는 물론 없거니와 코드 스타일의 차이 정도로 볼 수 있을 것 같아요.
일부 유효성 검사 라이브러리에서는 연수님께서 작성주신 방법과 throw 두 유효성 검사 함수를 제공하기도 합니다. 즉. 상황에 따라 더 편한 방법을 사용하면 될 것 같아요 😉
| const isPressed = toggleBtn.getAttribute("aria-pressed") === "true"; | ||
| const inputType = toggleBtn.closest(".password-input").querySelector("input"); | ||
|
|
||
| toggleBtn.setAttribute("aria-pressed", isPressed ? "false" : "true"); | ||
| inputType.type = isPressed ? "password" : "text"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
크.. aria까지 신경쓰시는 모습 👍👍👍
정말 꼼꼼하네요 👍👍
| if (!targetFieldId) { | ||
| return; | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
굿굿 ! 조건에 맞지 않으면 함수를 조기에 return하시는 모습 !
if ... else 계속 사용하면 가독성이 떨어지고 자칫 블록 안에 블록, 블록 안에 블록.. 지옥에 빠질 수 있죠
이럴 때 연수님께서 하신 것처럼 조건에 부합하지 않으면 조기에 exit 시키는 패턴을 Guard Clause라고 합니다 !
훌륭합니다 ! 센스가 좋네요 👍👍
|
수고하셨습니다 연수님 ! 리액트에서는 또 어떤 모습을 보여줄지 기대해봅니다 🥺🥺🥺 |
```commit feat: 스프린트 미션 4 기본 요구사항 작업 완료 - (공통) 폼 공통 컴포넌트 스타일 수정 - (로그인/회원가입) 입력 검증 함수 구현, 이벤트 동작 추가 ``` 위처럼 스프린트 3부터 한 커밋에 여러 작업 내용을 묶어서 정리하기 시작했는데, (뭔가 깔끔해보여서요!ㅎㅎ) 수강생 분들 커밋 메시지를 보니 기능/작업 단위별로 세분화해서 올리신 경우가 많더라구요. |
Sprint Mission 4 요구사항
기본
로그인
input에서focus out할 때,input에 빨강색 테두리 / 아래에 "이메일을 입력해주세요." 빨강색 에러 메세지input에 빨강색 테두리 / 아래에 "잘못된 이메일 형식입니다" 빨강색 에러 메세지input에서focus out할 때,input에 빈 값이 있거나 에러 메세지가 있으면,input에 유효한 값을 입력하면,회원가입
input에서focus out할 때,input에 빨강색 테두리 / 아래에 "이메일을 입력해주세요." 빨강색 에러 메세지input에 빨강색 테두리와 아래에 "잘못된 이메일 형식입니다" 빨강색 에러 메세지input에서focus out할 때,input에 빨강색 테두리 / 아래에 "닉네임을 입력해주세요." 빨강색 에러 메세지input에서focus out할 때,input과 비밀번호 확인input의 값이 다른 경우,input아래에 "비밀번호가 일치하지 않습니다." 에러 메세지input에 빈 값이 있거나 에러 메세지가 있으면,input에 유효한 값을 입력하면,심화
비밀번호의 문자열이 보일 때는 사선이 없는 눈 모양 아이콘이 보이도록 합니다.
작업 URL
판다마켓 | 메인
판다마켓 | 로그인
판다마켓 | 회원가입
주요 변경사항
스크린샷
로그인
회원가입
멘토에게
배웠던 import export 문법을 처음 응용해보면서 코드를 모듈화 해서 관리해보려고 시도했는데요. 😀
작은 프로젝트에서는 파일 나누는 기준을 정하는게 어려운 것 같아요. . . 이렇게 파일을 분리할 때 제일 우선적으로 고려하는 기준이 있을까요?
비슷한 패턴의 로직을 반복할때 고민해서 네이밍 하는데도 변수나 함수 파라미터 이름이 겹치게 되는 경우가 생깁니다.
(새 기능을 추가해서 만들 때 기존에 짰던 코드를 자꾸 건드리게 돼요 . . . 🤕)
의미만 명확하게 전달되면 비슷하거나 겹쳐도 괜찮은지 궁금합니다.