Feat: #159 닉네임 중복 확인 API 및 회원가입 기능 구현 #171
Conversation
…ature/#159-nickname-check-api-and-signup
Yoonyesol
added
🗃️ Chore
Walkthrough이번 변경 사항은 사용자 인증 및 회원가입 기능을 개선하기 위해 여러 컴포넌트와 훅을 수정했습니다. 주요 변경 사항으로는 닉네임 중복 확인 API와 회원가입 기능의 구현, 사용자 정보 접근 방식의 개선, 그리고 버튼 비활성화 기능이 추가되었습니다. 또한, 사용자 관련 데이터 구조가 업데이트되었고, 이메일 인증 및 비밀번호 변경 기능이 향상되었습니다. Changes
Possibly related issues
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Outside diff range and nitpick comments (13)
src/hooks/useEmailVerification.ts (1)
28-30: 변경 사항이 적절해 보입니다. 타입 안전성을 위한 작은 제안이 있습니다.이 변경은
expireVerificationCode함수의 유연성을 향상시켜 좋습니다. 오류 메시지 표시를 제어할 수 있게 되어 다양한 상황에 대응할 수 있게 되었습니다.타입 안전성을 더욱 높이기 위해 매개변수의 타입을 명시적으로 지정하는 것이 좋습니다. 다음과 같이 변경을 고려해보세요:
- const expireVerificationCode = (showMessage = true) => { + const expireVerificationCode = (showMessage: boolean = true) => {이렇게 하면 함수 사용 시 잘못된 타입의 인자가 전달되는 것을 방지할 수 있습니다.
src/layouts/page/SettingLayout.tsx (1)
23-23: userInfo 사용 승인 및 개선 제안
useStore에서userInfo를 가져와 사용하는 것은 정적 데이터를 동적 사용자 정보로 대체하는 좋은 변경사항입니다. 이는 컴포넌트를 더 동적으로 만들고 실제 사용자 상태와 일치시킵니다.다만,
userInfo가 존재하지 않을 경우를 대비한 간단한 에러 처리를 추가하는 것이 좋겠습니다. 다음과 같이 수정해 보세요:- const { userInfo } = useStore(); + const { userInfo = { nickname: '사용자' } } = useStore(); // ... - <ListSidebar title={`${userInfo.nickname} 님의 정보`}> + <ListSidebar title={`${userInfo?.nickname || '사용자'} 님의 정보`}>이렇게 하면
userInfo가 없거나nickname이 없는 경우에도 안전하게 처리할 수 있습니다.Also applies to: 34-34
src/types/UserType.tsx (2)
14-16:UserInfo타입 추가 승인 및 보안 고려사항 제안
UserInfo타입의 추가는 인증 프로세스에 유용할 것 같습니다.그러나
password필드를 문자열로 저장하는 것에 대해 보안 측면을 고려해 주시기 바랍니다. 가능하다면 다음과 같은 방법을 고려해 보세요:
- 비밀번호를 해시화하여 저장
- 별도의 보안 관련 타입을 만들어 관리
- 민감한 정보를 다루는 부분에 주석을 추가하여 주의를 환기
이러한 방법들은 보안을 강화하고 잠재적인 취약점을 줄이는 데 도움이 될 수 있습니다.
31-31:CheckNicknameForm타입 추가 승인 및 주석 제안
CheckNicknameForm타입의 추가는 적절합니다. 이는 닉네임 중복 확인 API 구현 목적과 일치합니다.타입의 목적을 명확히 하기 위해 간단한 주석을 추가하는 것이 좋을 것 같습니다. 예를 들어:
// 닉네임 중복 확인을 위한 폼 타입 export type CheckNicknameForm = Pick<User, 'nickname'>;이렇게 하면 다른 개발자들이 이 타입의 용도를 쉽게 이해할 수 있을 것입니다.
src/components/user/auth-form/LinkContainer.tsx (1)
52-72: 코드 개선 승인 및 최적화 제안변경된 코드는
links배열이 존재할 때만 매핑을 수행하도록 하여 컴포넌트의 안정성을 향상시켰습니다. 이는links가 정의되지 않았거나 null일 때 발생할 수 있는 잠재적인 오류를 방지합니다.추가적인 최적화를 위해 다음과 같은 변경을 고려해 보세요:
- {links && - links.map((linkItem) => ( + {links?.map((linkItem) => (이 변경은 동일한 기능을 유지하면서 코드를 더 간결하게 만듭니다. 옵셔널 체이닝 연산자
?.를 사용하면links가 존재할 때만map함수가 호출되므로, 별도의 조건문이 필요 없습니다.src/components/common/ValidationInput.tsx (1)
57-57: buttonDisabled 프로퍼티가 올바르게 구현되었습니다.
buttonDisabled프로퍼티가 컴포넌트에 잘 통합되었습니다. 버튼의 클래스와 비활성화 상태가 이 프로퍼티에 따라 적절히 설정됩니다.가독성 향상을 위해 다음과 같은 작은 개선을 제안합니다:
-className={`h-18 w-75 rounded ${buttonDisabled ? 'bg-disable' : 'bg-sub'} px-8 font-bold`} +className={`h-18 w-75 rounded px-8 font-bold ${buttonDisabled ? 'bg-disable' : 'bg-sub'}`}이렇게 하면 조건부 클래스가 문자열의 끝에 위치하여 더 읽기 쉬워집니다.
Also applies to: 97-102
src/mocks/mockData.ts (1)
Line range hint
41-305: USER_DUMMY 배열의 확장이 잘 되었습니다.사용자 데이터의 확장과 일관성 있는 구조는 좋습니다. 하지만 몇 가지 개선할 점이 있습니다:
- 실제 이메일 주소와 유사한 형식을 사용하고 있습니다. 테스트 데이터임을 명확히 하기 위해
example.com도메인을 사용하는 것이 좋습니다.- 비밀번호 패턴이 일관적입니다. 실제 사용자 데이터의 다양성을 반영하기 위해 다양한 패턴을 사용하는 것이 좋습니다.
- 프로필 이미지 이름이 일관성이 없습니다. 일부는 확장자가 있고 일부는 없습니다.
다음과 같이 개선해 보세요:
- email: '[email protected]', + email: '[email protected]',- password: 'test1234!', + password: 'P@ssw0rd123!',- profileImageName: 'Image1.jpg', + profileImageName: 'image1.jpg',이러한 변경을 통해 더 현실적이고 다양한 테스트 데이터를 만들 수 있습니다.
src/pages/user/SignUpPage.tsx (3)
42-42: TODO 주석에 대한 도움을 제공합니다.해당 기능을 유저 설정 페이지로 분리하려는 계획이 있으신 것 같습니다. 이를 구현하는 데 도움을 드릴 수 있습니다. GitHub 이슈를 생성하여 해당 작업을 추적할까요?
69-71: 회원가입 성공 시 즉시 페이지 이동을 고려해보세요.현재 2초 후에 로그인 페이지로 이동하도록 설정되어 있습니다. 사용자 경험을 향상시키기 위해 성공 메시지를 표시한 후 즉시 이동하거나, 사용자에게 이동 여부를 선택할 수 있도록 하는 것을 고려해보세요.
82-82: 예상치 못한 에러에 대한 추가 로깅을 고려해보세요.예상치 못한 에러 발생 시 디버깅을 위해
console.error(error)와 같은 로그를 추가하면 문제 해결에 도움이 될 수 있습니다.src/mocks/services/authServiceHandler.ts (3)
24-31: 이메일 인증 번호 검증 로직 강화 필요현재 이메일 인증 번호를 검증할 때 더미 데이터를 사용하고 있습니다. 실제 서비스에서는 인증 번호를 안전하게 저장하고 검증할 수 있는 방법이 필요합니다.
데이터베이스나 캐시를 활용하여 인증 번호를 관리하는 방안을 고려해주세요.
108-109: 남아있는 TODO 주석 처리 필요
// ToDo: 추후 삭제와 같은 주석이 코드에 남아있습니다. 작업이 완료되었거나 불필요한 주석이라면 제거하는 것이 좋습니다.해당 주석을 정리하는 데 도움이 필요하신가요? 기꺼이 도와드리겠습니다.
134-146: 액세스 토큰 미존재 시 일관된 에러 처리 필요액세스 토큰이 없을 때
new HttpResponse(null, { status: 401 })를 반환하고 있습니다. 다른 부분과 일관성 있게HttpResponse.json을 사용하여 에러 메시지를 반환하는 것이 좋습니다.다음과 같이 수정하면 좋겠습니다:
- if (!accessToken) return new HttpResponse(null, { status: 401 }); + if (!accessToken) { + return HttpResponse.json({ message: '인증 정보가 존재하지 않습니다.' }, { status: 401 }); + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (12)
- src/components/common/ValidationInput.tsx (4 hunks)
- src/components/user/auth-form/LinkContainer.tsx (1 hunks)
- src/hooks/useEmailVerification.ts (1 hunks)
- src/layouts/page/SettingLayout.tsx (3 hunks)
- src/mocks/mockData.ts (16 hunks)
- src/mocks/services/authServiceHandler.ts (5 hunks)
- src/pages/setting/UserSettingPage.tsx (1 hunks)
- src/pages/user/SignUpPage.tsx (3 hunks)
- src/services/authService.ts (1 hunks)
- src/stores/useStore.ts (2 hunks)
- src/types/UserType.tsx (2 hunks)
- src/utils/converter.ts (2 hunks)
🧰 Additional context used
🪛 Biome
src/mocks/services/authServiceHandler.ts
[error] 201-202: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (27)
src/layouts/page/SettingLayout.tsx (2)
4-4: useStore 훅 가져오기 추가 승인
useStore훅을 가져오는 것은 동적 사용자 정보에 접근하기 위한 적절한 변경사항입니다. 이는 사용자 등록 기능 구현이라는 PR 목표와 일치합니다.
Line range hint
1-48: 전체 변경사항 요약 및 승인이 PR의 변경사항들은
SettingLayout컴포넌트를 개선하여 동적 사용자 정보를 사용하도록 만들었습니다. 이는 PR의 목표인 사용자 등록 기능 구현과 잘 부합합니다.주요 변경사항:
useStore훅 도입으로 동적 사용자 정보 접근- 정적 더미 데이터 대신 실제 사용자 정보 사용
이러한 변경으로 컴포넌트가 실제 사용자 상태와 더 잘 연동되어 작동하게 되었습니다. 제안된 에러 처리 개선사항을 적용하면 더욱 견고한 코드가 될 것입니다.
src/types/UserType.tsx (3)
23-23:UserSignUpForm타입 변경 승인
UserSignUpForm타입에서profileImageName을 제외한 변경은 적절해 보입니다. 이는 사용자 등록 과정에서 프로필 이미지가 필수가 아님을 나타내며, 초기 등록 절차를 간소화할 수 있습니다.
29-29:UserSignUpRequest타입 추가 승인
UserSignUpRequest타입의 추가는 적절해 보입니다.UserSignUpForm에서checkPassword를 제외함으로써, 실제 API 요청에 필요한 데이터만을 포함하고 있습니다. 이는 클라이언트-서버 간 데이터 전송을 최적화하고, 불필요한 정보가 서버로 전송되는 것을 방지합니다.
5-5:username필드 타입 변경 승인 및 확인 요청
username필드의 타입을string | null에서string으로 변경한 것은 적절해 보입니다. 이는 사용자 등록 기능 구현과 일치합니다.다만, 이 변경이 기존 코드에 미치는 영향을 확인해 주시기 바랍니다. 다음 스크립트를 실행하여
username이 null일 수 있다고 가정한 코드를 찾아보세요:src/stores/useStore.ts (1)
79-79:username속성의 기본값 변경 검토
username속성의 기본값이null에서 빈 문자열('')로 변경되었습니다. 이 변경은 일관성 있게 적용되었지만, 다음 사항을 고려해야 합니다:
- 타입 안전성:
null과 빈 문자열은 다르게 처리될 수 있으므로, 애플리케이션의 다른 부분에서username을 사용하는 방식을 검토해야 합니다.- 의미론적 차이:
null은 '값이 없음'을 나타내는 반면, 빈 문자열은 '빈 값'을 나타냅니다. 이 차이가 비즈니스 로직에 미치는 영향을 고려해야 합니다.- 프론트엔드 처리: 사용자 인터페이스에서
username을 표시하거나 처리하는 방식을 확인하고 필요한 경우 수정해야 합니다.이 변경이 애플리케이션의 다른 부분에 미치는 영향을 확인하기 위해 다음 스크립트를 실행하세요:
이 스크립트의 결과를 바탕으로 필요한 추가 변경 사항을 확인하세요.
Also applies to: 96-96
src/pages/setting/UserSettingPage.tsx (1)
84-84: 더미 데이터에서 실제 사용자 데이터로의 전환을 승인합니다.이 변경은 정적 더미 데이터에서 동적 사용자 데이터로 전환하는 좋은 단계입니다. PR 목표와 일치하며 애플리케이션의 실제 기능을 향상시킵니다.
다음 사항들을 고려해 보시기 바랍니다:
userInfoData.links가 정의되지 않은 경우에 대비하여 폴백(fallback) 옵션을 추가하는 것이 좋습니다. 예를 들어:initialLinks={userInfoData.links || []}애플리케이션의 다른 부분에서 여전히 더미 데이터를 사용하고 있는지 확인하고, 일관성을 유지하기 위해 필요한 경우 업데이트하세요.
다음 스크립트를 실행하여 애플리케이션 전체에서 더미 데이터 사용을 확인하세요:
✅ Verification successful
다음 스크립트를 실행하여
USER_INFO_DUMMY의 사용 여부를 다시 확인해주세요. 파일 형식을 올바르게 지정했습니다:
사용되지 않는 더미 데이터 확인 완료
USER_INFO_DUMMY가 코드베이스 내에서 더 이상 사용되지 않음을 확인했습니다. 변경 사항을 승인합니다.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # 설명: USER_INFO_DUMMY 사용 여부 확인 # 테스트: USER_INFO_DUMMY 사용 검색. 예상 결과: 사용 중인 곳이 없어야 함 rg --type typescript --type javascript "USER_INFO_DUMMY"Length of output: 91
Script:
#!/bin/bash # 설명: USER_INFO_DUMMY 사용 여부 확인 # 테스트: USER_INFO_DUMMY 사용 검색. 예상 결과: 사용 중인 곳이 없어야 함 rg --type ts --type js "USER_INFO_DUMMY"Length of output: 40
src/components/common/ValidationInput.tsx (2)
18-18: JSDoc에 새로운 매개변수가 적절히 추가되었습니다.
buttonDisabled매개변수에 대한 설명이 명확하게 추가되었습니다. 이는 컴포넌트의 기능을 잘 문서화하고 있습니다.
43-43: ValidationInputProps 타입에 새로운 프로퍼티가 올바르게 추가되었습니다.
buttonDisabled프로퍼티가 선택적 불리언 타입으로 적절히 추가되었습니다. 이는 JSDoc 및 컴포넌트의 기능과 일치합니다.src/services/authService.ts (4)
13-14: 새로운 타입 import가 올바르게 추가되었습니다.
CheckNicknameForm과UserSignUpRequest타입이 적절하게 추가되었습니다. 이는 새로 구현된 함수들에서 사용되며, 기존 코드의 명명 규칙을 따르고 있습니다.
17-28: 회원가입 API 함수가 올바르게 구현되었습니다.
signUp함수가 다음과 같이 적절하게 구현되었습니다:
- 비동기 함수로 올바르게 선언되었습니다.
UserSignUpRequest타입의signUpForm과 선택적axiosConfig를 매개변수로 받습니다.- 인증이 필요하지 않은 요청에
defaultAxios인스턴스를 사용합니다.- JSDoc 주석이 상세하고 기존 스타일을 따릅니다.
함수의 구현이 파일의 다른 함수들과 일관성을 유지하고 있습니다.
30-41: 닉네임 중복 확인 API 함수가 올바르게 구현되었습니다.
checkNicknameDuplicate함수가 다음과 같이 적절하게 구현되었습니다:
- 비동기 함수로 올바르게 선언되었습니다.
CheckNicknameForm타입의nicknameForm과 선택적axiosConfig를 매개변수로 받습니다.- 인증이 필요하지 않은 요청에
defaultAxios인스턴스를 사용합니다.- JSDoc 주석이 상세하고 기존 스타일을 따릅니다.
함수의 구현이 파일의 다른 함수들과 일관성을 유지하고 있습니다.
Line range hint
1-41: 전체적인 변경 사항이 적절하게 구현되었습니다.이 PR에서
authService.ts파일에 다음과 같은 변경 사항이 추가되었습니다:
- 새로운 타입
CheckNicknameForm과UserSignUpRequest가 import 되었습니다.- 회원가입을 위한
signUp함수가 추가되었습니다.- 닉네임 중복 확인을 위한
checkNicknameDuplicate함수가 추가되었습니다.이러한 변경 사항들은 기존 코드의 스타일과 구조를 일관성 있게 따르고 있으며, 요구된 기능을 적절히 구현하고 있습니다. 새로운 함수들은 기존 함수들과 유사한 패턴을 사용하여 구현되었으며, JSDoc 주석도 상세하게 작성되어 있습니다.
전반적으로 이 변경 사항들은 잘 구현되었으며, 코드의 품질과 일관성을 유지하고 있습니다.
src/mocks/mockData.ts (1)
38-38: TEMP_PASSWORD_DUMMY의 용도를 명확히 해주세요.이 상수의 목적이 불분명합니다. 임시 비밀번호로 보이는데, 하드코딩된 비밀번호는 보안 위험이 될 수 있습니다.
다음 스크립트를 실행하여 이 상수의 사용처를 확인하세요:
#!/bin/bash # Description: TEMP_PASSWORD_DUMMY 상수의 사용처를 검색합니다. rg --type typescript "TEMP_PASSWORD_DUMMY"제안:
- 이 상수의 용도를 주석으로 명확히 설명해주세요.
- 가능하다면 환경 변수나 설정 파일을 통해 관리하는 것이 좋습니다.
- 프로덕션 환경에서 실수로 사용되지 않도록 주의해주세요.
src/pages/user/SignUpPage.tsx (13)
1-4: 필요한 모듈 임포트 확인했습니다.React 관련 훅과 AxiosError, useNavigate 등 필요한 모듈을 적절하게 임포트하였습니다.
11-11: 사용자 인증 서비스 함수 임포트 확인했습니다.
checkNicknameDuplicate와signUp함수를 올바르게 임포트하였습니다.
15-16: 네비게이션 훅 및 닉네임 체크 상태 설정 확인했습니다.
useNavigate훅과checkedNickname상태 관리가 올바르게 설정되었습니다.
23-23:defaultValues에서username초기값 변경 확인했습니다.
username의 초기값을null에서 빈 문자열로 변경하여 폼 초기화 시 안정성을 높였습니다.
34-35: 폼 메서드 구조 분해 할당 및 닉네임 watch 설정 확인했습니다.폼 관련 메서드들을 구조 분해 할당하고,
nickname필드를watch로 설정하여 실시간으로 값 변화를 감지하도록 구현했습니다.
38-40: 닉네임 변경 시 중복 확인 상태 초기화 로직 확인했습니다.
useEffect를 활용하여 닉네임 필드가 변경되면checkedNickname상태를false로 설정하여 중복 확인 버튼을 재활성화하는 로직이 올바르게 구현되었습니다.
43-55: 닉네임 중복 확인 함수 구현 확인했습니다.닉네임의 유효성을 확인하고, 성공 및 에러에 따른 토스트 메시지를 적절히 표시하는 로직이 잘 구현되었습니다.
56-59: 인증 코드 요청 함수 구현 확인했습니다.
checkedNickname상태를 확인하여 닉네임 중복 체크가 완료된 경우에만 인증 코드를 요청하는 로직이 올바르게 구현되었습니다.
63-63: 회원가입 데이터 처리 로직 확인했습니다.
checkPassword를 제외한 나머지 데이터를filteredData로 전달하여 불필요한 데이터가 전송되지 않도록 처리한 점이 좋습니다.
88-88: 폼 제출 핸들러 설정 확인했습니다.
handleSubmit을 통해 폼 제출 시 유효성 검사가 이루어지도록 설정되었습니다.
92-93: 폼 필드의 에러 처리 및 등록 확인했습니다.각 입력 필드에 대해
errors와register를 적절히 사용하여 유효성 검사와 에러 메시지 처리가 잘 구현되었습니다.Also applies to: 99-100, 106-107, 114-115, 125-126, 133-134
118-119: 중복 확인 버튼의 비활성화 처리 확인했습니다.닉네임 중복 확인 후 버튼이 비활성화되며,
checkNickname함수를 통해 다시 확인할 수 있도록 구현되었습니다.
144-144: 자기소개 필드 등록 확인했습니다.
register('bio')를 통해 자기소개 필드가 폼 데이터에 포함되도록 설정되었습니다.
|
@Seok93 리뷰 감사합니다! |
PR Type
What kind of change does this PR introduce?
Related Issues
#159 닉네임 중복 확인 API 및 회원가입 기능 구현
What does this PR do?
View
mock데이터에 존재하지 않는 유저를 회원가입시키고, 로그인하는 과정입니다.
Other information
토큰에서 userId 추출관련 분기문이 보이신다면 그 부분을 처리해 준 내용입니다.)