Abrar/feature/performance score frontend

[abrar-deakin]

Implemented performance scoring endpoint integration into frontend.

Changes:

• Added guard score API integration
• Displayed current rating on Home screen
• Displayed performance summary on Profile screen

[TeddyScript101]

Code Review Summary

In your previous submission, you have the wrong type of API response.

Without proper decomposition or data massaging, this is what you have done
setGuardScore(score)

Actual shape of "data" from the API response

Because of this, the score of a guard will forever be '0.0'

[abrar-deakin]

I have addressed the review comments and fixed the API response handling issue. The performance score is now displaying correctly on both the Home and Profile screens. Please see the updated screenshots attached. Thank you!

[Krisha190235]

Request changes. The core feature works, but the duplicate API call in HomeScreen, copy-pasted logic across screens, and leftover console.log statements should be addressed before merging.

[TeddyScript101]

Hi,

We have reviewed this multiple times and invested significant time providing detailed feedback. The same fundamental issues keep appearing. Therefore, this is your last chance to correct everything before the 24 May deadline.

After reviewing the actual API response and the GuardScore type definition, there are critical problems that need to be fixed:

---

1. The type does not match the actual API response

The real API response is:

{
  guardId: string
  score: number
  breakdown: {
    punctuality: { score, maxPoints, onTimeCheckins, totalCheckins }
    shiftCompletion: { score, maxPoints, completedShifts, totalAssignedShifts }
    incidents: { score, maxPoints, high, medium, low, deduction }
  }
}

But the current GuardScore type contains fields like rating, attendanceRate, punctualityRate, summary, and message — none of which exist in the API response. Where did these come from? You cannot define fields the API does not return. Remove them.

If breakdown is not being used, that is acceptable — but it should still be acknowledged in the type as breakdown: unknown, not silently omitted or replaced with invented fields. unknown means "I know this field exists in the API but I am not handling it". Do not use any — any disables all compiler protection. unknown keeps the contract honest.

type ApiGuardScore = {
  guardId: string;
  score: number;
  breakdown: unknown; // exists in API, not in use
};

export type GuardScore = Pick<ApiGuardScore, 'guardId' | 'score'>;

---

2. All fields marked as ? — this defeats the purpose of TypeScript

Every field in GuardScore is marked optional. This means the compiler will never complain regardless of what you pass in. That is not type safety — that is just avoiding the compiler's job. I flagged this in my first round of feedback. This is the second time I am saying the same thing.

guardId and score are always present in the API response. They must be required. The rule is simple: if the API always returns it, make it required. If you are not using it, use Pick to exclude it. If it is genuinely sometimes absent, only then use ?.

---

3. guardScore?.rating does not exist — and score: 0 is handled incorrectly

This is the current render logic:

value={
  guardScore?.rating
    ? guardScore.rating.toFixed(1)
    : guardScore?.score
      ? guardScore.score.toFixed(1)
      : '0.0'
}

Two bugs here:

• rating does not exist in the API response. It will always be undefined, so the first condition is always false. This is dead code — and it only exists because the type was wrong in the first place.
• guardScore?.score is falsy when score is 0. When the API returns score: 0 (as seen in the actual response), this condition falls through to '0.0' — not because the value is absent, but because 0 is falsy. The output looks correct but for completely the wrong reason. This is a silent logic bug.

The correct fix:

value={guardScore?.score != null ? guardScore.score.toFixed(1) : '0.0'}

• Remove rating entirely — it does not exist in the API
• Use != null to check for actual absence, not truthiness
• score: 0 will now correctly display as '0.0' through the first branch, not the fallback

---

Please re-read the API response carefully and fix all of the above before the deadline.

Thanks