[Due for payment 2026-09-15] [$250] Update pages using the common table component to scroll the entire page

[JS00001]

We've recently updated the following pages to use the new components/Table component (stored in components/Tables)

• Workspaces
• Domains
• Categories
• Company Cards

The current behavior of these pages is for the table body to scroll, but nothing else. Lets add a headerComponent prop to these tables (passed from the page), and pass the header content, buttons, etc to the table, so that the entire view scrolls. Note: We also want the table header to stick to the top of the page

This issue is on hold until #90537 is merged

Issue Owner

Current Issue Owner: @Krishna2323

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022065394629663983091
• Upwork Job ID: 2065394629663983091
• Last Price Increase: 2026-06-12

[melvin-bot]

@Krishna2323 Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

Current assignee @Krishna2323 is eligible for the External assigner, not assigning anyone new.

[JS00001]

this is off of hold

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-12 11:40:08 UTC.

Proposal

What is the root cause of that problem?

The common table rows are the only part owned by the table's FlashList. Header content, buttons, filters, and sometimes <Table.Header /> are rendered outside Table.Body, so they sit outside the scroll view and stay fixed while only the rows move.

Company Cards shows the split: on narrow layout it already passes its header/buttons and table header into ListHeaderComponent, but on wide layout it renders that same block before <Table.Body />, so the wide page cannot scroll as one view.

There is also a sticky-header detail to handle carefully: in the pinned FlashList version, stickyHeaderIndices applies to items in the list data, not to nested children inside ListHeaderComponent. If we put both the page header and table header into one list header, we either cannot stick only the table header or we risk sticking the page controls too.

What changes do you think we should make in order to solve the problem?

Add a headerComponent prop to the affected table wrappers for Workspaces, Domains, Categories, and Company Cards, and pass each page's header/actions into the table instead of rendering them beside the body list.

Then update the shared table body so it owns both scroll behavior and sticky table-header behavior:

• Render the page-provided headerComponent as the FlashList header so it scrolls away with the rows.
• Render <Table.Header /> as a dedicated synthetic list item before the real rows, and set stickyHeaderIndices to that item so only the table header sticks.
• Keep search, filters, sorting, empty states, loading skeletons, and row rendering applied to the real table data before adding the synthetic header item.
• Preserve table refs and scroll methods so callers still use row indexes, not the extra internal header row.

For Company Cards, move the header/buttons composition out to the page-provided header prop, but still render it inside the <Table> provider so Table.SearchBar and Table.FilterButtons keep their context. Apply the same wrapper pattern to the Workspaces, Domains, and Categories table wrappers. This is UI-only; no backend or API behavior should change.

What alternative solutions did you explore? (Optional)

Wrapping the whole page in another ScrollView would create nested scrolling with the existing FlashList and would be risky for long tables. Putting the page header and table header together in ListHeaderComponent is also incomplete because FlashList cannot make just one child inside that header sticky. The safer fix is to let the common table own the single list scroll and represent the table header as the sticky list item.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022065394629663983091