Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughReads and persists inviteCode via cookies across setup/invite flows, uses combined inviteCode to drive initial setup and registration logic, consolidates invitation tooltip rendering, removes the InviterHeartIcon and its Icon mapping, and refreshes user data on Points page mount. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/hooks/useZeroDev.ts (1)
59-76: Critical: Wrong variable used in API call breaks cookie-based invite acceptance.Line 66 uses
inviteCode(from Redux store only) instead ofuserInviteCode(which combines both Redux and cookie values). This means when an invite code exists only in cookies (not in Redux), the API call will receive an empty or undefined value, causing the invite acceptance to fail silently.This breaks the entire cookie-based invite flow that this PR is trying to establish, particularly for PWA scenarios where Redux state may not persist but cookies do.
Apply this diff to fix the issue:
- const result = await invitesApi.acceptInvite(inviteCode, inviteType) + const result = await invitesApi.acceptInvite(userInviteCode, inviteType)Also, minor typo in the comment on line 61: "store" should be "stored".
- // invite code can also be store in cookies, so we need to check both + // invite code can also be stored in cookies, so we need to check both
🧹 Nitpick comments (1)
src/app/(setup)/setup/page.tsx (1)
115-121: LGTM! Cookie-based invite code reading enables persistence across sessions.The pattern of reading from both Redux store and cookies, then using the logical OR, is correct. This ensures invite codes persist even if Redux state is cleared, which is essential for PWA scenarios.
Minor typo in the comment on line 117: "store" should be "stored".
Apply this diff to fix the typo:
- // invite code can also be store in cookies, so we need to check both + // invite code can also be stored in cookies, so we need to check both
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
src/app/(setup)/setup/page.tsx(2 hunks)src/components/Global/Icons/Icon.tsx(0 hunks)src/components/Global/Icons/inviter-heart.tsx(0 hunks)src/components/Invites/InvitesPage.tsx(3 hunks)src/components/Invites/JoinWaitlistPage.tsx(1 hunks)src/components/UserHeader/index.tsx(1 hunks)src/hooks/useZeroDev.ts(2 hunks)
💤 Files with no reviewable changes (2)
- src/components/Global/Icons/Icon.tsx
- src/components/Global/Icons/inviter-heart.tsx
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-08T17:13:13.140Z
Learnt from: Zishan-7
PR: peanutprotocol/peanut-ui#1299
File: src/app/(mobile-ui)/points/page.tsx:41-51
Timestamp: 2025-10-08T17:13:13.140Z
Learning: In `src/app/(mobile-ui)/points/page.tsx`, the icon name "invite-heart" is intentionally used (not "inviter-heart") when displaying who invited the current user, as this is a deliberate design choice despite semantic differences with UserHeader usage.
Applied to files:
src/components/UserHeader/index.tsx
📚 Learning: 2025-09-29T18:34:33.596Z
Learnt from: Zishan-7
PR: peanutprotocol/peanut-ui#1251
File: src/components/Invites/JoinWaitlistPage.tsx:41-55
Timestamp: 2025-09-29T18:34:33.596Z
Learning: In the JoinWaitlistPage component, after successfully accepting an invite via invitesApi.acceptInvite(), calling fetchUser() is sufficient to update the user state and automatically display the app. No manual navigation to /home or other pages is required since the user is already on the home page and the app will be displayed once user.hasAppAccess is updated.
Applied to files:
src/components/Invites/JoinWaitlistPage.tsx
🧬 Code graph analysis (5)
src/components/UserHeader/index.tsx (1)
src/components/Tooltip/index.tsx (1)
Tooltip(18-106)
src/components/Invites/JoinWaitlistPage.tsx (1)
src/redux/hooks.ts (1)
useSetupStore(9-9)
src/app/(setup)/setup/page.tsx (1)
src/utils/general.utils.ts (1)
getFromCookie(160-186)
src/hooks/useZeroDev.ts (2)
src/utils/general.utils.ts (2)
getFromCookie(160-186)removeFromCookie(188-198)src/services/invites.ts (1)
invitesApi(7-83)
src/components/Invites/InvitesPage.tsx (2)
src/context/authContext.tsx (1)
useAuth(191-197)src/utils/general.utils.ts (1)
saveToCookie(136-158)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Deploy-Preview
🔇 Additional comments (4)
src/components/Invites/JoinWaitlistPage.tsx (1)
25-26: LGTM! Invite code now pre-populated from setup store.This change ensures that if an invite code exists in the setup store (which can be sourced from cookies), it will be pre-filled in the input field. This improves the user experience by avoiding manual re-entry.
src/components/UserHeader/index.tsx (1)
98-106: Good refactor consolidating duplicate tooltip logic.The consolidated conditional reduces code duplication while maintaining the same functionality. The dynamic
idandcontentbased on which condition is true is a clean approach.Note: In the rare edge case where both
isInviterandisInvitedByLoggedInUserare true (mutual invitation), only the inviter tooltip will be displayed due to the ternary operator. This is likely acceptable given the rarity of this scenario.src/components/Invites/InvitesPage.tsx (2)
40-40: LGTM! Cookie persistence ensures invite codes survive PWA installations.Saving the invite code to cookies before navigation is a good practice, as mentioned in the comment. This ensures the invite code persists even if the user installs the PWA, where Redux state might not carry over.
45-51: Good defensive logic in logout handler.The conditional check for
userexistence prevents attempting to logout when there's no authenticated user, gracefully redirecting to setup instead. This handles edge cases where a user might land on this page without being logged in.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/app/(mobile-ui)/points/page.tsx(2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-08T17:13:13.140Z
Learnt from: Zishan-7
PR: peanutprotocol/peanut-ui#1299
File: src/app/(mobile-ui)/points/page.tsx:41-51
Timestamp: 2025-10-08T17:13:13.140Z
Learning: In `src/app/(mobile-ui)/points/page.tsx`, the icon name "invite-heart" is intentionally used (not "inviter-heart") when displaying who invited the current user, as this is a deliberate design choice despite semantic differences with UserHeader usage.
Applied to files:
src/app/(mobile-ui)/points/page.tsx
📚 Learning: 2025-09-29T18:34:33.596Z
Learnt from: Zishan-7
PR: peanutprotocol/peanut-ui#1251
File: src/components/Invites/JoinWaitlistPage.tsx:41-55
Timestamp: 2025-09-29T18:34:33.596Z
Learning: In the JoinWaitlistPage component, after successfully accepting an invite via invitesApi.acceptInvite(), calling fetchUser() is sufficient to update the user state and automatically display the app. No manual navigation to /home or other pages is required since the user is already on the home page and the app will be displayed once user.hasAppAccess is updated.
Applied to files:
src/app/(mobile-ui)/points/page.tsx
🧬 Code graph analysis (1)
src/app/(mobile-ui)/points/page.tsx (1)
src/context/authContext.tsx (1)
useAuth(191-197)
🪛 Biome (2.1.2)
src/app/(mobile-ui)/points/page.tsx
[error] 37-37: This hook is being called conditionally, but all hooks must be called in the exact same order in every component render.
Hooks should not be called after an early return.
For React to preserve state between calls, hooks needs to be called unconditionally and always in the same order.
See https://reactjs.org/docs/hooks-rules.html#only-call-hooks-at-the-top-level
(lint/correctness/useHookAtTopLevel)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Deploy-Preview
🔇 Additional comments (2)
src/app/(mobile-ui)/points/page.tsx (2)
18-18: LGTM!The import of
useEffectis correctly added to support the new effect below.
22-22: fetchUser is correctly exposed by useAuth and included in AuthContextType
AuthContextType defines fetchUser and useAuth returns it via AuthContext.Provider.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/app/(mobile-ui)/points/page.tsx (1)
33-36: Hook ordering issue resolved; addfetchUserto dependency array.The critical hook ordering violation from the previous review has been fixed—the
useEffectis now correctly positioned before the early return, satisfying the Rules of Hooks.However,
fetchUsershould be included in the dependency array to satisfy theexhaustive-depslinting rule and follow React best practices. IffetchUseris guaranteed to be stable (e.g., wrapped inuseCallbackin the auth context), this is less critical, but including it improves clarity and prevents potential linting warnings.Apply this diff to add
fetchUserto the dependency array:useEffect(() => { // Re-fetch user to get the latest invitees list for showing heart Icon fetchUser() - }, []) + }, [fetchUser])
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/app/(mobile-ui)/points/page.tsx(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-29T18:34:33.596Z
Learnt from: Zishan-7
PR: peanutprotocol/peanut-ui#1251
File: src/components/Invites/JoinWaitlistPage.tsx:41-55
Timestamp: 2025-09-29T18:34:33.596Z
Learning: In the JoinWaitlistPage component, after successfully accepting an invite via invitesApi.acceptInvite(), calling fetchUser() is sufficient to update the user state and automatically display the app. No manual navigation to /home or other pages is required since the user is already on the home page and the app will be displayed once user.hasAppAccess is updated.
Applied to files:
src/app/(mobile-ui)/points/page.tsx
🧬 Code graph analysis (1)
src/app/(mobile-ui)/points/page.tsx (1)
src/context/authContext.tsx (1)
useAuth(191-197)
Hugo0
left a comment
There was a problem hiding this comment.
approved, pending iOS confirmation
No description provided.