fix(board): render error state instead of infinite loader when data is null

[nios-x]

Proposed change

Resolves #3052

Contributor: Soumya (GitHub: @nios-x)
Role: Student contributor (GSoC aspirant)

This PR fixes an issue on the Board page where the UI enters an infinite loading state when the GraphQL response for a selected year returns null.

Previously, the loading state was rendered before validating whether boardOfDirectors data existed. As a result, when the query completed successfully but returned null, the page remained stuck on the loading spinner.

This change updates the conditional rendering logic to:

• Check for null board data before rendering the loading state
• Display a proper 404-style error message when board data is not available
• Ensure the loading spinner is shown only while the query is actively loading

Checklist

• Required: I read and followed the contributing guidelines
• Required: I ran make check-test locally and all tests passed
• I used AI for code, documentation, or tests in this PR

Previous ScreenShots:

Current ScreenShots

[coderabbitai]

Summary by CodeRabbit

• Refactor
  • Improved loading state management on the candidates page for better performance and maintainability.

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

Walkthrough

Refactors candidates page to use Apollo's native loading flag from useQuery instead of manual isLoading state management, allowing the GraphQL query lifecycle to drive the loading indicator and fixing infinite loading when no data exists for a given year.

Changes

Cohort / File(s)	Summary
Loading State Refactoring frontend/src/app/board/[year]/candidates/page.tsx	Replaced manual isLoading state with Apollo's loading flag from useQuery; removed setIsLoading calls and the effect toggling loading state; updated spinner conditional rendering to use the query's loading instead

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• Fixed sporadic 404 flash  #2441 — Refactors component loading handling to replace manual isLoading state with Apollo useQuery's native loading flag across other components

Suggested labels

frontend

Suggested reviewers

• arkid15r
• kasya

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title accurately describes the main fix: rendering an error state instead of an infinite loader when data is null on the board page.
Description check	✅ Passed	The PR description is well-detailed and clearly explains the issue, the proposed solution, and references the linked issue #3052 with before/after screenshots.
Linked Issues check	✅ Passed	The code changes align with issue #3052 requirements: handling null boardOfDirectors data before checking loading state to display error instead of infinite loader.
Out of Scope Changes check	✅ Passed	All changes are scoped to fixing the infinite loader issue by replacing manual loading state with Apollo's loading flag and adjusting conditional rendering logic.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

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

---

📜 Recent 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 c83db94 and 46721e8.

📒 Files selected for processing (1)

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

🧰 Additional context used

🧬 Code graph analysis (1)

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

frontend/src/types/__generated__/boardQueries.generated.ts (1)

• GetBoardCandidatesDocument (33-33)

🔇 Additional comments (2)

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

91-91: LGTM! Clean refactor to use Apollo's built-in loading state.

Using Apollo's native loading flag from useQuery is the correct approach and eliminates the need for manual loading state management. This directly addresses the infinite loading issue by ensuring the loading state accurately reflects the GraphQL query lifecycle.

---

676-688: Excellent fix! The conditional rendering order now correctly handles the null data case.

The evaluation order is now correct:

1. Show loading spinner while the query is in progress (loading === true)
2. Show 404 error when the query completes but returns no board data (!graphQLData?.boardOfDirectors)
3. Render candidates on success

This properly resolves issue #3052 where null board data would result in an infinite loading state. The Apollo loading flag ensures the spinner is only shown during active query execution, and the null check immediately follows to catch cases where the backend returns no data for the selected year.

---

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.}

[nios-x]

@arkid15r @kasya
Sorry for closing that PR Early.

[nios-x]

There are no duplicate PR please do not close this one.
Actually i thought to close review required PR and raise a new one.

[nios-x]

@arkid15r Merge it as i was unaware about the rules so some problem happened at first . You can see everything is working fine below. Futher i will be more sincere with raising PRs
https://github.com/user-attachments/assets/97969e8c-786d-457d-84fc-e7db8ad82eb8

[nios-x]

@kasya

[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

[kasya]

@nios-x Please continue work in your original PR. This is ridiculous how many PRs were already opened and closed for this issue - it took me several minutes to find the correct one.

If you're not able to stick to our rules I'll just reassign this issue to someone else.

[nios-x]

@kasya I fixed the code but any of the maintainers are not taking the PRs seriously. Sometimes the bot added changes required then I closed the pr and reraised it. This is not a correct way. But all you can merge that pr