Tree-shakeable feature typing dilemma in v9 (react)

[markpfeifle]

I'm currently struggling a bit with the migration from v8 to v9 in a React project. This is related to the newly introduced dependency of the whole typing system on the tableFeatures that have been selected when creating the table instance with useTable.

Background:
We use quite a few reusable components that take e.g. table or column objects as input, interact with the table, column, etc. API(s) and render stuff as a result of these API calls.
There might be a sorting-aware component that uses information about the sorting state of column(s) and a selection-aware component that accesses information about selected rows. These components can then be used for different all kinds of tables that use different sets of features. In the past, typing was easy, because all features were imported by default, so all APIs were always present on each table, column, ... instance.

Problem in the migration process:
When typing e.g. a table input prop of such a component as { table: Table<TFeatures extends TableFeatures, TData extends RowData>}, by default I will not be able to use most of the table API methods, because TableFeatures is pretty bare-bones. That means, I somehow need to narrow the type to make sure typescript understands that the e.g. sorting API methods are available in the component code. At the same time, I don't want to type the table too specifically for a certain set of features because I want to use the component for a table that has e.g. the feature sets {rowSortingFeature, columnVisibilityFeature}, {rowSortingFeature, rowSelectionFeature, columnVisibilityFeature} and all kinds of conceivable feature combinations.

I've tried some typing patterns in the following codesandbox (see file src/SortingAware.tsx): https://codesandbox.io/p/devbox/polished-hazelnut-vktpys?file=%2Fsrc%2FSortingAware.tsx

None of them really works, and my only current workarounds are really nasty type assertions (which sometimes work, sometimes not but can get easily out of hands for complex components). Am I overlooking something really obvious here? What is a clean pattern for achieving safe and consistent typing?

[MLuc24]

The reason none of your patterns work is that this isn't a matter of finding the right constraint. Table<TFeatures, TData> cannot resolve its feature-derived members at all while TFeatures is still an unresolved type parameter.

Reproduced on @tanstack/react-table@9.1.2, TypeScript 5.9.3:

function A<TFeatures extends TableFeatures, TData extends RowData>({
  table,
}: {
  table: Table<TFeatures, TData>
}) {
  return table.store.state.sorting
  //                       ^ Property 'sorting' does not exist on type
  //                         '{} | (TableState_CellSelection & … & TableState_RowSorting)'
}

Look at the type in that error: a union of {} and "every feature's state intersected together". ExtractFeatureMapTypes in packages/table-core/src/types/TableFeatures.ts is a conditional over Extract<keyof TFeatures, keyof TFeatureMap>; with a generic TFeatures it stays deferred, so a property must exist on both arms — and the {} arm has nothing.

That is also why tightening the bound changes nothing:

TFeatures extends TableFeatures & Required<Pick<TableFeatures, 'rowSortingFeature'>>
// identical error

The union comes from the deferred conditional, not from the constraint, so no bound on TFeatures collapses it. Assertions are the only way through that particular door — hence the nastiness you ran into.

There is a second thing worth knowing: useTable does not return Table. It returns ReactTable<TFeatures, TData, TState>, three parameters, and it is not assignable to Table<TFeatures, TData>.

That third parameter is the way out. table.state is typed by TState, independently of TFeatures — so constrain that and leave the feature set free:

import type {
  ReactTable,
  RowData,
  TableFeatures,
  TableState_RowSorting,
} from '@tanstack/react-table'

export function SortingAware<
  TFeatures extends TableFeatures,
  TData extends RowData,
  TState extends TableState_RowSorting,
>({ table }: { table: ReactTable<TFeatures, TData, TState> }) {
  return table.state.sorting // resolved — no assertion
}

Checked against tables with different feature sets:

const small = tableFeatures({ rowSortingFeature, columnVisibilityFeature })
const big = tableFeatures({ rowSortingFeature, columnVisibilityFeature, rowSelectionFeature })

SortingAware({ table: useTable({ features: small, columns, data }) }) // ok
SortingAware({ table: useTable({ features: big, columns, data }) })   // ok

const noSorting = tableFeatures({ columnVisibilityFeature })
SortingAware({ table: useTable({ features: noSorting, columns, data }) })
// Type 'ReactTable<…, TableState_ColumnVisibility>' is not assignable to
// 'ReactTable<…, TableState_RowSorting>'

Any feature set containing sorting is accepted, the ones without it are rejected at the call site, and nothing is asserted — which is what you were after.

For the components that take a column rather than the table, the same principle applies one level down: intersect the feature's contributed type onto the generic one instead of trying to constrain TFeatures.

export function ColumnSortingAware<TFeatures extends TableFeatures, TData extends RowData>({
  column,
}: {
  column: Column<TFeatures, TData, unknown> & Column_RowSorting<TFeatures, TData>
}) {
  return column.getIsSorted()
}

// call site — accepted:
// table.getAllColumns().map((column) => <ColumnSortingAware column={column} />)

Row_RowSelection, Column_ColumnFiltering and friends follow the same naming, so a component needing two features just intersects both.

[V1OL3TF0X]

What about subtyping column definitions, for example? A const cannot take a generic TFeatures, and last I checked, subtyping it with something like Required<Pick<TableFeatures, 'rowSortingFeature'>> does not work for reasons mentioned above. At the same time, from my experiments at least, any type added there makes the column definition unasignable to anything. Should it just be a union of ColumnDef_FeatureName, omitting the generic ColumnDef<TFeatures, TData, unknown>? Or something else?

[reyberyturiaga]

I'm having some challenges migrating an app to v9 too. It's currently running on v8 and using ShadCn components. Because those components are intended to be composed together, there's a deep level of nesting and in order to avoid props drilling from parent to child (and up to grandchildren several levels deep), React's useContext was used to expose useReactTable instance as table const to consuming components. In v8, it was easy to type it because all I needed to do was to use Table<TData> generic but in v9 useTable doesn't return Table<TData> anymore but ReactTable<TFeatures, TData, TSelected> and I'm having a hard time satisfying the correct type. I think TSelected is the culprit for the type shenanigans that is going on.

[davidmateita]

I also had quite some trouble with this typing and I found a bandaid solution and some better approaches for now, I'll share it below in case it helps anyone.

Goal

To create a generic component that accepts table object (and optionally make the RowPaginationFeature required)

Problem 1

Using concrete type for TFeatures breaks component consumers.
In the example below, keep in mind that TableFeatures interface is using Partial, so my TableFeaturesWithRowPagination type should get ANY feature but with RowPagination mandatory.

interface TableFeatures extends Partial<CoreFeatures>, Partial<StockFeatures>, Partial<Plugins> {...}

type TableFeaturesWithRowPagination = TableFeatures &  
  Required<Pick<TableFeatures, "rowPaginationFeature">>;

export function DatatablePagination<TData extends RowData>({  
  table,  
}: {  
  table: ReactTable<TableFeaturesWithRowPagination, TData>; // <- concrete type  
}) {  
  return (  
      /* state is correctly resolved and can select the pagination state */  
    <table.Subscribe selector={(state) => state.pagination}>  
      {(pagination) => (  
		<Pagination  
		  value={pagination.pageIndex + 1}  
		  total={table.getPageCount()}  
		  onChange={(page) => table.setPageIndex(page - 1)} {/* <- table apis are discovered and no issues in typescript */}  
		/>  
      )}  
    </table.Subscribe>  
  );  
}

// in other components
<DatatablePagination table={table} /> {/* <- typescript error */}

This is the typescript error from table in <DatatablePagination table={table} />

Problem 2

Using generic type for TFeatures breaks table object in component definition, the table apis are not discoverable.

export function DatatablePagination<  
    TData extends RowData,  
    TFeatures extends TableFeaturesWithRowPagination,  
>({  
  table,  
}: {  
  table: ReactTable<TFeatures, TData>; // <generic type  
}) {  
  return (  
      /* state is now typed as ExtractFeatureMapTypes<TFeatures, TableState_FeatureMap>, type cannot be resolved  
      
          TS2339: Property pagination does not exist on type                {} | (TableState_RowPagination & TableState_CellSelection & TableState_ColumnFiltering & ... 10 more ... & TableState_RowSorting)                Property pagination does not exist on type {}      */  
    <table.Subscribe selector={(state) => state.pagination}>  
      {(pagination) => (  
		<Pagination  
		  value={pagination.pageIndex + 1}  
		  total={table.getPageCount()} /* <- TS2339: Property getPageCount does not exist on type ReactTable<TFeatures, TData */  
		  onChange={(page) => table.setPageIndex(page - 1)} /* <- TS2339: Property setPageIndex does not exist on type ReactTable<TFeatures, TData> */  
		/>  
      )}  
    </table.Subscribe>  
  );  
}

// in other components  
<DatatablePagination table={table} /> {/* <- now works fine */}

Bandaid Solution

Use generic type to properly resolve table features, then convert it for internal usage to concrete type.

This allows the table object to be passed to the component and it throw errors if RowPagination feature is missing, but also allows for the table apis to be discovered inside the component itself. I am using the same base typescript type TableFeaturesWithRowPagination, so should be ok from type safety pov.

type TableFeaturesWithRowPagination = TableFeatures &
  Required<Pick<TableFeatures, "rowPaginationFeature">>;

// 1. PUBLIC BOUNDARY: Generic constraint for the parent table.
// WHY: Using a concrete type in props forces TanStack's ExtractFeatureMapTypes to
// extract all library features, breaking parent assignment. Generics capture exact features.
export function DatatablePagination<
  TData extends RowData,
  TFeatures extends TableFeaturesWithRowPagination,
>(props: { table: ReactTable<TFeatures, TData> }) {
  
  // 2. INTERNAL BOUNDARY: Cast the generic back to a concrete type.
  // WHY: TypeScript defers mapping on open generics, causing table APIs and state to
  // remain unresolved (returning `{}`). Casting forces evaluation to make APIs discoverable.
  const table = props.table as unknown as ReactTable<TableFeaturesWithRowPagination, TData>;
  
  return (
    <table.Subscribe selector={(state) => state.pagination}>
      {(pagination) => (
		<Pagination
		  value={pagination.pageIndex + 1}
		  total={table.getPageCount()}
		  onChange={(page) => table.setPageIndex(page - 1)}
		/>
      )}
    </table.Subscribe>
  );
}

What I went for instead

I started from useAppContext from createTableHook and had some issues where components would not re-render which turnout out to be from React Compiler rather than the Table Context as I initially thought. The documention mentions that for React Compiler not all table objects are reactive and I was confused about how should I use table.Subscribe since I also want to re-render when row models change and maybe have some way to externally reload the table.

I was afraid of silent failures of components not re-rendering in cases where I may add few states from other features later and forget to add it in all table subcomponents or use a different table object which may not be reactive (ex. useHeaderContext().table instead of useTableContext() if I understood it right). That lead me to going the old v8 approach of components where I wanted to pass the table, row , column objects manually and managing everything myself. This was also a pain and I don't like that bandaid solution duplicated in all components and manually managing rerenders like that.

My current solution is this:

1. disable React Compiler, without it everything re-renders fine and I don't have to fight the memoization and figuring out is reactive and what not
2. remove Subscribe and table.Subscribe that are now unnecessary
3. use createTableHook instead and create table components to prevent fighting against the typing and minimize the prop drilling

export function DatatablePagination() {  
    const table = useTableContext();  
  
    return (  
        <Pagination  
            value={table.state.pagination.pageIndex + 1}  
            total={table.getPageCount()}  
            onChange={(page) => table.setPageIndex(page - 1)}  
        />  
    );  
}

[reyberyturiaga]

Putting my update here too just in case someone else run into this thread. I decided to use createTableHook and refactor my existing provider based approach to hooks based approach as recommended in the docs: https://tanstack.com/table/latest/docs/framework/react/guide/composable-tables. There is a lot more work involved and the major pain point as @davidmateita already mentioned is managing the subscriptions manually due to React compiler not re-rendering table components properly. You basically need to identify specifically which features would need to trigger a re-render for each custom table components you create which is really tedious to do. But honestly, after going through it, I am proud of the results. The code looks much cleaner and reusable. The team really did a fantastic job of making table components more composable in v9!