Fix snake_case/camelCase mismatch in modern-bias page (2 TS errors)

[adhit-r]

Summary

The modern-bias page has 2 TypeScript errors caused by a snake_case/camelCase mismatch between the FastAPI backend (which serializes Python field names as snake_case) and the frontend TypeScript types (which expect camelCase). Pick the right approach, fix the mismatch, and you'll have learned how this codebase crosses the Python <-> TypeScript boundary.

Background

• Backend: FastAPI + Pydantic. Conventional Python serializes fields as snake_case: total_tests, gdpr_compliant, evaluation_time.
• Frontend: TypeScript + React. Conventional JS expects camelCase: totalTests, gdprCompliant, evaluationTime.
• A previous refactor renamed the frontend type definitions to camelCase but did not add a translation layer at the API boundary, so the runtime payload still has snake_case keys while TypeScript thinks it should have camelCase. The compiler catches this - runtime would fail silently with undefined reads.

The Errors

apps/frontend/src/app/(dashboard)/modern-bias/page.tsx(268,9):
  error TS2739: Type '{ total_tests: number; tests_passed: number; tests_failed: number;
                       overall_bias_rate: number; evaluation_time?: string }'
  is missing the following properties from type
  '{ totalTests: number; testsPassed: number; testsFailed: number;
     overallBiasRate: number; evaluationTime?: string }':
  totalTests, testsPassed, testsFailed, overallBiasRate

apps/frontend/src/app/(dashboard)/modern-bias/page.tsx(271,9):
  error TS2559: Type '{ gdpr_compliant?: boolean; ai_act_compliant?: boolean;
                       fairness_score?: number }'
  has no properties in common with type
  '{ gdprCompliant?: boolean; aiActCompliant?: boolean; fairnessScore?: number }'

Both errors are in the body of handleRunEvaluation (around lines 218-340) where results.evaluation_summary and results.compliance_status are passed to a typed function that expects camelCase.

Two Approaches - Please Comment Before Starting

Approach A - Translate at the boundary (recommended, ~2-3h)

Add a snakeToCamel helper inside the api-client (or a small apps/frontend/src/lib/api/case-transform.ts) that recursively walks API responses and renames keys. Wire it into the bias evaluation hook so consumers always see camelCase.

Pros: Frontend code stays idiomatic TypeScript. Future API additions get conversion for free.
Cons: Touches api-client.ts (or adds a new helper imported by the hook). Needs a couple of unit tests.

Approach B - Make the frontend types match snake_case (~30 min)

Change the type definitions used by modern-bias/page.tsx from totalTests -> total_tests, etc. The page already does some manual mapping in handleRunEvaluation - that mapping can be deleted because the shapes will be identical.

Pros: Smallest possible diff.
Cons: Non-idiomatic TypeScript. Will surprise future contributors who expect camelCase frontend types. Doesn't fix the underlying convention drift.

Please comment on this issue with which approach you want to take before starting work. A maintainer will respond within 48 hours to confirm.

Files Involved

• Read first to understand context:

  • apps/frontend/src/app/(dashboard)/modern-bias/page.tsx (lines 75-340 - the hook + the report generators)
  • apps/frontend/src/lib/api/api-client.ts (the wrapper you may extend in Approach A)

• Files you'll modify (Approach A):

  • apps/frontend/src/lib/api/api-client.ts or a new case-transform.ts
  • apps/frontend/src/app/(dashboard)/modern-bias/page.tsx (delete the manual snake->camel remapping in the report generator calls now that the hook returns camelCase)
  • Tests under apps/frontend/src/lib/api/__tests__/ (add 1-2 unit tests for the transformer)

• Files you'll modify (Approach B):

  • apps/frontend/src/app/(dashboard)/modern-bias/page.tsx (the inline type definitions for EvaluationSummary and ComplianceStatus - and the type imported by generatePDFReport/generateDOCXReport)
  • apps/frontend/src/lib/export/json-export.ts (the BiasEvaluationPDFData type)

Acceptance Criteria

• cd apps/frontend && npx tsc --noEmit reports zero errors at modern-bias/page.tsx:268 and :271
• No as any casts
• If Approach A: Includes 1-2 unit tests for the transformer (basic case + nested object case)
• If Approach B: Type renames are consistent - every consumer of BiasEvaluationPDFData and the eval-summary type uses snake_case
• Manual smoke test (optional): with a backend running, navigate to /dashboard/modern-bias, run an evaluation, and verify the PDF/DOCX/JSON export buttons still produce correct output

How to Reproduce

git clone https://github.com/adhit-r/fairmind.git
cd fairmind/apps/frontend
npm install
npx tsc --noEmit

Errors at modern-bias/page.tsx:268 and :271 should appear.

Estimated Effort

• Approach A: 2-3 hours (helper + tests + cleanup)
• Approach B: 30 minutes (mechanical rename)

Both are welcome - pick based on your experience level.

Why This Is a Good First Issue

• Tightly scoped. Two errors, one file (Approach B) or one new helper (Approach A).
• Educational. You'll learn how a Python/TypeScript stack handles the case-naming impedance mismatch.
• Has a clear right answer once you pick the approach.
• Maintainer support. Comment on this issue with questions and a maintainer will respond within 48 hours.

Help / Questions

Comment on this issue to claim it (say "I'd like to take this" + which approach) before starting, so we don't have duplicate work. A maintainer will confirm within 48 hours.