Feat: #146 비밀번호 변경 전 인증 페이지의 인증 로직 구현 #162
Conversation
Walkthrough이번 변경 사항은 사용자 인증 및 이메일 인증 프로세스를 개선하기 위해 여러 파일에서 수정이 이루어졌습니다. Changes
Possibly related issues
Possibly related PRs
Suggested labels
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: 8
🧹 Outside diff range and nitpick comments (18)
src/constants/settings.ts (1)
7-7: 변경 사항이 적절해 보입니다.이메일 인증 만료 시간을 15분으로 설정한 것은 합리적인 선택입니다.
AUTH_SETTINGS객체 내에VERIFIED_EXPIRATION을 추가한 것은 인증 관련 설정을 한 곳에 모아 관리하는 좋은 방법입니다.가독성을 높이기 위해 상수에 간단한 주석을 추가하는 것이 좋을 것 같습니다. 다음과 같이 변경하는 것은 어떨까요?
- VERIFIED_EXPIRATION: 15 * MINUTE, + VERIFIED_EXPIRATION: 15 * MINUTE, // 이메일 인증 만료 시간src/pages/user/SearchPasswordPage.tsx (2)
Line range hint
43-59: onSubmit 함수 리팩토링 제안
onSubmit함수의 구조를 개선할 수 있을 것 같습니다:
- try-catch 블록 내부의 로직을 별도의 함수로 추출하여 가독성을 높이세요.
- 에러 처리 로직을 더 세분화하여 다양한 에러 상황에 대응할 수 있도록 개선하세요.
- TODO 주석에 언급된 대로
useAxios훅을 사용하여 네트워크 요청을 처리하면 코드를 더 간결하게 만들 수 있습니다.다음과 같은 구조로 리팩토링을 고려해보세요:
const handleSearchPassword = async (data: SearchPasswordForm) => { const fetchData = await searchUserPassword(data); setTempPassword(fetchData.data.password); }; const handleError = (error: unknown) => { if (error instanceof AxiosError && error.response) { if (error.response.status === 401) handleVerificationError(); else if (error.response.status === 404) toastError('사용자를 찾을 수 없습니다.'); else toastError(error.response.data.message); } else { toastError('예상치 못한 에러가 발생했습니다.'); } }; const onSubmit = async (data: SearchPasswordForm) => { setLoading(true); try { await handleSearchPassword(data); } catch (error) { handleError(error); } finally { setLoading(false); } };이렇게 리팩토링하면 각 함수의 책임이 명확해지고, 에러 처리도 더 세분화될 수 있습니다.
Line range hint
61-76: 컴포넌트 구조 개선 제안현재
SearchPasswordPage컴포넌트의 구조를 더 작고 집중된 컴포넌트들로 나누면 코드의 가독성과 재사용성을 높일 수 있을 것 같습니다:
폼 처리 로직을 커스텀 훅으로 추출하세요. 예:
useSearchPasswordForm로딩 스피너, 검색 결과, 검색 데이터 폼을 별도의 컴포넌트로 분리하세요. 예:
LoadingSpinnerSearchResultDisplaySearchPasswordForm메인 컴포넌트에서는 이러한 작은 컴포넌트들을 조합하여 사용하세요.
예시 구조:
export default function SearchPasswordPage() { const { formMethods, loading, tempPassword, handleSubmit } = useSearchPasswordForm(); return ( <FormProvider {...formMethods}> <AuthFormLayout onSubmit={handleSubmit}> {loading && <LoadingSpinner />} {!loading && tempPassword && <SearchResultDisplay password={tempPassword} />} {!loading && !tempPassword && <SearchPasswordForm />} </AuthFormLayout> </FormProvider> ); }이렇게 구조를 개선하면 각 컴포넌트의 책임이 명확해지고, 테스트와 유지보수가 더 쉬워질 것입니다.
src/pages/user/SearchIdPage.tsx (1)
40-40: setValue 함수 호출의 변경이 적절합니다.'code'에서 'verificationCode'로의 변경이 setValue 함수 호출에도 일관되게 적용되었습니다. 이는 폼 필드의 이름 변경과 일치하며, 값 재설정이 올바르게 이루어지도록 합니다.
오류 처리를 개선하기 위해 다음과 같은 변경을 고려해 보세요:
- setValue('verificationCode', ''); + setValue('verificationCode', '', { shouldValidate: true });이 변경으로 값을 재설정할 때 유효성 검사가 즉시 트리거되어, 사용자에게 더 빠른 피드백을 제공할 수 있습니다.
src/pages/setting/UserPasswordSettingPage.tsx (3)
13-13: 인증 확인 로직이 잘 구현되었습니다. 단, useEffect의 의존성 배열을 개선할 수 있습니다.
isVerified상태와 useEffect를 사용하여 사용자 인증을 확인하고 필요시 리다이렉션하는 로직이 잘 구현되었습니다.하지만 useEffect의 의존성 배열에
navigate함수를 추가하는 것이 좋습니다:useEffect(() => { if (!isVerified) navigate('/setting/auth', { replace: true }); }, [isVerified, navigate]);이렇게 하면
navigate함수가 변경될 때마다 (드물지만 가능한 시나리오) effect가 올바르게 동작하게 됩니다.Also applies to: 25-27
30-31: 네트워크 로직 개선에 대한 TODO 주석을 작업 항목으로 만들어주세요.현재 코드에 "useAxios 훅을 이용한 네트워크 로직으로 변경" 이라는 TODO 주석이 있습니다. 이 개선 사항을 놓치지 않도록 별도의 작업 항목(예: GitHub Issue)으로 만들어 추적하는 것이 좋겠습니다.
이렇게 하면 코드의 일관성을 유지하고 향후 유지보수를 용이하게 할 수 있습니다.
이 TODO에 대한 GitHub Issue를 생성해드릴까요?
Line range hint
30-40: 에러 처리를 더 구체적으로 개선할 수 있습니다.현재 에러 처리 로직이 잘 구현되어 있지만, 더 구체적인 에러 메시지를 제공하면 사용자 경험을 향상시킬 수 있습니다. 예를 들어:
try { await updateUserPassword(submitData); toastSuccess('비밀번호가 변경되었습니다.'); setTimeout(() => { navigate('/setting/user', { replace: true }); }, 2000); } catch (error) { if (error instanceof AxiosError) { switch (error.response?.status) { case 400: toastError('잘못된 요청입니다. 입력 정보를 확인해주세요.'); break; case 401: toastError('인증에 실패했습니다. 다시 로그인해주세요.'); // 로그인 페이지로 리다이렉션 로직 추가 break; case 403: toastError('비밀번호 변경 권한이 없습니다.'); break; default: toastError('서버 오류가 발생했습니다. 잠시 후 다시 시도해주세요.'); } } else { toastError('예상치 못한 에러가 발생했습니다.'); } }이렇게 하면 사용자에게 더 명확한 피드백을 제공할 수 있습니다.
src/stores/useStore.ts (2)
15-15:onVerifyCode메서드 추가 승인 및 문서화 제안
AuthStore타입에onVerifyCode메서드를 추가한 것은 적절합니다. 이는 이메일 인증 프로세스를 트리거하는 데 사용될 것으로 보입니다.메서드의 목적과 사용 방법을 명확히 하기 위해 간단한 JSDoc 주석을 추가하는 것이 좋겠습니다. 예를 들어:
/** 이메일 인증 코드를 확인하고 사용자의 인증 상태를 업데이트합니다. */ onVerifyCode: () => void;
54-64:onVerifyCode구현 승인 및 개선 제안
onVerifyCode메서드의 구현이 잘 되었습니다. 인증 상태를 설정하고 일정 시간 후에 만료시키는 로직이 PR의 목적에 잘 부합합니다.다음과 같은 작은 개선을 제안합니다:
- 타임아웃 ID를 저장하고 필요한 경우 취소할 수 있도록 하는 것이 좋겠습니다. 이렇게 하면 사용자가 재인증을 시도할 때 이전 타임아웃을 정리할 수 있습니다.
onVerifyCode: () => { let timeoutId: NodeJS.Timeout; set((state) => { // 이전 타임아웃이 있다면 취소 if (state.verificationTimeoutId) { clearTimeout(state.verificationTimeoutId); } timeoutId = setTimeout(() => { set({ isVerified: false, verificationTimeoutId: null }); }, AUTH_SETTINGS.VERIFIED_EXPIRATION); return { isVerified: true, verificationTimeoutId: timeoutId }; }); },
- 인증 만료 시간을 상수로 정의하고 있는데, 이 값이 어떻게 설정되었는지 주석으로 설명하면 좋겠습니다. 특히 PR 설명에서 언급된 6초 테스트 값이 그대로 사용되고 있다면, 이를 명확히 해주세요.
src/pages/setting/UserSettingPage.tsx (3)
Line range hint
26-31: 폼 제출 로직 구현 필요onSubmit 함수가 현재 폼 데이터를 콘솔에 로그하고 있지만, 실제 제출 로직은 구현되지 않았습니다. TODO 주석에 언급된 대로 폼 제출 로직을 구현해야 합니다.
폼 제출 로직 구현에 도움이 필요하신가요? 기본적인 구조를 제안해 드릴 수 있습니다.
6-6: 사용되지 않는 import 제거 고려USER_INFO_DUMMY가 import되었지만 현재 코드에서 사용되지 않는 것으로 보입니다. 사용되지 않는 import는 제거하는 것이 좋습니다.
다음과 같이 수정하는 것을 고려해 보세요:
-import { USER_INFO_DUMMY } from '@mocks/mockData';
Line range hint
26-31: 에러 처리 로직 추가 권장폼 제출 시 발생할 수 있는 에러에 대한 처리가 구현되어 있지 않습니다. 사용자 경험 향상을 위해 에러 처리 로직을 추가하는 것이 좋습니다.
다음과 같은 에러 처리 로직 추가를 고려해 보세요:
const onSubmit = async (data: EditUserInfoForm) => { try { const { username, email, profileImageName, ...filteredData } = data; // TODO: API 호출 로직 구현 // const response = await api.updateUserInfo(filteredData); console.log('User info updated successfully'); } catch (error) { console.error('Failed to update user info:', error); // TODO: 사용자에게 에러 메시지 표시 } };src/services/authService.ts (1)
Line range hint
77-87: LGTM! 인증되지 않은 사용자를 위한 적절한 변경사항입니다.
authAxios에서defaultAxios로의 변경은 이메일 인증 코드 전송이 인증되지 않은 사용자를 위한 것임을 명확히 합니다. 이는 일반적인 이메일 인증 흐름과 일치합니다.함수 주석을 더 명확하게 하기 위해 다음과 같이 수정하는 것은 어떨까요?
/** - * 이메일 인증 번호 발송 요청 API + * 이메일 인증 번호 발송 요청 API (인증 불필요) * * @export * @async * @param {RequestEmailCode} email - 이메일 * @param {AxiosRequestConfig} [axiosConfig={}] - axios 요청 옵션 설정 객체 * @returns {Promise<AxiosResponse>} */src/pages/user/SignUpPage.tsx (1)
35-35: 변경 사항이 일관성 있게 적용되었습니다.'code'에서 'verificationCode'로의 이름 변경이 onSubmit 함수 내에서도 일관되게 적용되었습니다. 이는 좋은 변경입니다.
작은 개선 사항으로, 폼 데이터를 서버로 보내기 전에 'verificationCode'의 유효성을 한 번 더 확인하는 것이 좋을 것 같습니다. 예를 들어:
if (!verificationCode) { return toastError('인증 코드를 입력해주세요.'); }이렇게 하면 사용자 경험을 개선하고 불필요한 서버 요청을 줄일 수 있습니다.
Also applies to: 40-40
src/mocks/services/authServiceHandler.ts (2)
21-21: 인증 로직 개선
USER_INFO_DUMMY를 사용하여 사용자 이름과 비밀번호를 검증하는 것은 좋은 접근 방식입니다. 이는 코드의 일관성과 유지보수성을 향상시킵니다.보안을 더욱 강화하기 위해 비밀번호 비교 시 시간 상수 비교 함수를 사용하는 것을 고려해 보세요. 예를 들어:
import { timingSafeEqual } from 'crypto'; if (username === USER_INFO_DUMMY.username && timingSafeEqual(Buffer.from(password), Buffer.from(USER_INFO_DUMMY.password))) { // ... }이렇게 하면 타이밍 공격에 대한 추가적인 보호를 제공할 수 있습니다.
131-139: 이메일 인증 코드 확인 API 추가이메일 인증 코드 확인을 위한 새로운 API 핸들러를 추가한 것은 좋은 변경사항입니다. 이는 PR의 목표인 이메일 인증 로직 구현과 일치합니다.
보안을 강화하기 위해 인증 코드 비교 시에도 시간 상수 비교를 사용하는 것이 좋습니다. 예를 들어:
import { timingSafeEqual } from 'crypto'; if (email !== USER_INFO_DUMMY.email || !timingSafeEqual(Buffer.from(verificationCode), Buffer.from(VERIFICATION_CODE_DUMMY))) { // ... }이렇게 하면 타이밍 공격에 대한 추가적인 보호를 제공할 수 있습니다.
src/mocks/mockData.ts (1)
37-37: 상수 이름 변경이 적절합니다.상수 이름을
emailVerificationCode에서VERIFICATION_CODE_DUMMY로 변경한 것은 좋은 선택입니다. 이 변경으로 다음과 같은 이점이 있습니다:
- 다른 더미 데이터 상수들(예:
JWT_TOKEN_DUMMY)과 일관성이 유지됩니다.- 이 값이 테스트용 더미 데이터임을 명확히 나타냅니다.
더 나아가, 이 상수가 이메일 인증용이라는 것을 명확히 하기 위해
EMAIL_VERIFICATION_CODE_DUMMY로 이름을 변경하는 것을 고려해 보시는 것은 어떨까요? 이렇게 하면 상수의 목적이 더욱 명확해질 것 같습니다.src/pages/setting/UserAuthenticatePage.tsx (1)
31-32: 인증 성공 시 사용자에게 알림 메시지를 표시해주세요이메일 인증 코드 검증에 성공한 후, 사용자에게 인증 성공 메시지를 표시하면 더 좋은 사용자 경험을 제공할 수 있습니다.
onVerifyCode()호출 후에 성공 토스트 메시지를 추가하는 것을 고려해주세요.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (13)
- src/constants/settings.ts (1 hunks)
- src/mocks/mockData.ts (1 hunks)
- src/mocks/services/authServiceHandler.ts (5 hunks)
- src/pages/setting/UserAuthenticatePage.tsx (3 hunks)
- src/pages/setting/UserPasswordSettingPage.tsx (2 hunks)
- src/pages/setting/UserSettingPage.tsx (1 hunks)
- src/pages/user/SearchIdPage.tsx (2 hunks)
- src/pages/user/SearchPasswordPage.tsx (2 hunks)
- src/pages/user/SignUpPage.tsx (3 hunks)
- src/services/authService.ts (2 hunks)
- src/services/axiosProvider.ts (2 hunks)
- src/stores/useStore.ts (3 hunks)
- src/types/UserType.tsx (2 hunks)
🧰 Additional context used
Biome
src/mocks/services/authServiceHandler.ts
[error] 118-121: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments not posted (19)
src/types/UserType.tsx (3)
20-20: 'code'에서 'verificationCode'로의 이름 변경이 적절합니다.'code'에서 'verificationCode'로의 이름 변경은 타입의 의도를 더 명확하게 전달합니다. 이는 코드의 가독성과 유지보수성을 향상시킵니다.
29-29: 'EmailVerificationForm' 타입에서의 일관된 이름 변경을 승인합니다.'code'에서 'verificationCode'로의 이름 변경이
EmailVerificationForm타입에서도 일관되게 적용되었습니다. 이는 코드베이스 전체의 일관성을 유지하는 데 도움이 됩니다.
31-31: 모든 관련 타입에서의 일관된 이름 변경을 승인합니다.
SearchPasswordForm타입에서도 'code'가 'verificationCode'로 변경되었습니다. 이로써 모든 관련 타입(UserSignUpForm,EmailVerificationForm,SearchPasswordForm)에서 일관된 이름 변경이 이루어졌습니다. 이러한 일관된 변경은 코드의 전반적인 품질과 유지보수성을 향상시킵니다.src/pages/user/SearchIdPage.tsx (3)
36-39: setError 함수 호출의 변경이 적절합니다.'code'에서 'verificationCode'로의 변경이 setError 함수 호출에도 일관되게 적용되었습니다. 이는 폼 필드의 이름 변경과 일치하며, 오류 처리가 올바르게 연결되도록 보장합니다.
Line range hint
1-75: 전반적인 변경 사항이 적절합니다.'code'에서 'verificationCode'로의 변수명 변경이 일관되게 적용되었습니다. 이러한 변경은 코드의 가독성을 향상시키고, 변수의 목적을 더 명확하게 표현합니다. 폼 관리, 오류 처리, 값 재설정 등 모든 관련 로직이 올바르게 업데이트되었습니다.
다음 사항을 고려해 보세요:
- 제안된 setValue 함수 호출 개선을 통해 사용자에게 더 빠른 피드백을 제공할 수 있습니다.
- 이메일 인증 확인 API가 아직 구현되지 않았다는 점을 고려하여, 향후 실제 API 구현 시 관련 로직을 재검토하고 필요한 경우 수정하세요.
전체적으로, 이 변경사항은 PR의 목표를 잘 달성하고 있으며, 코드 품질을 향상시키고 있습니다.
23-23: 변수명 변경이 적절합니다.'code'에서 'verificationCode'로의 변경은 변수의 목적을 더 명확하게 표현합니다. 이는 코드의 가독성을 향상시킵니다.
다음 스크립트를 실행하여 변경된 변수명이 파일 전체에서 일관되게 사용되는지 확인하세요:
✅ Verification successful
변수명이 일관되게 변경되었습니다.
'code' 변수의 사용이 제거되고, 'verificationCode'로 모두 변경되었습니다. 변경사항이 문제없이 반영되었습니다.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # 설명: 'code'에서 'verificationCode'로의 변경이 일관되게 적용되었는지 확인합니다. # 테스트: 'code' 변수 사용 여부 확인. 예상 결과: 'code' 변수 사용이 없어야 함. rg '\bcode\b' src/pages/user/SearchIdPage.tsx # 테스트: 'verificationCode' 변수 사용 확인. 예상 결과: 'verificationCode' 변수 사용이 있어야 함. rg '\bverificationCode\b' src/pages/user/SearchIdPage.tsxLength of output: 208
src/pages/setting/UserPasswordSettingPage.tsx (1)
1-2: import 문 변경이 적절합니다.새로운 기능을 위해 필요한
useEffect,useNavigate, 그리고useStore를 적절히 추가했습니다. 또한 import 문을 재정렬하여 가독성을 향상시켰습니다.Also applies to: 8-9
src/stores/useStore.ts (1)
11-11: LGTM:isVerified속성 추가
AuthStore타입에isVerified불리언 속성을 추가한 것은 적절합니다. 이는 사용자의 이메일 인증 상태를 추적하는 데 사용될 것으로 보입니다.src/pages/setting/UserSettingPage.tsx (2)
6-6: import 문 순서 개선import 문의 순서를 변경하여 코드 구성이 개선되었습니다. 이는 가독성을 높이고 관련 import를 그룹화하는 데 도움이 됩니다.
11-11: 사용자 정보 접근 방식 개선useStore에서 사용자 정보를 가져오는 방식이 개선되었습니다. 객체 구조 분해를 사용하여 코드가 더 간결해졌고, 현대적인 JavaScript 관행에 더 잘 부합합니다.
다만, 다음 사항을 고려해 보시기 바랍니다:
- userInfo가 undefined일 경우에 대한 처리가 필요할 수 있습니다. 옵셔널 체이닝을 사용하거나 기본값을 제공하는 것이 좋습니다.
- 컴포넌트가 다시 렌더링될 때마다 useStore가 호출됩니다. 성능 최적화를 위해 useMemo나 useCallback을 고려해 볼 수 있습니다.
다음 스크립트를 실행하여 useStore의 사용을 확인해 보세요:
src/services/authService.ts (1)
89-99:⚠️ Potential issue이메일 인증 로직이 잘 구현되었습니다. 하지만
authAxios사용에 대해 재고해 볼 필요가 있습니다.새로운
checkEmailCode함수의 추가는 PR의 목적과 잘 부합합니다. 그러나 이메일 인증 과정에서authAxios를 사용하는 것은 일반적이지 않습니다.이메일 인증은 보통 로그인 전에 이루어지는 과정이므로,
authAxios대신defaultAxios를 사용하는 것이 더 적절할 수 있습니다. 다음과 같이 수정하는 것을 고려해보세요:export async function checkEmailCode(verifyForm: EmailVerificationForm, axiosConfig: AxiosRequestConfig = {}) { - return authAxios.post('user/verify/code', verifyForm, axiosConfig); + return defaultAxios.post('user/verify/code', verifyForm, axiosConfig); }만약 인증된 사용자만 이 기능을 사용해야 한다면, 함수 주석에 이를 명시하는 것이 좋습니다.
다음 스크립트를 실행하여
authAxios의 사용을 확인해 보세요:이 결과를 바탕으로
authAxios의 사용이 일관되게 적용되고 있는지 확인하시기 바랍니다.src/pages/user/SignUpPage.tsx (2)
23-23: 변경 사항이 적절합니다.'code'에서 'verificationCode'로의 이름 변경은 필드의 목적을 더 명확하게 나타냅니다. 이는 코드의 가독성을 향상시키는 좋은 변경입니다.
Line range hint
1-160: 이메일 인증 로직 구현에 대한 확인이 필요합니다.PR 목표에 언급된 이메일 인증 로직의 구현이 이 파일에서 직접적으로 보이지 않습니다. 'verificationCode' 필드의 추가는 좋은 시작이지만, 실제 인증 프로세스의 구현이 필요해 보입니다.
다음 사항들을 확인해 주세요:
- 이메일 인증 요청 및 확인을 처리하는 함수가 구현되어 있는지
- 인증 정보를 Zustand에 저장하는 로직이 있는지
- 인증 만료 시 사용자를 리다이렉트하는 로직이 구현되어 있는지
이러한 로직들이 다른 파일에 구현되어 있다면, 그 파일들을 리뷰에 포함시키는 것이 좋을 것 같습니다.
다음 스크립트를 실행하여 관련 구현을 찾아볼 수 있습니다:
#!/bin/bash # Description: Search for email verification related implementations # Look for email verification related functions rg --type typescript "function.*(email|verification|authenticate)" -g '!*.test.ts' # Look for Zustand store related to authentication rg --type typescript "create.*Store.*auth" -g '!*.test.ts' # Look for redirection logic related to authentication rg --type typescript "(redirect|navigate).*auth" -g '!*.test.ts'src/mocks/services/authServiceHandler.ts (5)
4-4: 코드 개선: 상수 도입
VERIFICATION_CODE_DUMMY와USER_INFO_DUMMY를 도입한 것은 좋은 변경사항입니다. 이는 코드의 유지보수성을 향상시키고 하드코딩을 줄이는 데 도움이 됩니다.
Line range hint
121-129: 이메일 인증 로직 개선이메일 인증 번호 요청 API의 주석을 업데이트하고
USER_INFO_DUMMY.email을 사용하여 이메일을 검증하는 변경사항은 적절합니다. 이는 코드의 일관성을 유지하고 가독성을 향상시킵니다.🧰 Tools
Biome
[error] 118-121: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
143-145: 사용자 이름 복구 API 개선변수명을
code에서verificationCode로 변경하고VERIFICATION_CODE_DUMMY를 사용하여 인증 코드를 검증하는 변경사항은 적절합니다. 이는 코드의 일관성과 가독성을 향상시킵니다.
160-164: 비밀번호 복구 API 개선사용자 이름 복구 API와 마찬가지로, 변수명을
code에서verificationCode로 변경하고VERIFICATION_CODE_DUMMY를 사용하여 인증 코드를 검증하는 변경사항은 적절합니다. 이는 코드의 일관성을 유지하고 가독성을 향상시킵니다.
118-121: 정적 분석 도구 제안 검토Biome 정적 분석 도구가 118-121 라인에 대해 옵셔널 체이닝(optional chaining)을 사용하도록 제안했습니다. 이 변경이 필요한지 확인하기 위해 해당 코드 부분을 더 자세히 살펴볼 필요가 있습니다.
다음 스크립트를 실행하여 해당 코드 부분을 확인해 주세요:
이 결과를 바탕으로 옵셔널 체이닝 적용이 적절한지 판단할 수 있을 것입니다.
🧰 Tools
Biome
[error] 118-121: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
src/services/axiosProvider.ts (1)
9-9: Axios 타입 선언 추가 확인
axios에서AxiosInstance와AxiosRequestConfig타입을 가져와 타입 안전성을 높였습니다.
|
@Seok93 리뷰 감사합니다! 네 생각보다 주석 처리 해야 하는 영역이 적어서 수정 작업도 금방 할 수 있을 것 같아요.ㅎㅎ |
Yoonyesol
deleted the
feature/#146-email-auth-for-password-update-access
branch
PR Type
What kind of change does this PR introduce?
Related Issues
#146 비밀번호 변경 전 인증 페이지의 인증 로직 구현
What does this PR do?
code->verificationCode로 변경authAxios를 사용하는 API에서 401에러 코드를 응답으로 받았을 때 로그인 화면으로 강제 이동하는 에러 수정Other information
만료시간을 6초로 설정한 뒤 테스트해보았습니다.
Other information
이메일 인증 확인 API가 만들어지지 않은 상태라 임의로 엔드포인트와 응답을 설정해서 기능을 구현했습니다.isAuthenticated변수가 초기화되는 문제와 함께 따로 구현해 PR 올리도록 하겠습니다.