fix: load data on compare/share page (closes #41)

[GauravSolo]

Fixes #41

Summary

The compare/share page was not showing the models and responses for shared comparison links, even though the backend API returned the data. This PR wires the existing API response into the UI so that the shared page correctly displays the prompt, models, and responses.

Changes

• Use responseA.data and responseB.data from the API to render the two model responses on the compare/share page.
• Use modelA.name / modelB.name when available; if the name is "unknown", fall back to displaying modelId so the user can still identify the models.
• Ensure the share view uses the same fields as the main compare view so behavior is consistent.

Testing

• Opened an existing compare/share link (e.g. the one mentioned in Data not loading on compare/share page #41).
• Verified that:
  • Both model responses are now visible on the shared page.
  • Model labels are populated (using name or modelId).
  • The page loads without errors in the browser console.

Screenshot

Summary by CodeRabbit

• Bug Fixes
  • Improved model name display in comparison badges to show model names when available, with model IDs as fallback
  • Fixed response data display in model comparison panels for more accurate results

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

A shared comparison page now correctly displays model response data by referencing the appropriate data field instead of response field, and model names in badges prefer non-"unknown" values with fallback to modelId for clarity.

Changes

Cohort / File(s)	Summary
Shared comparison page data display fix apps/webapp/src/app/compare/share/[id]/page.tsx	Updated model A and B response panels to render from responseA.data and responseB.data fields instead of responseA.response and responseB.response; refined badge labels to prefer a non-"unknown" model name when available, otherwise fallback to modelId

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• Single file with straightforward field reference corrections
• Badge label logic adjustment is simple conditional logic

Poem

🐰 Data flows like carrots in a burrow deep,
Model names no longer lost in the weep,
Compare and share, the fix is complete,
Responses now render, the page looks so sweet! 🥕✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the fix for the compare/share page data loading issue and references the linked issue #41.
Linked Issues check	✅ Passed	All coding objectives from issue #41 are met: API responses are wired into the UI, model names display with fallback to modelId, and the shared page now renders the same data as the main compare view.
Out of Scope Changes check	✅ Passed	The changes are directly scoped to fixing the compare/share page data loading issue; no unrelated modifications are present.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

apps/webapp/src/app/compare/share/[id]/page.tsx (1)

43-44: Define a proper type for response objects instead of any.

The responseA and responseB fields are typed as any, which bypasses TypeScript's type safety. Consider defining an interface that includes at least the data field and any other fields returned by the API.

Apply this diff to add proper typing:

+interface ModelResponse {
+  data: string;
+  // Add other fields returned by the API
+}
+
 type MatchData = {
   id: string;
   winnerId: number | null;
   isShareable: boolean;
   createdAt: Date;
   modelA: {
     id: number;
     name: string;
     provider: string;
     modelId: string;
     owner: string;
     host: string;
     elo: number | null;
   };
   modelB: {
     id: number;
     name: string;
     provider: string;
     modelId: string;
     owner: string;
     host: string;
     elo: number | null;
   } | null;
   prompt: {
     id: string;
     question: string;
     fullPrompt: string;
     type: string;
   };
-  responseA: any;
-  responseB: any;
+  responseA: ModelResponse;
+  responseB: ModelResponse;
 };

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9f0986c and 5f89085.

📒 Files selected for processing (1)

• apps/webapp/src/app/compare/share/[id]/page.tsx (4 hunks)

🔇 Additional comments (4)

apps/webapp/src/app/compare/share/[id]/page.tsx (4)

197-199: LGTM! Good fallback logic for model labels.

The badge correctly displays the model name when available and not "unknown", falling back to modelId otherwise. This provides a clear, identifiable label for each model as specified in the PR objectives.

---

246-248: LGTM! Consistent with Model A label logic.

The Model B badge uses the same fallback pattern as Model A, ensuring consistent behavior across both comparison sides.

---

269-269: LGTM! Completes the response display fix.

The change to use responseB.data mirrors the Model A fix and ensures both responses display correctly.

---

219-219: Use .data field to correctly access response content.

The change to use matchData.responseA.data is correct. Line 127 in the same file already uses .data for calculations, confirming this is the proper field in the matchData structure.

(Note: Other components in the codebase such as response-comparison.tsx and llm-judge-scorer.ts use .response because they work with different data structures; this is expected and not an error.)