BaseballHelm: Stop infinite loading on Events when coach has zero teams

[njrini99-code]

Problem

EventsClient initializes loading to true but only calls fetchEvents() when teams.length > 0. A showcase coach with no teams never clears loading.

Evidence

• src/app/baseball/(dashboard)/dashboard/events/EventsClient.tsx line 107: useState(true)

    if (teams.length > 0) {
      fetchEvents();
    }
  }, [authLoading, coach?.id, teams]);

When teams is [] and auth is ready, fetchEvents never runs and loading stays true.

Why it matters

The Events page is stuck on a skeleton forever for new showcase orgs — a broken empty state.

Acceptance criteria

• When auth is ready and teams.length === 0, set loading false and show the empty state.
• No perpetual "Loading…" subtitle/header.

[njrini99-code]

@coderabbitai plan

[coderabbitai]

Coding Plan

Summary

• Remove the teams.length > 0 gate around fetchEvents() so the function's existing internal early-returns (which already set loading=false) always execute, following the established sibling-page convention.
• Consume useTeams().isLoading and incorporate it into the effect guard/dependencies so an empty teams array is only treated as "no teams" after teams finish loading, preventing a transient incorrect empty state.
• Rely entirely on the already-present empty-state JSX and header logic, scoping the change to the single EventsClient.tsx fetch effect.

Design Choices

Design Choice 1: Should the fix consume `useTeams().isLoading` to distinguish "teams still loading" from "coach has zero teams," or simply follow the sibling-page convention of removing the gate and relying on the existing internal early-returns?

Options Considered:

1. Remove the if (teams.length > 0) gate and always call fetchEvents(), relying on the function's existing teamIds.length === 0 branch (which already sets events=[] and loading=false). This matches the established idiom used by sibling Client components.
2. Additionally destructure isLoading from useTeams() and add it to the effect's guard/dependency array so the effect waits for teams to finish loading before treating an empty array as "no teams."

Chosen Option: 2

Rationale: Both reliably clear the stuck-loading state; the difference is whether we also guard against acting on a transiently-empty teams array before useTeams() resolves. Option 2 both fixes the infinite-loading bug and prevents a brief incorrect empty-state flash while teams are still resolving, using a flag the hook already provides; the change remains minimal and low-risk.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Fix the Events loading lifecycle

This phase corrects the fetch effect in the Events page so the loading flag always resolves once auth and teams are ready, making the already-present empty state reachable for coaches with zero teams. All work is contained to a single component; no new abstractions or shared-hook changes are required.

Task 1: Always resolve loading in the Events fetch effect

Ensure fetchEvents() runs (and clears loading) regardless of how many teams the coach has, while still avoiding premature decisions during team loading.

• Update src/app/baseball/(dashboard)/dashboard/events/EventsClient.tsx to remove the outer if (teams.length > 0) { fetchEvents(); } gate so fetchEvents() is always invoked; its existing internal teamIds.length === 0 branch already sets events=[] and loading=false.
• Destructure isLoading (e.g., as teamsLoading) from useTeams() instead of only { teams }.
• Extend the effect's early-return guard to wait on team loading — i.e., return early (without flipping loading to a misleading state) while authLoading || teamsLoading, and add teamsLoading to the effect's dependency array so the fetch re-runs once teams resolve.
• Verify the guard ordering so that when auth is ready and teamsLoading is false with zero teams, the effect proceeds to the zero-teams branch and sets loading=false.

Task 2: Confirm empty-state and header behavior

Validate that the existing UI now renders correctly once loading resolves.

• Confirm the existing "Honest empty state" block (rendered when filteredEvents.length === 0 and loading === false) now displays for a zero-team coach, and that the header subtitle no longer remains stuck on "Loading…".
• No structural UI changes are expected; this task is verification of the rendered output for the zero-teams, has-teams, and error paths.

🤖 Prompt for AI agents

Implement a fix to the Events page's data-fetching effect so the `loading` flag
always resolves, even for coaches with zero teams. Goal: eliminate the infinite
loading skeleton and surface the existing 'No upcoming events' empty state.

In `src/app/baseball/(dashboard)/dashboard/events/EventsClient.tsx`:
- Remove the outer `if (teams.length > 0) { fetchEvents(); }` gate so
`fetchEvents()` is always invoked regardless of team count. Rely on the
function's existing internal `teamIds.length === 0` branch, which already sets
`events=[]` and `loading=false`.
- Destructure `isLoading` from `useTeams()` (name it `teamsLoading`) in addition
to `teams`.
- Extend the effect's early-return guard so it returns early (without setting a
misleading loading state) while `authLoading || teamsLoading` is true, and add
`teamsLoading` to the effect's dependency array so the fetch re-runs once teams
finish resolving.
- Ensure guard ordering is correct: once auth is ready and `teamsLoading` is
false, even with zero teams, the effect should proceed into the fetch logic and
reach the zero-teams branch that sets `loading=false`.

After making this change, verify (without making structural UI changes) that:
- The existing 'Honest empty state' block, shown when `filteredEvents.length ===
0` and `loading === false`, now correctly displays for a zero-team coach.
- The header subtitle no longer remains stuck on 'Loading…'.
- Behavior remains correct for the zero-teams, has-teams, and error paths.

Research

The baseball dashboard is built from per-page *Client.tsx components under src/app/baseball/(dashboard)/dashboard/. Each page manages its own local loading state inside a data-fetching useEffect, and the convention is to explicitly call setLoading(false) in every early-return branch (including zero-team cases), while letting render-time empty states be driven by the data array's .length. Auth state comes from useAuth() (exposing coach and loading: authLoading), and the coach's teams come from useTeams() (src/hooks/use-teams.ts), which also exposes an isLoading flag. EventsClient.tsx currently consumes only { teams } from useTeams() and gates its fetch behind teams.length > 0, which is the source of the bug.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Implement a fix to the Events page's data-fetching effect so the `loading` flag
always resolves, even for coaches with zero teams. Goal: eliminate the infinite
loading skeleton and surface the existing 'No upcoming events' empty state.

In `src/app/baseball/(dashboard)/dashboard/events/EventsClient.tsx`:
- Remove the outer `if (teams.length > 0) { fetchEvents(); }` gate so
`fetchEvents()` is always invoked regardless of team count. Rely on the
function's existing internal `teamIds.length === 0` branch, which already sets
`events=[]` and `loading=false`.
- Destructure `isLoading` from `useTeams()` (name it `teamsLoading`) in addition
to `teams`.
- Extend the effect's early-return guard so it returns early (without setting a
misleading loading state) while `authLoading || teamsLoading` is true, and add
`teamsLoading` to the effect's dependency array so the fetch re-runs once teams
finish resolving.
- Ensure guard ordering is correct: once auth is ready and `teamsLoading` is
false, even with zero teams, the effect should proceed into the fetch logic and
reach the zero-teams branch that sets `loading=false`.

After making this change, verify (without making structural UI changes) that:
- The existing 'Honest empty state' block, shown when `filteredEvents.length ===
0` and `loading === false`, now correctly displays for a zero-team coach.
- The header subtitle no longer remains stuck on 'Loading…'.
- Behavior remains correct for the zero-teams, has-teams, and error paths.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[njrini99-code]

Fixed and deployed in PR #650 (main 08a94d1) — explicitly named in the PR's fix list. Reopen if it doesn't hold on prod.