[FE] 학생 반응하기 요청하기 로컬 스토리지 저장 기능 구현 #215
Conversation
- useBlockTimer에서 로컬값 가져와서 비교하도록 구현
- 각각의 return 마다 type 명시
WalkthroughThis pull request revises the Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant C as Card Component
participant BT as useBlockTimer Hook
participant LS as localStorage
U->>C: Click on card
C->>BT: Call startBlock()
BT->>LS: Retrieve initialCountdown using type key
BT->>BT: Initialize countdown and isBlocked state
BT->>C: Update component state (isBlocked, countdown)
C->>C: Handle UI feedback based on blocked state
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
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: 0
🧹 Nitpick comments (8)
front-end/src/hooks/useBlockTimer.ts (2)
13-13: Check for multiple effect triggers and transitions
Because the effect at lines 16-26 re-invokesstartCountdownifinitialCountdown > 0, any changes totype,blockDuration, ordelaymight reset the countdown unexpectedly mid-block. Ensure that this is intentional, or consider memoizing these props to avoid unintended resets.Also applies to: 15-20, 26-26, 28-51
63-63: Optionally expose a cancel or reset method
Returning{ isBlocked, countdown, startBlock }is sufficient for most use cases. However, if you foresee the need to cancel an ongoing block or reset the countdown, returning additional functions (e.g.,cancelBlock) could improve reusability.front-end/src/pages/student/course/react/components/ReactCard.tsx (3)
1-1: Use consistent naming for reaction-based properties
Importing theReactiontype and adding the newtypeprop is clear. Just ensure future expansions stay consistent, e.g., usereactionTypeor another descriptive name if you add multiple similar props.Also applies to: 4-4, 9-9
12-16: Encapsulate block duration constants
You're passing10000(block duration) and2000(delay) directly to the hook. Consider extracting these into a config or constant for better maintainability and clarity.
20-26: Consolidate state if feasible
You mapisBlockedtoisSelectedinside a side effect. If your UI fully depends onisBlocked, you might simplify by relying solely onisBlockedinstead of duplicating withisSelected. Keeping two states in sync can lead to confusion unless it’s truly necessary.front-end/src/pages/student/course/request/components/RequestCard.tsx (2)
1-1: Adopt consistent naming & typing
IntroducingRequestTypein the props aligns with the approach for reactions. Ensure that thetypestrings for requests and reactions remain distinct if they share localStorage keys, to avoid collisions.Also applies to: 4-4, 11-11, 19-19
28-34: Mirror isBlocked into isSelected
As withReactCard, you’re togglingisSelectedwhenisBlockedchanges. Consider whether the UI needs both states, or if referencingisBlockedalone is sufficient.front-end/src/repository/classroomRepository.ts (1)
108-108: Translate Korean comment to maintain consistency.The comment "오류 처리" (error handling) should be in English to maintain consistency with the rest of the codebase.
- await throwError(response); // 오류 처리 + await throwError(response); // Error handling
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
front-end/src/hooks/useBlockTimer.ts(1 hunks)front-end/src/pages/student/course/react/StudentReact.tsx(1 hunks)front-end/src/pages/student/course/react/components/ReactCard.tsx(1 hunks)front-end/src/pages/student/course/request/StudentRequest.tsx(1 hunks)front-end/src/pages/student/course/request/components/RequestCard.tsx(1 hunks)front-end/src/repository/classroomRepository.ts(2 hunks)
🔇 Additional comments (10)
front-end/src/hooks/useBlockTimer.ts (2)
3-10: Leverage fallback for missing or invalid keys in localStorage
The approach of retrieving and parsing the stored countdown from localStorage is a good way to persist the block state. However, consider additional safeguards iftypecould be null/undefined or if localStorage returns invalid data (e.g., non-numeric strings).
53-61: Clarify partial second rounding
When callingstartCountdown(blockDuration / 1000), fractional remainders are truncated. IfblockDurationis not always a clean multiple of 1000, consider rounding or adjusting the value to ensure more consistent block durations.front-end/src/pages/student/course/react/components/ReactCard.tsx (2)
32-32: Trigger block only on success
CallingstartBlock()immediately aftersetIsSelected(true)ensures the countdown runs exclusively for successful clicks. This is great for preventing user spamming. No concerns here.
38-39: Confirm button disabling logic
The button is disabled based on eitherisSelectedorisBlocked. This ensures no repeated interactions. If the user flow changes so thatisSelectedcan be reset, consider reevaluating whether users should be allowed multiple clicks within the block timeframe.front-end/src/pages/student/course/request/components/RequestCard.tsx (2)
22-23: Match units for block duration
You’re calling the hook with60000for the block duration (in milliseconds) and dividing by 1000 inside the hook. Double-check that you’re aware of the difference between the internal “seconds” usage (countdown) and the external “milliseconds” usage.
40-40: Good practice to block on success
CallingstartBlock()after confirming success is an effective way to prevent spammy requests. This logic is consistent with the approach inReactCard.front-end/src/pages/student/course/react/StudentReact.tsx (1)
66-66: LGTM! Type prop addition aligns with local storage implementation.The addition of the
typeprop toReactCardenables type-based localStorage persistence for reaction timers.front-end/src/pages/student/course/request/StudentRequest.tsx (1)
84-84: LGTM! Type prop addition enables request-specific timer persistence.The addition of the
typeprop toRequestCardenables localStorage persistence for request timers, consistent with the implementation inReactCard.front-end/src/repository/classroomRepository.ts (2)
68-72: LGTM! Streamlined question data structure.The return value has been optimized to include only the necessary fields (
id,createdAt,content), improving type safety and reducing data transfer.
111-118: LGTM! Consistent data transformation.The mapping of question data follows the same streamlined structure as
sendQuestion, ensuring consistency across the repository.
#️⃣ 연관된 이슈
📝 작업 내용
학생 반응하기 요청하기 로컬 스토리지 저장 기능 구현
학생이 요청과 반응에는 한번씩 누르게 되면 서버의 부하를 생각하여 60초.10초 동안 못하도록 막았습니다.
하지만 각각의 초 단위를 서버에서 받아오는것이 아니기 때문에 새로 고침을 하게 되면 초기화가 되는 문제가 생겨서
로컬스토리지에 저장하여 사용하도록 구현 했습니다!
Summary by CodeRabbit