revert: PR #83 홈 진행중인 사건 API 연동 및 UI 수정 되돌리기 - #84
Conversation
This reverts commit 89d9c6f.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthrough
Changesnickname 제거 및 active 필터 삭제
추정 코드 리뷰 노력🎯 2 (Simple) | ⏱️ ~10 minutes 연관 가능성 있는 PR
시 🐰
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
src/hooks/useActiveCases.ts (1)
23-28: 💤 Low value사용되지 않는 상수 및 타입 정의
ACTIVE_DISPUTE_STATUSES,ActiveDisputeStatus,RawCase가 정의되었지만 현재 코드에서 사용되지 않습니다. TODO 구현 전까지 불필요한 코드입니다.♻️ 사용되지 않는 코드 제거 제안
-// 진행중인 사건 = 진술 시작 후 ~ 판결 전 -// draft(진술 전), judging(판결 처리 중), judged(판결 완료) 제외 -const ACTIVE_DISPUTE_STATUSES = ['waiting_opponent', 'opponent_joined', 'both_submitted'] as const -type ActiveDisputeStatus = (typeof ACTIVE_DISPUTE_STATUSES)[number] - -type RawCase = ActiveCase & { status: ActiveDisputeStatus } -🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/hooks/useActiveCases.ts` around lines 23 - 28, The constants ACTIVE_DISPUTE_STATUSES and types ActiveDisputeStatus and RawCase are defined in the useActiveCases.ts hook but are not currently used anywhere in the code. Remove these unused definitions (the constant array, the type alias, and the RawCase type) until they are needed for future implementation, as keeping unused code adds unnecessary complexity.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/home/NewCaseButton.tsx`:
- Line 34: The setTimeout timeout of 5000ms is too short for the two sequential
API calls to room creation and dispute creation. The 5-second timeout can cause
premature request cancellation on slower networks or during server load.
Increase the timeout value from 5000 to at least 15000 milliseconds to provide
sufficient time for both the room creation and dispute creation API calls to
complete, or alternatively implement separate timeout mechanisms for each
individual API call to better handle their individual response times.
In `@src/hooks/useActiveCases.ts`:
- Around line 30-36: When implementing the commented-out `fetchActiveCases`
function, add a data transformation layer to map the flat
`DisputeParticipantDto[]` structure returned from the API into the nested
`Participant[]` structure expected by the component. The mapping must handle
converting the flat participants data (with userId, profileImageUrl, role at
root level) into the nested structure required by `Participant` (with user
object containing nickname and profileImageUrl). Since the `nickname` field is
not provided by the API response but is referenced in `ActiveCasesSection.tsx`
at line 63 via `p.user.nickname`, you need to either fetch user details
separately from a User API endpoint or adjust the API contract to include
nickname in the participant data. Create a mapping function that transforms each
`DisputeParticipantDto` into a `Participant` object with the correct nested
structure and resolved nickname data.
---
Nitpick comments:
In `@src/hooks/useActiveCases.ts`:
- Around line 23-28: The constants ACTIVE_DISPUTE_STATUSES and types
ActiveDisputeStatus and RawCase are defined in the useActiveCases.ts hook but
are not currently used anywhere in the code. Remove these unused definitions
(the constant array, the type alias, and the RawCase type) until they are needed
for future implementation, as keeping unused code adds unnecessary complexity.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 68c39c23-061c-4a2f-97b2-b7256f3913b9
📒 Files selected for processing (6)
src/app/api/disputes/[id]/route.tssrc/app/api/disputes/route.tssrc/app/page.module.scsssrc/components/home/NewCaseButton.tsxsrc/hooks/useActiveCases.tssrc/types/dispute.ts
💤 Files with no reviewable changes (2)
- src/types/dispute.ts
- src/app/api/disputes/[id]/route.ts
| const controller = new AbortController() | ||
| // 방 생성 + 사건 생성 두 번의 순차 API 호출을 커버할 수 있도록 30초로 설정 | ||
| const timeout = setTimeout(() => controller.abort(), 30000) | ||
| const timeout = setTimeout(() => controller.abort(), 5000) |
There was a problem hiding this comment.
타임아웃이 연속된 두 API 호출에 비해 지나치게 짧습니다.
5초 타임아웃은 room 생성(36-43행)과 dispute 생성(45-52행) 두 개의 순차적 API 호출을 완료하기에 너무 짧습니다. 느린 네트워크 환경, 서버 부하 상황, 또는 콜드 스타트 시 정상적인 요청도 중단될 수 있어 사용자에게 불필요한 오류 메시지가 표시됩니다.
최소 15,000ms 이상으로 늘리거나, 각 API 호출마다 개별 타임아웃을 설정하는 것을 권장합니다.
⏱️ 타임아웃 증가 제안
- const timeout = setTimeout(() => controller.abort(), 5000)
+ const timeout = setTimeout(() => controller.abort(), 15000)📝 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.
| const timeout = setTimeout(() => controller.abort(), 5000) | |
| const timeout = setTimeout(() => controller.abort(), 15000) |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/components/home/NewCaseButton.tsx` at line 34, The setTimeout timeout of
5000ms is too short for the two sequential API calls to room creation and
dispute creation. The 5-second timeout can cause premature request cancellation
on slower networks or during server load. Increase the timeout value from 5000
to at least 15000 milliseconds to provide sufficient time for both the room
creation and dispute creation API calls to complete, or alternatively implement
separate timeout mechanisms for each individual API call to better handle their
individual response times.
| // TODO: 진행중인 사건 API 연동 시 활성화 | ||
| // async function fetchActiveCases(): Promise<ActiveCase[]> { | ||
| // const res = await fetch('/api/disputes?active=true') | ||
| // if (!res.ok) throw new Error('진행중인 사건을 불러오지 못했습니다.') | ||
| // const json = await res.json() | ||
| // return json.data.disputes | ||
| // } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Participant 타입과 DisputeParticipantDto 간의 nickname 사용 현황 확인
echo "=== DisputeParticipantDto 정의 확인 ==="
rg -n "interface DisputeParticipantDto" -A 10 --type=ts
echo ""
echo "=== useActiveCases의 Participant 타입에서 nickname 사용 확인 ==="
rg -n "nickname" src/hooks/useActiveCases.ts
echo ""
echo "=== ActiveCasesSection에서 nickname 사용 확인 ==="
rg -n "nickname" src/components/home/ActiveCasesSection.tsxRepository: I5-Project/TALKY-OWL
Length of output: 781
🏁 Script executed:
#!/bin/bash
# Get complete context of useActiveCases.ts
echo "=== Complete useActiveCases.ts (lines 1-50) ==="
head -50 src/hooks/useActiveCases.ts | cat -n
echo ""
echo "=== Check if there's a transformation/mapping between types ==="
rg -n "Participant|DisputeParticipantDto" src/hooks/useActiveCases.ts -B 2 -A 2Repository: I5-Project/TALKY-OWL
Length of output: 1887
🏁 Script executed:
#!/bin/bash
# Check Dispute type definition and its relationship with participants
echo "=== Dispute type definition ==="
rg -n "export interface Dispute" src/types/dispute.ts -A 15
echo ""
echo "=== Check what fields Dispute includes ==="
rg -n "participants" src/types/dispute.ts -B 2 -A 2Repository: I5-Project/TALKY-OWL
Length of output: 1757
🏁 Script executed:
#!/bin/bash
# Check for User type and any existing mapping utilities
echo "=== Check User type definition ==="
rg -n "export interface User" src/types -A 10
echo ""
echo "=== Check for any mapper functions ==="
fd . src -name "*map*" -o -name "*transform*" -o -name "*convert*"
echo ""
echo "=== Check how userId relates to User/nickname ==="
rg -n "User.*nickname|nickname.*User" src/types --type tsRepository: I5-Project/TALKY-OWL
Length of output: 868
TODO 구현 시 타입 구조와 데이터 변환 불일치 해결 필요
주석 처리된 fetchActiveCases를 구현할 때 주의가 필요합니다. API는 DisputeParticipantDto[] 형태로 participants를 반환하지만, 현재 Participant 타입과 구조가 맞지 않습니다:
DisputeParticipantDto: 평탄한 구조 (userId, profileImageUrl, role 등)Participant: 중첩된 구조 (user: { nickname, profileImageUrl }, role)
특히 nickname 필드는 DisputeParticipantDto에 없으며, ActiveCasesSection.tsx(line 63)에서 p.user.nickname을 참조하고 있어 런타임 오류가 발생합니다. API 응답을 Participant 타입으로 변환하는 매핑 로직이 필요하며, nickname 데이터를 어디서 가져올지 결정해야 합니다 (User API 별도 조회 또는 API 응답 구조 변경).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/hooks/useActiveCases.ts` around lines 30 - 36, When implementing the
commented-out `fetchActiveCases` function, add a data transformation layer to
map the flat `DisputeParticipantDto[]` structure returned from the API into the
nested `Participant[]` structure expected by the component. The mapping must
handle converting the flat participants data (with userId, profileImageUrl, role
at root level) into the nested structure required by `Participant` (with user
object containing nickname and profileImageUrl). Since the `nickname` field is
not provided by the API response but is referenced in `ActiveCasesSection.tsx`
at line 63 via `p.user.nickname`, you need to either fetch user details
separately from a User API endpoint or adjust the API contract to include
nickname in the participant data. Create a mapping function that transforms each
`DisputeParticipantDto` into a `Participant` object with the correct nested
structure and resolved nickname data.
팀장 승인 없이 dev에 머지된 PR #83을 되돌립니다.
Summary by CodeRabbit
릴리스 노트
버그 수정
기능 변경
스타일