[Feature] Add rank change indicator (↑↓) to leaderboard rows using historical data

[akshara200829-lgtm]

Feature Request

Currently the leaderboard shows only current ranks with no indication of movement since the last sync. Users have no way to know if they climbed or dropped in ranking.

Proposed behaviour:

Each leaderboard row should show a rank change indicator:

• ↑3 (moved up 3 places) in green
• ↓2 (dropped 2 places) in red
• = (no change) in dim
• NEW (first appearance on this tab's leaderboard)

This fits the terminal theme and can be styled as:
[+3] / [-2] / [==] / [NEW]

How to implement:

The leetcode-ranking-data repo already stores daily JSON snapshots.Fetch both today's and yesterday's JSON for the active tab, compute rank delta per user.id, and render inline.

Why it matters:

Every competitive leaderboard (Codeforces, LeetCode itself) shows rank movement. Without it, the leaderboard feels static and loses motivational value — users can't see their progress reflected in real time.

Hey @codepvg ,
I would like to work on this issue under GSSOC. Please assign this to me!

[Yogender-verma]

Hi @akshara200829-lgtm,

I'd like to work on this issue under GSSoC 2026.

I reviewed the proposed behavior and implementation approach. I plan to fetch the current and previous leaderboard snapshots, calculate rank deltas per user, and display indicators such as ↑, ↓, =, and NEW while keeping the existing terminal-style UI consistent.

Could you please assign this issue to me?

Thanks!

[jagdish-15]

@akshara200829-lgtm

One thing I'd like some clarification on regarding the implementation. You mentioned fetching today's and yesterday's snapshot JSON for the active tab and comparing them, but currently we only store historical raw user data (see here). We don't store historical versions of the generated leaderboard rankings for each tab (overall, weekly, monthly, daily).

The tab-wise leaderboard files only exist for the current state, so I'm not sure that approach would work as described.

One thought I had is whether it would make more sense to calculate and store the rank change during the sync process rather than computing it entirely on the frontend.

For example, the sync script could compare the current rankings against the rankings from the final sync of the previous day. Since we keep commits for every sync, we could retrieve the leaderboard files (overall, weekly, monthly, daily) from the last commit of the previous day and determine each user's position exactly as it was at that point in time. The script could then calculate a rankChange value for each user and store it directly in the generated leaderboard JSON files.

That would keep the frontend simple and avoid additional requests or calculations on page load.

Please let me know if you had a different approach in mind before moving forward with this.

[akshara200829-lgtm]

Hi @jagdish-15, thanks for the clarification!
I've reviewed the sync script (scripts/sync_leaderboard.js) and your approach makes complete sense. The script already reads and overwrites the leaderboard JSONs (overall.json, daily.json, weekly.json, monthly.json) each sync cycle, so I can read each file before overwriting it to get the previous rankings, compute rankChange per user (as +N, -N, =, or NEW), and store it directly in the output JSON.
The frontend would then just read and render the stored rankChange field — no extra fetches needed.