[Fix] mypage redirect 로직 수정 #234
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Walkthrough사용자 타입의 Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🎭 Playwright Report✨ E2E Test가 성공적으로 완료되었습니다. Test 요약 내용을 확인해주세요.
📊 Test Summary
📜 Test Details✅ Passed Tests (3)
|
🎨 Storybook Report✅ 변경 사항이 없습니다 모든 Story가 이전 빌드와 동일합니다.
|
📊 Coverage Report
➡️ #234을 main에 병합하면 coverage가 Coverage 요약@@ Coverage Diff @@
## main #234 +/- ##
===========================================
Coverage 38.24% 38.24% 0.00%
===========================================
Files 175 175 0
Lines 7574 7574 0
Branches 330 330 0
===========================================
Hits 2897 2897 0
Misses 4677 4677 0 영향받은 파일✅ 이 PR로 영향받은 파일이 없습니다 수정된 모든 파일이 현재 coverage를 유지했습니다. |
🚀 PR Preview Report✨ Build가 성공적으로 완료되었습니다. Preview에서 변경사항을 확인하세요.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Chiman2937
force-pushed
the
chiyoung-fix/mypage
branch
from
099aa9b to
6b4dce5
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/app/(user)/mypage/layout.tsxsrc/app/(user)/profile/[userId]/layout.tsxsrc/mock/service/user/user-mock.tssrc/types/service/user.ts
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: Chiman2937
Repo: WeGo-Together/WeGo_FrontEnd PR: 230
File: src/mock/service/user/user-handler.ts:8-43
Timestamp: 2025-12-23T09:36:26.773Z
Learning: In the WeGo_FrontEnd repository's user mock handlers (src/mock/service/user/user-handler.ts), the follow API mock should return only a success message without user data using createMockSuccessResponse('팔로우 성공'), as the actual API doesn't return user data on successful follow.
📚 Learning: 2025-12-23T09:36:26.773Z
Learnt from: Chiman2937
Repo: WeGo-Together/WeGo_FrontEnd PR: 230
File: src/mock/service/user/user-handler.ts:8-43
Timestamp: 2025-12-23T09:36:26.773Z
Learning: In the WeGo_FrontEnd repository's user mock handlers (src/mock/service/user/user-handler.ts), the follow API mock should return only a success message without user data using createMockSuccessResponse('팔로우 성공'), as the actual API doesn't return user data on successful follow.
Applied to files:
src/mock/service/user/user-mock.ts
📚 Learning: 2025-12-23T09:36:26.774Z
Learnt from: Chiman2937
Repo: WeGo-Together/WeGo_FrontEnd PR: 230
File: src/mock/service/user/user-handler.ts:8-43
Timestamp: 2025-12-23T09:36:26.774Z
Learning: In the WeGo_FrontEnd repository, isFollow === false represents "not currently following" state, meaning a follow action is allowed and should succeed.
Applied to files:
src/mock/service/user/user-mock.tssrc/types/service/user.ts
🧬 Code graph analysis (1)
src/app/(user)/profile/[userId]/layout.tsx (3)
src/lib/query-client.ts (1)
getQueryClient(15-22)src/lib/query-key/query-key-user/index.ts (1)
userKeys(1-6)src/api/index.ts (1)
API(22-22)
🔇 Additional comments (3)
src/mock/service/user/user-mock.ts (1)
18-18: LGTM! Mock 데이터가 새로운 타입 정의와 일치합니다.
isFollow: null값이 본인 페이지를 나타내는 새로운 리다이렉트 로직과 올바르게 정렬되었습니다.src/app/(user)/mypage/layout.tsx (1)
11-12:force-dynamic설정이 올바르게 추가되었습니다.이 설정은 마이페이지가 항상 최신 사용자 데이터를 가져오도록 보장합니다. 커밋 메시지 "fix: mypage에 force-dynamic 추가"와 일치합니다.
src/app/(user)/profile/[userId]/layout.tsx (1)
18-19: LGTM! 숫자가 아닌 userId에 대한 검증이 추가되었습니다.
notFound()호출을 통해 잘못된 경로 파라미터를 적절히 처리하고 있습니다.
| await queryClient.fetchQuery({ | ||
| queryKey: userKeys.me(), | ||
| queryFn: () => API.userService.getMe(), | ||
| }); |
There was a problem hiding this comment.
API 실패 시 에러 처리가 누락되었습니다.
이전에 존재하던 try/catch 에러 처리 로직이 제거되었습니다. 현재 코드에서는 getMe() API 호출이 실패할 경우 (네트워크 오류, 인증 실패 등) 처리되지 않은 예외가 발생하여 전체 페이지가 에러 상태가 됩니다.
사용자 경험 향상을 위해 에러 처리를 추가하거나, 최소한 적절한 에러 바운더리를 설정하는 것을 권장합니다.
🔎 에러 처리 추가 예시
const MyPageLayout = async ({ children }: Props) => {
const queryClient = getQueryClient();
- await queryClient.fetchQuery({
- queryKey: userKeys.me(),
- queryFn: () => API.userService.getMe(),
- });
+ try {
+ await queryClient.fetchQuery({
+ queryKey: userKeys.me(),
+ queryFn: () => API.userService.getMe(),
+ });
+ } catch (error) {
+ // 적절한 에러 처리 (예: 로그인 페이지로 리다이렉트)
+ redirect('/login');
+ }
return <HydrationBoundary state={dehydrate(queryClient)}>{children}</HydrationBoundary>;
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| await queryClient.fetchQuery({ | |
| queryKey: userKeys.me(), | |
| queryFn: () => API.userService.getMe(), | |
| }); | |
| try { | |
| await queryClient.fetchQuery({ | |
| queryKey: userKeys.me(), | |
| queryFn: () => API.userService.getMe(), | |
| }); | |
| } catch (error) { | |
| // 적절한 에러 처리 (예: 로그인 페이지로 리다이렉트) | |
| redirect('/login'); | |
| } |
🤖 Prompt for AI Agents
In src/app/(user)/mypage/layout.tsx around lines 16 to 19, the call to
queryClient.fetchQuery for userKeys.me() lacks error handling so any API failure
will throw and crash the page; wrap the fetchQuery call in a try/catch (or use
.catch) to handle network/auth errors, log the error, and provide a fallback
path such as returning a safe default user state, redirecting to a login/error
page, or throwing a controlled error for an ErrorBoundary so the page doesn't
crash unexpectedly; ensure the chosen branch preserves type expectations and
downstream rendering (e.g., return null or a default object) and surface
user-friendly behavior.
| const user = await queryClient.fetchQuery({ | ||
| queryKey: userKeys.item(userId), | ||
| queryFn: () => API.userService.getUser({ userId }), | ||
| }); | ||
|
|
||
| // isFollow가 null이면 본인 페이지 이므로 mypage로 redirect 처리 | ||
| if (user.isFollow === null) redirect('/mypage'); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the getUser API implementation and schema
find . -type f -name "*.ts" -o -name "*.tsx" | head -20Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 692
🏁 Script executed:
# Search for API service definition to understand getUser response
rg "getUser" --type ts --type tsx -A 5 | head -50Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 98
🏁 Script executed:
# Look for userService implementation
rg "userService\|API\.user" --type ts --type tsx -B 2 -A 2 | head -50Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 98
🏁 Script executed:
# Check the mypage layout for error handling pattern mentioned in review
find . -type f -name "*mypage*" -o -name "*layout.tsx" | grep -i mypageRepository: WeGo-Together/WeGo_FrontEnd
Length of output: 132
🏁 Script executed:
# Search for isFollow field usage in the codebase
rg "isFollow" --type ts --type tsx -B 3 -A 3Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 98
🏁 Script executed:
# Search for getUser without type restriction
rg "getUser" -A 5 -B 2 | head -60Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 2794
🏁 Script executed:
# Look for isFollow field in codebase
rg "isFollow" -A 3 -B 3 | head -80Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 4480
🏁 Script executed:
# Check user service implementation
cat src/api/service/user-service/index.tsRepository: WeGo-Together/WeGo_FrontEnd
Length of output: 2135
🏁 Script executed:
# Check mypage layout for error handling
cat src/app/\(user\)/mypage/layout.tsxRepository: WeGo-Together/WeGo_FrontEnd
Length of output: 706
🏁 Script executed:
# Check the profile layout file
cat src/app/\(user\)/profile/\[userId\]/layout.tsxRepository: WeGo-Together/WeGo_FrontEnd
Length of output: 1054
fetchQuery 호출 시 에러 처리가 필요합니다.
현재 코드에서 API.userService.getUser() 호출이 실패하면 처리되지 않은 예외가 발생합니다. API 호출 실패에 대한 에러 처리(에러 바운더리 또는 try-catch)를 추가하세요.
참고: isFollow: null이 본인 프로필을 나타내는 API 계약은 타입 정의와 모의 데이터로 확인되었으므로 현재 로직은 올바릅니다.
🤖 Prompt for AI Agents
In src/app/(user)/profile/[userId]/layout.tsx around lines 23-29, wrap the
queryClient.fetchQuery call in a try-catch and handle API failures instead of
letting exceptions escape: call fetchQuery inside try, keep the existing
isFollow===null check and redirect('/mypage') as before, and in the catch either
redirect to a safe error route (e.g. redirect('/error')) or rethrow/throw a
Next.js Response to trigger the app error boundary, while optionally logging the
caught error for diagnostics.
| isNotificationEnabled: boolean; | ||
| createdAt: string; | ||
| isFollow: boolean; | ||
| isFollow: boolean | null; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for all isFollow usage in the codebase
rg -nP --type=ts --type=tsx '\.isFollow\b' -g '!*.test.*' -g '!*.spec.*' -g '!node_modules'Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 98
🏁 Script executed:
# Check the type definition file and related files
cat -n src/types/service/user.tsRepository: WeGo-Together/WeGo_FrontEnd
Length of output: 1424
🏁 Script executed:
# Search for isFollow in condition checks to see how it's being handled
rg -nP --type=ts --type=tsx 'isFollow\s*(===|!==|==|!=|\?|!)' -g '!*.test.*' -g '!*.spec.*' -g '!node_modules'Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 98
🏁 Script executed:
# Search for isFollow usage without specifying tsx
rg -nP '\.isFollow\b' -g '!*.test.*' -g '!*.spec.*' -g '!node_modules' | head -50Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 840
🏁 Script executed:
# Search for isFollow in condition checks
rg -nP 'isFollow\s*(===|!==|==|!=|\?|!)' -g '!*.test.*' -g '!*.spec.*' -g '!node_modules'Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 616
🏁 Script executed:
# Look at profile-related files that handle isFollow
fd -e ts -e js -e jsx -e tsx 'profile' | grep -v node_modules | grep -v test | head -20Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 53
🏁 Script executed:
# Check the mock handler mentioned in learnings
cat -n src/mock/service/user/user-handler.ts | head -50Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 1748
🏁 Script executed:
# Check the profile-info component in detail to understand the logic
cat -n src/components/pages/user/profile/profile-info/index.tsx | sed -n '25,40p'Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 589
🏁 Script executed:
# Verify if there are any other isFollow usages we missed
rg 'isFollow' -g '!*.test.*' -g '!*.spec.*' -g '!node_modules' --count-matchesRepository: WeGo-Together/WeGo_FrontEnd
Length of output: 279
🏁 Script executed:
# Check the actual user mock data to see what values are set
fd 'user-mock' | xargs cat -n | head -60Repository: WeGo-Together/WeGo_FrontEnd
Length of output: 2063
프로필 정보 컴포넌트에 명시적 null 방어 로직 추가 필요
isFollow 타입 변경이 코드베이스 전체에 통합되어 있으며, mock 핸들러와 라우트 가드에서 null 값을 적절히 처리하고 있습니다. 다만 src/components/pages/user/profile/profile-info/index.tsx의 31-32번 라인에서 !user.isFollow와 user.isFollow 조건을 사용할 때 명시적인 null 체크가 없습니다.
현재는 layout.tsx의 null 체크 리다이렉트(if (user.isFollow === null) redirect('/mypage'))로 보호되고 있지만, 향후 리팩토링 시 이 가드가 제거되면 null 값이 통과되어 자신의 프로필에서도 "팔로우 하기" 버튼이 표시될 수 있습니다. 방어적 프로그래밍을 위해 profile-info 컴포넌트에도 user.isFollow !== null 체크를 추가하는 것을 권장합니다.
🤖 Prompt for AI Agents
In src/components/pages/user/profile/profile-info/index.tsx around lines 31-32,
the component uses `!user.isFollow` and `user.isFollow` without guarding against
`null`; add an explicit null check (e.g., `user.isFollow !== null && ...`) to
both conditional branches so the UI only treats boolean values and ignores
`null`, preventing the "Follow" button from appearing when `isFollow` is `null`.
| children: React.ReactNode; | ||
| } | ||
|
|
||
| export const dynamic = 'force-dynamic'; |
There was a problem hiding this comment.
Next.js는 기본적으로 빌드할 때 SSG가 되므로 prerendering을 하는데, users/me api가 기본적으로 token이 필요한 api라 빌드 시점에 렌더링이 되지 않는 문제가 있어요
그래서 이걸 추가해주면 prerendering을 하지 않게 됩니다!
단점은 SEO 적용이 어렵다는 점이 있는데, 어차피 권한이 필요한 페이지라 상관이 없어서 추가했어요 :)
📝 변경 사항
나의 프로필 페이지 접속 시 마이페이지로 리다이렉트 로직을 수정했습니다.
기존: userId 쿠키 확인 후, 현재 조회한 프로필의 userId와 동일하면 mypage로 redirect
변경: 조회한 프로필의 isFollow 필드 값이 null이면 mypage로 redirect
🔗 관련 이슈
Closes #
🧪 테스트 방법
📸 스크린샷 (선택)
📋 체크리스트
💬 추가 코멘트
CodeRabbit Review는 자동으로 실행되지 않습니다.
Review를 실행하려면 comment에 아래와 같이 작성해주세요
Summary by CodeRabbit
버그 수정
✏️ Tip: You can customize this high-level summary in your review settings.