User profile page adding Causes tab #5152
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis change introduces new localization labels for causes and projects, updates GraphQL queries to include project type, and adjusts UI components to differentiate between causes and projects. It adds a "My Causes" menu item, refines tab and dropdown logic, and updates routing and displ 8000 ay logic to support distinct handling of causes alongside projects. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI
participant GraphQL API
User->>UI: Open Profile or Menu
UI->>UI: Determine if viewing Causes or Projects
UI->>GraphQL API: Fetch data (including projectType)
GraphQL API-->>UI: Return projects/causes with projectType
UI->>UI: Render menu/tab/routes based on type
UI->>User: Display "My Causes" or "My Projects" with correct links and labels
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (3)
lang/en.json (2)
832-832: Align key naming with existing pattern
"label.project_listed_on_public_site"mixes “project” directly into the key instead of following the existinglabel.project.*dot-notation (e.g.label.project.status). For consistency, consider:-"label.project_listed_on_public_site": "Listed on public site", +"label.project.listed_publicly": "Listed publicly",…and update the consuming components accordingly.
1945-1949: Remember to propagate new keys to other locale filesThe five newly-added Cause keys (
your_cause_has_been_published,my_causes,listed_publicly,view_cause,total_distributed) are currently English-only.
Add stubs to the other locale JSONs (lang/es.json,lang/de.json, etc.) to prevent runtime fallbacks or missing-string warnings.src/components/views/userProfile/projectsTab/ProjectActions.tsx (1)
141-159: Verify array splice indices for option insertionThe code uses hardcoded splice indices to insert options. This approach could be brittle if the base options array structure changes.
Consider using a more robust approach like:
-if (!isCause) { - options.splice(1, 0, { - label: formatMessage({ id: 'label.add_update' }), - icon: <IconUpdate16 />, - cb: () => - router.push(slugToProjectView(project.slug) + '?tab=updates'), - }); - - options.splice(3, 0, { - label: capitalizeAllWords( - formatMessage({ id: 'label.manage_addresses' }), - ), - icon: <IconWalletOutline16 />, - cb: () => { - setSelectedProject(project); - setShowAddressModal(true); - }, - }); -} +// Insert after edit option +if (!isCause) { + const editIndex = options.findIndex(opt => opt.icon?.type === IconEdit16); + options.splice(editIndex + 1, 0, { + label: formatMessage({ id: 'label.add_update' }), + icon: <IconUpdate16 />, + cb: () => + router.push(slugToProjectView(project.slug) + '?tab=updates'), + }); + + // Insert after activate/deactivate option + const activateIndex = options.findIndex(opt => opt.icon?.type === IconArchiving); + options.splice(activateIndex + 1, 0, { + label: capitalizeAllWords( + formatMessage({ id: 'label.manage_addresses' }), + ), + icon: <IconWalletOutline16 />, + cb: () => { + setSelectedProject(project); + setShowAddressModal(true); + }, + }); +}Or alternatively, build the options array conditionally from the start.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
lang/en.json(3 hunks)src/apollo/gql/gqlPowerBoosting.ts(1 hunks)src/components/menu/UserItems.tsx(1 hunks)src/components/views/userProfile/ProfileContributes.tsx(1 hunks)src/components/views/userProfile/boostedTab/BoostsTable.tsx(2 hunks)src/components/views/userProfile/causesTab/ProfileCausesTab.tsx(1 hunks)src/components/views/userProfile/projectsTab/ProjectActions.tsx(7 hunks)src/components/views/userProfile/projectsTab/ProjectItem.tsx(7 hunks)src/lib/constants/Routes.ts(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (4)
src/components/views/userProfile/causesTab/ProfileCausesTab.tsx (1)
src/components/views/userProfile/projectsTab/constants.ts (1)
projectsOrder(6-9)
src/components/views/userProfile/boostedTab/BoostsTable.tsx (1)
src/lib/routeCreators.ts (2)
slugToCauseView(42-42)slugToProjectView(3-5)
src/components/views/userProfile/projectsTab/ProjectItem.tsx (1)
src/helpers/number.ts (1)
formatDonation(53-75)
src/components/views/userProfile/projectsTab/ProjectActions.tsx (2)
src/lib/routeCreators.ts (4)
slugToCauseView(42-42)slugToProjectView(3-5)idToCauseEdit(27-29)idToProjectEdit(23-25)src/lib/helpers.ts (1)
capitalizeAllWords(331-333)
⏰ 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: build
🔇 Additional comments (21)
src/lib/constants/Routes.ts (2)
14-14: LGTM: Consistent with existing tab patternsThe new causes tab follows the same naming convention and structure as existing profile tabs.
74-74: LGTM: Route construction follows established patternThe MyCauses route is constructed consistently with other profile routes like MyProjects and MyDonations.
src/components/menu/UserItems.tsx (1)
151-155: LGTM: Menu item follows established patternThe new "My Causes" menu item is properly structured with the correct properties and logical placement in the menu array.
src/components/views/userProfile/causesTab/ProfileCausesTab.tsx (1)
29-29: LGTM: Query key change ensures proper data isolationChanging the query key from 'dashboard-projects' to 'dashboard-causes' is appropriate for the causes tab and prevents cache conflicts between projects and causes data.
src/apollo/gql/gqlPowerBoosting.ts (1)
74-74: LGTM: projectType field addition enables cause/project differentiationAdding the projectType field to the GraphQL query is necessary for components to conditionally handle projects and causes differently.
src/components/views/userProfile/boostedTab/BoostsTable.tsx (1)
34-34: LGTM: Appropriate imports for new functionalityThe imports for
slugToCauseViewandEProjectTypeare correctly added to support the conditional routing logic.Also applies to: 42-42
src/components/views/userProfile/ProfileContributes.tsx (1)
131-140: Verify causes count data sourceThe badge in ProfileContributes.tsx (lines 131–140) currently uses
user?.projectsCount, which represents total projects rather than causes. Our type definitions don’t include acausesCountfield. Please confirm one of the following:
- There is a dedicated causes count on the
userobject (e.g.user.causesCount) and update this badge accordingly.- Using
projectsCounthere is intentional (i.e. projects ≡ causes), or adjust the API/schema to expose a proper causes count.File to review:
- src/components/views/userProfile/ProfileContributes.tsx (lines 131–140)
src/components/views/userProfile/projectsTab/ProjectItem.tsx (4)
126-143: Verify intentional exclusion of verification status for causes.The verification status section is only rendered for projects of type
PROJECT, not for causes. Please confirm this is intentional behavior.
62-68: LGTM: Conditional routing logic is correct.The conditional routing based on project type appropriately directs causes to
/cause/[slug]and projects to/project/[slug].
85-91: LGTM: Conditional labeling implemented correctly.The conditional labeling logic properly differentiates between causes and projects using appropriate localization keys.
Also applies to: 97-105
182-198: Confirm the correct data source for “Total Distributed”
I didn’t find a separatetotalDistributed(or similarly named) field on the project type, yet the UI usesproject.totalDonationsfor both “Total Raised” and “Total Distributed.” Please verify with the backend/GraphQL schema whether:
- There is a distinct field for distributed funds that should be used here, or
project.totalDonationsis indeed intended to represent both values.• File: src/components/views/userProfile/projectsTab/ProjectItem.tsx
• Lines: 182–198lang/en.json (1)
1927-1927: Redundant qualifier in key
cause_status_smallduplicatescause_statuswhile only changing visual size. This leaks presentation concerns into i18n keys.
If the string is identical tolabel.cause.cause_status, reuse that key; otherwise, rename with a semantic suffix (e.g..shortor.abbr) that reflects the content, not styling.src/components/views/userProfile/projectsTab/ProjectActions.tsx (9)
20-20: LGTM: Import addition for project type enumThe import of
EProjectTypeis necessary for the type checking logic introduced later in the component.
23-25: LGTM: Import additions for cause-specific routesThe new route creator imports (
idToCauseEdit,slugToCauseView) are properly imported and will be used for cause-specific navigation.
65-65: LGTM: Clean type-based boolean derivationThe
isCauseboolean is clearly derived from the project type, providing a clean way to conditionally handle causes throughout the component.
104-111: LGTM: Conditional view option with proper routingThe view option correctly uses different labels and routes based on whether the item is a cause or project, maintaining consistent user experience.
114-122: LGTM: Conditional edit option with proper routingThe edit option correctly uses different labels and routes based on whether the item is a cause or project, maintaining consistency with the view option.
127-132: LGTM: Conditional activate/deactivate labelsThe activate/deactivate option correctly uses different labels based on whether the item is a cause or project, providing appropriate terminology for each type.
179-180: LGTM: Proper restriction of verification to projects onlyThe verification logic correctly restricts verification options to projects only (
project.projectType === EProjectType.PROJECT), which makes sense as causes likely don't need the same verification process.
237-237: LGTM: Consistent localization usageThe dropdown label now uses the localization system consistently with other labels in the component.
246-246: LGTM: Modal prop updated for cause supportThe
DeactivateProjectModalnow receives theisCauseprop, allowing the modal to handle causes appropriately.
Missing this:
and this:
Summary by CodeRabbit
New Features
Improvements
Bug Fixes