feat: change review badges to dropdowns on sponsor dashboard sidebar …#1425
feat: change review badges to dropdowns on sponsor dashboard sidebar …#1425espadondutravail wants to merge 1 commit into
Conversation
|
@espadondutravail is attempting to deploy a commit to the Superteam Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughBoth ChangesInline SelectLabel in Submission and Grant Application List Rows
pnpm Workspace Build Config
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 Warning |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
src/features/sponsor-dashboard/components/Submissions/SelectLabel.tsx (1)
24-24: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse explicit
| undefinedfor this prop.
submission?: SubmissionWithUserbreaks the repo’s TS prop contract. Prefersubmission: SubmissionWithUser | undefinedhere.
As per coding guidelines, useproperty: Type | undefinedinstead ofproperty?: Typefor TypeScript type definitions.🤖 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/features/sponsor-dashboard/components/Submissions/SelectLabel.tsx` at line 24, The SelectLabel prop type uses optional property syntax for submission, which breaks the repo’s TypeScript contract. Update the SelectLabel component’s props definition to use submission: SubmissionWithUser | undefined instead of submission?: SubmissionWithUser, and keep the rest of the component signatures consistent with this explicit undefined pattern.Source: Coding guidelines
src/features/sponsor-dashboard/components/GrantApplications/SelectLabel.tsx (1)
25-25: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse explicit
| undefinedfor this prop.
application?: GrantApplicationWithUsershould follow the repo’s explicit prop typing pattern instead of the optional form.
As per coding guidelines, useproperty: Type | undefinedinstead ofproperty?: Typefor TypeScript type definitions.🤖 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/features/sponsor-dashboard/components/GrantApplications/SelectLabel.tsx` at line 25, Update the SelectLabel component’s prop typing to follow the repo convention by replacing the optional application prop syntax with an explicit union including undefined. Locate the SelectLabel props/type definition and change the application field from optional form to an explicit GrantApplicationWithUser | undefined declaration, keeping the rest of the component unchanged.Source: Coding guidelines
src/features/sponsor-dashboard/components/Submissions/SubmissionList.tsx (1)
42-42: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse explicit
| undefinedforisHackathonPage.
isHackathonPage?: booleanis the optional-prop form the repo asks us to avoid. PreferisHackathonPage: boolean | undefined.
As per coding guidelines, useproperty: Type | undefinedinstead ofproperty?: Typefor TypeScript type definitions.🤖 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/features/sponsor-dashboard/components/Submissions/SubmissionList.tsx` at line 42, The `SubmissionList` type definition uses the optional-prop form for `isHackathonPage`, which should be expressed explicitly as `boolean | undefined` instead. Update the prop declaration in `SubmissionList.tsx` to use `isHackathonPage: boolean | undefined` so it matches the repo’s TypeScript guideline and keeps the `SubmissionList` interface consistent with the rest of the codebase.Source: Coding guidelines
src/features/sponsor-dashboard/components/GrantApplications/ApplicationList.tsx (1)
38-38: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse explicit
| undefinedforgrantSlug.
grantSlug?: stringshould be written asgrantSlug: string | undefinedto match the repo’s TS typing rule.
As per coding guidelines, useproperty: Type | undefinedinstead ofproperty?: Typefor TypeScript type definitions.🤖 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/features/sponsor-dashboard/components/GrantApplications/ApplicationList.tsx` at line 38, Update the TypeScript type definition for the ApplicationList props so grantSlug uses the repo’s required explicit undefined form instead of optional property syntax. In the ApplicationList component type/interface, change the grantSlug field from optional shorthand to a required property typed as string | undefined, and keep any references to grantSlug consistent with that signature.Source: Coding guidelines
🤖 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 `@pnpm-workspace.yaml`:
- Around line 1-11: The allowBuilds entries still use pnpm-generated
placeholders, so update the pnpm-workspace.yaml allowBuilds block to explicit
boolean values for each listed package. Replace each placeholder in the
allowBuilds section with either true or false so pnpm treats the packages as
approved or blocked during install. Use the allowBuilds key and the package
names shown there to locate and finish the unresolved entries.
In `@src/features/sponsor-dashboard/components/GrantApplications/SelectLabel.tsx`:
- Around line 37-38: The row is reading a stale application because
SelectLabel.targetApplication always prefers propApplication while the label
mutation only updates React Query and selectedGrantApplicationAtom. Update the
same backing data used by ApplicationList/ApplicationsTab (applicationsAtom) or
stop preferring the stale prop object in SelectLabel so the dropdown, sidebar,
and detail state stay in sync after a label change. Make sure the update path
covers the relevant label mutation handlers and any derived application
selection logic in SelectLabel.
---
Nitpick comments:
In
`@src/features/sponsor-dashboard/components/GrantApplications/ApplicationList.tsx`:
- Line 38: Update the TypeScript type definition for the ApplicationList props
so grantSlug uses the repo’s required explicit undefined form instead of
optional property syntax. In the ApplicationList component type/interface,
change the grantSlug field from optional shorthand to a required property typed
as string | undefined, and keep any references to grantSlug consistent with that
signature.
In `@src/features/sponsor-dashboard/components/GrantApplications/SelectLabel.tsx`:
- Line 25: Update the SelectLabel component’s prop typing to follow the repo
convention by replacing the optional application prop syntax with an explicit
union including undefined. Locate the SelectLabel props/type definition and
change the application field from optional form to an explicit
GrantApplicationWithUser | undefined declaration, keeping the rest of the
component unchanged.
In `@src/features/sponsor-dashboard/components/Submissions/SelectLabel.tsx`:
- Line 24: The SelectLabel prop type uses optional property syntax for
submission, which breaks the repo’s TypeScript contract. Update the SelectLabel
component’s props definition to use submission: SubmissionWithUser | undefined
instead of submission?: SubmissionWithUser, and keep the rest of the component
signatures consistent with this explicit undefined pattern.
In `@src/features/sponsor-dashboard/components/Submissions/SubmissionList.tsx`:
- Line 42: The `SubmissionList` type definition uses the optional-prop form for
`isHackathonPage`, which should be expressed explicitly as `boolean | undefined`
instead. Update the prop declaration in `SubmissionList.tsx` to use
`isHackathonPage: boolean | undefined` so it matches the repo’s TypeScript
guideline and keeps the `SubmissionList` interface consistent with the rest of
the codebase.
🪄 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: fc44a232-bc94-4053-a5d2-f828885015da
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (6)
pnpm-workspace.yamlsrc/features/sponsor-dashboard/components/ApplicationsTab.tsxsrc/features/sponsor-dashboard/components/GrantApplications/ApplicationList.tsxsrc/features/sponsor-dashboard/components/GrantApplications/SelectLabel.tsxsrc/features/sponsor-dashboard/components/Submissions/SelectLabel.tsxsrc/features/sponsor-dashboard/components/Submissions/SubmissionList.tsx
| allowBuilds: | ||
| '@prisma/engines': set this to true or false | ||
| '@reown/appkit': set this to true or false | ||
| bufferutil: set this to true or false | ||
| core-js: set this to true or false | ||
| keccak: set this to true or false | ||
| msgpackr-extract: set this to true or false | ||
| prisma: set this to true or false | ||
| protobufjs: set this to true or false | ||
| sharp: set this to true or false | ||
| utf-8-validate: set this to true or false |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
What value types does pnpm accept for allowBuildsinpnpm-workspace.yaml, and are string placeholders like "set this to true or false" valid?
💡 Result:
In the pnpm-workspace.yaml file, the allowBuilds setting accepts a mapping where keys are package matchers and values are booleans (true to allow, false to disallow) [1][2][3]. Regarding string placeholders like "set this to true or false": Yes, these are valid entries in the context of the file itself [4], but they function as placeholders that pnpm auto-populates when it encounters packages with build scripts that are not yet explicitly defined in allowBuilds [1][5][4]. When pnpm encounters such a package during installation, it adds an entry to your pnpm-workspace.yaml with a placeholder value (e.g., 'set this to true or false') so that you can manually edit it to true or false [1][5][4]. These placeholders behave identically to a missing entry: the package's build scripts will remain disallowed, and pnpm will continue to follow your strictDepBuilds setting (failing with an error if true, or printing a warning if false) until you replace the placeholder with an explicit boolean value [1][5][4]. While internal logic (such as in the createAllowBuildFunction) primarily processes the explicit true and false boolean values [6], these placeholder strings are an intended feature to assist users in managing workspace dependencies [4].
Citations:
- 1: https://pnpm.io/settings
- 2: https://pnpm.io/10.x/settings
- 3: pnpm/pnpm@cb367b9
- 4: feat(approve-builds): positional args, !pkg deny syntax, and auto-populate allowBuilds pnpm/pnpm#11030
- 5: https://pnpm.io/next/settings
- 6: https://github.com/pnpm/pnpm/blob/e1e29c15/building/policy/src/index.ts
Replace the pnpm-generated placeholders with explicit booleans.
These entries are valid placeholder values, but allowBuilds is still unresolved until each package is set to true or false, so pnpm will keep treating them as unapproved during install.
🤖 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 `@pnpm-workspace.yaml` around lines 1 - 11, The allowBuilds entries still use
pnpm-generated placeholders, so update the pnpm-workspace.yaml allowBuilds block
to explicit boolean values for each listed package. Replace each placeholder in
the allowBuilds section with either true or false so pnpm treats the packages as
approved or blocked during install. Use the allowBuilds key and the package
names shown there to locate and finish the unresolved entries.
| const targetApplication = propApplication || selectedApplicationAtomValue; | ||
|
|
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
This row will keep reading a stale application after label changes.
targetApplication always prefers propApplication, but the mutation only updates React Query and selectedGrantApplicationAtom. ApplicationList rows are rendered from ApplicationsTab’s applications array derived from applicationsAtom, so the inline dropdown keeps showing the old label until that separate store is refreshed. Update the same backing collection used by ApplicationList (or stop preferring the stale prop object) so sidebar and detail state stay in sync.
Also applies to: 61-108, 111-170
🤖 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/features/sponsor-dashboard/components/GrantApplications/SelectLabel.tsx`
around lines 37 - 38, The row is reading a stale application because
SelectLabel.targetApplication always prefers propApplication while the label
mutation only updates React Query and selectedGrantApplicationAtom. Update the
same backing data used by ApplicationList/ApplicationsTab (applicationsAtom) or
stop preferring the stale prop object in SelectLabel so the dropdown, sidebar,
and detail state stay in sync after a label change. Make sure the update path
covers the relevant label mutation handlers and any derived application
selection logic in SelectLabel.
|
Can you remove the pnpm files committed in this PR? |
RevTpark
left a comment
RevTpark
left a comment
There was a problem hiding this comment.
Can you remove the pnpm files, everything else is good
2 participants
feat: modify review badges to dropdown input in the submission sidebar (fixes #1420)
What does this PR do?
This PR updates the submission sidebar in the Sponsor Dashboard. The static review badges ("Unreviewed", "Shortlisted", etc.) have been replaced with a Dropdown input similar to the one found in the main submission details panel. Sponsors can now click the badge directly from the sidebar to change the review label. The click propagation is handled correctly so that interacting with the dropdown does not inadvertently open or close the submission details.
Where should the reviewer start?
The reviewer should start by looking at
src/features/sponsor-dashboard/components/Submissions/SelectLabel.tsxwhere theDropdownMenuwas integrated to replace the static pill. Next, seesrc/features/sponsor-dashboard/components/Submissions/SubmissionList.tsxfor how the new interactive label is conditionally rendered (hidden for hackathons/spams/winners).How should this be manually tested?
Any background context you want to provide?
This change improves the sponsor's UX by allowing quick triage directly from the sidebar list, removing the need to open every single submission just to change its status.
What are the relevant issues?
Fixes #1420
Screenshots (if appropriate)
(Feel free to add a quick screenshot or GIF showing the working dropdown in the sidebar here).
Summary by CodeRabbit
New Features
Bug Fixes
Chores