UI fixes

[Benjtalkshow]

Summary by CodeRabbit

• Improvements
  • Enhanced pagination control with dynamic page size adjustment for the hackathon participants list.
  • Improved pagination logic with unified data handling to better manage page size changes and trigger data reloads accordingly.

[vercel]

@Benjtalkshow is attempting to deploy a commit to the Threadflow Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes refactor pagination logic by introducing dynamic page size state in the participants page and unifying pagination object extraction from API responses in the hackathons hook to enable flexible, consistent pagination handling across features.

Changes

Cohort / File(s)	Summary
Participants Page Pagination app/(landing)/organizations/[id]/hackathons/[hackathonId]/participants/page.tsx	Introduces dynamic pageSize state and updates pagination handlers to accept optional limit parameters. Resets pagination to page 1 when page size changes; otherwise navigates to the requested page.
Hackathons Hook Pagination Extraction hooks/use-hackathons.ts	Unifies pagination object extraction by reading from either response.data?.pagination or response.meta?.pagination for both hackathons and participants flows, reducing redundant code.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• Hackathon analytics #381: Modifies pagination handling in hooks/use-hackathons.ts for hackathons, participants, and drafts pagination state management.

Suggested reviewers

• 0xdevcollins

Poem

🐰✨ Hop! Skip! Jump through pages anew,
Dynamic sizes dancing in pagination's brew,
No more static bounds—flexibility's true,
The hook now speaks one unified tongue too! 📖

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check	❓ Inconclusive	The title 'UI fixes' is too vague and generic; it does not convey meaningful information about the specific changes made to pagination logic and data fetching.	Use a more descriptive title that reflects the main change, such as 'Implement dynamic pagination for hackathons and participants' or 'Refactor pagination to support dynamic page sizing'.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 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]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

app/(landing)/organizations/[id]/hackathons/[hackathonId]/participants/page.tsx (1)

238-255: ⚠️ Potential issue | 🟡 Minor

Drive the rows-per-page control from pageSize, not participantsPagination.itemsPerPage.

DataTablePagination reads the select value from table.getState().pagination.pageSize, but this table is still controlled by participantsPagination.itemsPerPage. After a user picks a new size, the control can bounce back to the old value until the fetch finishes because the server pagination hasn't updated yet. Use the local pageSize state as the source of truth here.

Suggested adjustment

     state: {
       pagination: {
         pageIndex: participantsPagination.currentPage - 1,
-        pageSize: participantsPagination.itemsPerPage,
+        pageSize,
       },
     },
     onPaginationChange: updater => {
       if (typeof updater === 'function') {
         const newState = updater({
           pageIndex: participantsPagination.currentPage - 1,
-          pageSize: participantsPagination.itemsPerPage,
+          pageSize,
         });
 
-        if (newState.pageSize !== participantsPagination.itemsPerPage) {
+        if (newState.pageSize !== pageSize) {
           setPageSize(newState.pageSize);
           handlePageChange(1, newState.pageSize);
         } else {
           handlePageChange(newState.pageIndex + 1);
         }
       }
     },

As per coding guidelines, "Prefer readability over performance in React and Next.js development".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/`(landing)/organizations/[id]/hackathons/[hackathonId]/participants/page.tsx
around lines 238 - 255, The pagination control is currently driven by
participantsPagination.itemsPerPage which causes the rows-per-page select to
revert while the server fetch runs; update DataTablePagination to drive pageSize
from the local pageSize state instead of participantsPagination.itemsPerPage. In
the onPaginationChange handler of the table (where updater is applied) use the
local pageSize value as the source of truth: call setPageSize(newState.pageSize)
immediately when the user selects a new size, call handlePageChange(1,
newState.pageSize) to fetch page 1 with the new size, and ensure the table
initial state uses pageSize (pageIndex: participantsPagination.currentPage - 1,
pageSize: pageSize) so table.getState().pagination.pageSize reflects the local
pageSize.

🧹 Nitpick comments (1)

hooks/use-hackathons.ts (1)

231-243: Replace the new as any pagination casts with a typed normalizer.

These casts remove type checking where the response shape varies. The pagination is already defined in your API types (HackathonsData.pagination and ParticipantsData.pagination), so this should remain typed instead of falling back to any.

Typed approach

+type PaginationShape = {
+  page?: number;
+  limit?: number;
+  total?: number;
+  totalPages?: number;
+  hasNext?: boolean;
+  hasPrev?: boolean;
+};
+
+const getPagination = (response: {
+  data?: unknown;
+  meta?: { pagination?: PaginationShape };
+}): PaginationShape | undefined => {
+  if (
+    response.data &&
+    typeof response.data === 'object' &&
+    'pagination' in response.data
+  ) {
+    return (response.data as { pagination?: PaginationShape }).pagination;
+  }
+
+  return response.meta?.pagination;
+};
...
-        const pagination = (response.data?.pagination ||
-          response.meta?.pagination) as any;
+        const pagination = getPagination(response);
...
-        const pagination = (response.data?.pagination ||
-          response.meta?.pagination) as any;
+        const pagination = getPagination(response);

Applies to lines 231–243 and 580–591. Per coding guidelines: "Do not use 'any' type; always search for proper Trustless Work entity types."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@hooks/use-hackathons.ts` around lines 231 - 243, Replace the unsafe "as any"
cast on the pagination object with a typed normalizer that maps the possible
response shapes to the known pagination type (use the API types
HackathonsData.pagination or ParticipantsData.pagination), e.g. create a small
helper (normalizePagination) that accepts response.data?.pagination ||
response.meta?.pagination, narrows/validates fields (page, totalPages, total,
limit, hasNext, hasPrev) and returns a strongly typed pagination object; then
use that helper when calling setHackathonsPagination and when updating
hackathonsPageRef.current and repeat the same replacement for the other
occurrence that handles ParticipantsData pagination so no "any" remains.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In
`@app/`(landing)/organizations/[id]/hackathons/[hackathonId]/participants/page.tsx:
- Around line 238-255: The pagination control is currently driven by
participantsPagination.itemsPerPage which causes the rows-per-page select to
revert while the server fetch runs; update DataTablePagination to drive pageSize
from the local pageSize state instead of participantsPagination.itemsPerPage. In
the onPaginationChange handler of the table (where updater is applied) use the
local pageSize value as the source of truth: call setPageSize(newState.pageSize)
immediately when the user selects a new size, call handlePageChange(1,
newState.pageSize) to fetch page 1 with the new size, and ensure the table
initial state uses pageSize (pageIndex: participantsPagination.currentPage - 1,
pageSize: pageSize) so table.getState().pagination.pageSize reflects the local
pageSize.

---

Nitpick comments:
In `@hooks/use-hackathons.ts`:
- Around line 231-243: Replace the unsafe "as any" cast on the pagination object
with a typed normalizer that maps the possible response shapes to the known
pagination type (use the API types HackathonsData.pagination or
ParticipantsData.pagination), e.g. create a small helper (normalizePagination)
that accepts response.data?.pagination || response.meta?.pagination,
narrows/validates fields (page, totalPages, total, limit, hasNext, hasPrev) and
returns a strongly typed pagination object; then use that helper when calling
setHackathonsPagination and when updating hackathonsPageRef.current and repeat
the same replacement for the other occurrence that handles ParticipantsData
pagination so no "any" remains.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 4701950d-0723-4839-aff4-2d1bcc5b8b89

📥 Commits

Reviewing files that changed from the base of the PR and between a5f4370 and 62b0b19.

📒 Files selected for processing (2)

• app/(landing)/organizations/[id]/hackathons/[hackathonId]/participants/page.tsx
• hooks/use-hackathons.ts