[PERFORMANCE] : GitRank.jsx: Unpaginated live leaderboard listener causes scaling bottleneck and high Firestore read costs

[MayurKharat0390]

Is your feature request related to a problem?

❌ Describe the bug

On the GitRank Rating Engine page (/dashboard/gitrank), the global leaderboard mounts a real-time listener using Firestore's onSnapshot on the users collection:

const q = query(
  collection(db, "users"),
  where("onboardingStatus", "==", "complete")
);

### Describe the solution you'd like

// Sort by totalPoints descending
users.sort((a, b) => (b.points?.totalPoints || 0) - (a.points?.totalPoints || 0));

// Assign ranks
const ranked = users.map((u, i) => ({
  ...u,
  rank: i + 1
}));

### Describe alternatives you've considered

_No response_

### Mockups/Screenshots

_No response_

### Before submitting

- [x] I have read the [Contributing Guidelines](https://github.com/indresh404/RankerHub/blob/main/docs/CONTRIBUTING.md)
- [x] I have checked for duplicate feature requests.
- [x] I have discussed this idea in [Discussions](https://github.com/indresh404/RankerHub/discussions) (especially if it is a major feature).

[Shamarvey1]

i love to work on this assign this to me !

[uNikhil-codes]

Hi @indresh404, I would like to claim this performance optimization issue.

Using onSnapshot on the entire users collection without limits creates a severe scaling bottleneck and high Firestore read costs. Here is my proposed plan to optimize the leaderboard:

1. Move to One-Time Fetching: Replace the real-time onSnapshot listener with getDocs inside a useEffect hook. This limits data retrieval to a single fetch when the dashboard mounts, rather than continuous real-time streaming for every user edit.
2. Query-Level Sorting and Limiting: Offload sorting and pagination to Firestore by updating the query:

   const q = query(
     collection(db, "users"),
     where("onboardingStatus", "==", "complete"),
     orderBy("points.totalPoints", "desc"),
     limit(100)
   );