Simplify heatmap data checks for contributions and communications

[SidharthxNST]

Resolves: #3262

This PR improves the user experience for projects or chapters that don’t yet have any activity. When an entity has zero contributions, the contribution section (stats and heatmap) is no longer shown, preventing empty or confusing UI elements.

The solution adds a simple check to see whether any contribution data actually exists before rendering the contribution section. If there’s no activity, the entire section is skipped, so users only see meaningful information.

This is a UI-only change. It doesn’t modify backend logic or alter the behavior for entities that already have contribution data — those continue to work exactly as before.

Test Plan

Manual verification of contribution rendering logic
Entities with zero contributions do not render stats or heatmap
Entities with contribution data render as before

Checklist

• Required: I followed the contributing workflow
• Required: I verified that my code works as intended and resolves the issue as described
• Required: I ran make check-test locally: all warnings addressed, tests passed
• I used AI for code, documentation, tests, or communication related to this PR

[coderabbitai]

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Fixed heatmap rendering logic on the candidates page to display contribution and communication heatmaps only when they contain actual data points.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Walkthrough

Modified render guards for two heatmap components to check for any positive count values instead of non-empty key sets. This prevents heatmaps from displaying when entities have zero contributions, addressing visual clutter for new projects.

Changes

Cohort / File(s)	Summary
Heatmap Rendering Guards frontend/src/app/board/[year]/candidates/page.tsx	Changed Object.keys(...).length > 0 to Object.values(...).some(count => count > 0) for both contributionHeatmapData and communicationHeatmapData render conditions, ensuring heatmaps only display when at least one data point has a positive value

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• feat: Add Contribution Heatmap to Chapter and Project Pages #2674: Modifies heatmap rendering in the same file by adding heatmap usage and variant props to ContributionHeatmap components.

Suggested labels

frontend

Suggested reviewers

• arkid15r
• kasya

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Simplify heatmap data checks for contributions and communications' accurately describes the main change of improving how contribution and communication heatmap rendering conditions are evaluated.
Description check	✅ Passed	The description is directly related to the changeset, explaining the motivation for hiding empty contribution sections and confirming the UI-only nature of the change.
Linked Issues check	✅ Passed	The PR successfully addresses issue #3262 by implementing the exact solution requested: preventing the contribution heatmap from rendering when an entity has zero contributions.
Out of Scope Changes check	✅ Passed	The changes are narrowly focused on the heatmap rendering conditions in a single file and directly align with the objective to hide contributions for entities with zero activity.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

frontend/src/app/board/[year]/candidates/page.tsx (2)

460-472: Logic change correctly hides heatmaps when all contribution counts are zero.

The switch from checking Object.keys(...).length > 0 to Object.values(...).some(count => count > 0) properly addresses the issue where heatmaps appeared confusing for entities with zero contributions.

Minor nit: the indentation of the callback and closing parenthesis appears slightly off.

🔧 Optional: align indentation

             {snapshot.contributionHeatmapData &&
-              Object.values(snapshot.contributionHeatmapData).some(
-              (count) => count > 0
-              ) && (
+              Object.values(snapshot.contributionHeatmapData).some((count) => count > 0) && (
                 <div className="mt-3">

---

623-637: Consistent application of the same logic for communication heatmap.

The condition correctly prevents displaying the communication heatmap when there's no actual engagement data (all zeros).

Minor nit: similar indentation inconsistency as the contribution heatmap check.

🔧 Optional: align indentation

         {snapshot?.communicationHeatmapData &&
-          Object.values(snapshot.communicationHeatmapData).some(
-          (count) => count > 0
-            ) && (
+          Object.values(snapshot.communicationHeatmapData).some((count) => count > 0) && (
             <div className="mt-4 w-full border-t border-gray-200 pt-4 dark:border-gray-700">

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 318d333 and 16be7a7.

📒 Files selected for processing (1)

• frontend/src/app/board/[year]/candidates/page.tsx

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a length check before rendering HealthMetrics: `healthMetricsData.length > 0`. This ensures that when HealthMetrics is rendered, the data array has at least one element, making accessing data[0] safe within the HealthMetrics component.

Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a safety check that ensures HealthMetrics component is only rendered when healthMetricsData exists and has at least one element: `healthMetricsData && healthMetricsData.length > 0`. This makes accessing data[0] safe within the HealthMetrics component.

📚 Learning: 2025-06-20T16:12:59.256Z

Learnt from: ahmedxgouda
Repo: OWASP/Nest PR: 1633
File: frontend/src/components/HealthMetrics.tsx:30-30
Timestamp: 2025-06-20T16:12:59.256Z
Learning: In the DetailsCard component (frontend/src/components/CardDetailsPage.tsx), there's a length check before rendering HealthMetrics: `healthMetricsData.length > 0`. This ensures that when HealthMetrics is rendered, the data array has at least one element, making accessing data[0] safe within the HealthMetrics component.

Applied to files:

• frontend/src/app/board/[year]/candidates/page.tsx

[kasya]

Closed in favor of #3314