feat: Add bounty management navigation and CTA components#654
Conversation
|
@BWM0223 is attempting to deploy a commit to the Threadflow Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughAdds a client-side bounty management navigation component with typed props, active-route highlighting, conditional disabled states and badges, plus a direct manage-bounty CTA link. ChangesBounty management navigation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed due to a network error. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
components/bounty/BountyManageNav.tsx (1)
91-137: 🎯 Functional Correctness | 🔵 TrivialSwitch to prefix matching for active state detection
The route tree verification confirms that while no nested sub-pages currently exist under
/me/bounties/[id]/manage, theBountyManageNavcomponent is explicitly structured to render tabs forconfigure,applications, and other sub-routes.Once these nested pages are implemented, the strict
pathname === item.hrefcheck will fail to highlight the correct parent tab. Switch topathname.startsWith(item.href)to ensure the active state persists for any child route.🤖 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 `@components/bounty/BountyManageNav.tsx` around lines 91 - 137, In BountyManageNav, the active tab logic is too strict because `pathname === item.href` only matches the exact route and will stop highlighting parent tabs for nested sub-routes like configure or applications. Update the `isActive` check in the `navItems.map` render path to use prefix matching against `pathname` so the correct tab stays active for child routes, while keeping the existing `item.href`-based Link rendering and styling logic intact.
🤖 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 `@components/bounty/BountyManageNav.tsx`:
- Around line 17-22: The BountyManageNavProps.bountyStatus field is duplicating
the bounty lifecycle literals instead of using the shared canonical Bounty
status type. Update BountyManageNav to import and use the backend-shared bounty
status type from the existing shared definitions (for example, a types/bounty.ts
export or the relevant API-shared type) so the nav stays aligned with the source
of truth. If no shared Bounty type exists yet, extract the status union into a
central shared type and reference that from BountyManageNavProps.
---
Nitpick comments:
In `@components/bounty/BountyManageNav.tsx`:
- Around line 91-137: In BountyManageNav, the active tab logic is too strict
because `pathname === item.href` only matches the exact route and will stop
highlighting parent tabs for nested sub-routes like configure or applications.
Update the `isActive` check in the `navItems.map` render path to use prefix
matching against `pathname` so the correct tab stays active for child routes,
while keeping the existing `item.href`-based Link rendering and styling logic
intact.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0ef7291d-a635-4d47-852d-5f323813c4ff
📒 Files selected for processing (1)
components/bounty/BountyManageNav.tsx
| interface BountyManageNavProps { | ||
| bountyId: string; | ||
| bountyStatus: "draft" | "active" | "submissions" | "judging" | "payout" | "completed" | "cancelled"; | ||
| hasDisputes?: boolean; | ||
| pendingPayouts?: number; | ||
| } |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Read-only check for a shared bounty status enum/type.
rg -n --glob '*.{ts,tsx,js,jsx}' '\b(BountyStatus|bountyStatus)\b|draft|active|submissions|judging|payout|completed|cancelled' .Repository: boundlessfi/boundless
Length of output: 50378
Verify this status list matches the shared bounty lifecycle.
The BountyManageNav component hardcodes the bountyStatus type with a specific set of literals. While the codebase contains a types/hackathon/core.ts file with a status type that is similar, it currently appears scoped to Hackathons and includes 'published' while the nav component uses 'draft' in a slightly different structure.
To prevent subtle mismatches where a Bounty type is introduced or modified independently later, please import the canonical Bounty status type directly from the backend-shared type definitions (e.g., pages/api/... or types/bounty.ts if it exists) rather than maintaining a parallel list. If a unified canonical type does not exist yet, it would be safer to centralize these statuses to avoid drift as the dashboard grows.
Currently, the mapping appears to match common expectations, but hardcoding in the component creates a maintenance risk.
🤖 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 `@components/bounty/BountyManageNav.tsx` around lines 17 - 22, The
BountyManageNavProps.bountyStatus field is duplicating the bounty lifecycle
literals instead of using the shared canonical Bounty status type. Update
BountyManageNav to import and use the backend-shared bounty status type from the
existing shared definitions (for example, a types/bounty.ts export or the
relevant API-shared type) so the nav stays aligned with the source of truth. If
no shared Bounty type exists yet, extract the status union into a central shared
type and reference that from BountyManageNavProps.
Source: Coding guidelines
1 participant
Summary
Partial implementation for Issue #637
Changes
Summary by CodeRabbit
New Features
Bug Fixes