tableMeta / columnMeta slots can't see the table's TData

[tomerzcod7]

We moved our app to v9 and every table goes through one createTableHook. The tables have different row types, and most of them want the same thing from table meta: an onRowClick(row) with the row typed for that table.

The tableMeta slot from #6316 looked like the right place for it. Thanks for that one, it's been asked for since #4220, #4646 and #4739. What I can't figure out is how to write the slot so it knows which table it ends up on:

interface AppTableMeta {
  onRowClick?: (row: Row<typeof features, ???>) => void
}

const features = tableFeatures({ rowSortingFeature, tableMeta: metaHelper<AppTableMeta>() })
const { useAppTable } = createTableHook({ features })

The slot type is fixed when tableFeatures() runs and ExtractTableMeta returns it as is, so nothing fits in ???. RowData means every handler casts before row.original.name compiles. any lets row.original.nmae through. And Person ties the features object to the people table, which defeats the shared hook.

For now we fall back to v8-style declaration merging, since the global TableMeta does get TData:

declare module '@tanstack/react-table' {
  interface TableMeta<TFeatures extends TableFeatures, TData extends RowData> {
    onRowClick?: (row: Row<TFeatures, TData>) => void
  }
}

That works, but it's global, so every table in the project gets these keys, and the meta guide recommends the slots over it anyway. ColumnMeta has had TData and TValue since #4145 / #4208, which leaves the slots as the one place you can't reach them.

What I'd propose is letting a slot optionally be a type-level function that the library applies to each table's TData. With the this-typed interface pattern it's a few lines in table-core, and no public type gets a new generic:

export interface TableMetaFn {
  readonly TData: unknown
  readonly meta: object
}

type ApplyTableMeta<TMeta, TData> = TMeta extends TableMetaFn
  ? (TMeta & { readonly TData: TData })['meta']
  : TMeta

// in ExtractTableMeta, the slot branch returns ApplyTableMeta<TMeta, TData> instead of TMeta

Plain object slots resolve exactly like they do today. In an app it looks like this:

interface AppTableMetaShape<TData extends RowData> {
  onRowClick?: (row: Row<typeof features, TData>) => void
}
interface AppTableMeta extends TableMetaFn {
  readonly meta: AppTableMetaShape<this['TData'] & RowData>
}

const features = tableFeatures({ rowSortingFeature, tableMeta: metaHelper<AppTableMeta>() })
const { useAppTable } = createTableHook({ features })

useAppTable({ data: people, columns: personColumns, meta: { onRowClick: (row) => row.original.name } }) // Person
useAppTable({ data: invoices, columns: invoiceColumns, meta: { onRowClick: (row) => row.original.total } }) // Invoice
useAppTable({ data: people, columns: personColumns, meta: { onRowClick: (row) => row.original.nmae } }) // error

Reading it back works too. table.options.meta?.onRowClick?.(row) is typed with that table's Row<typeof features, Person>.

columnMeta could do the same with TData and TValue, which gets you things like a per-column formatter typed by the accessor's value:

export interface ColumnMetaFn {
  readonly TData: unknown
  readonly TValue: unknown
  readonly meta: object
}
// ExtractColumnMeta applies (TMeta & { readonly TData: TData; readonly TValue: TValue })['meta']
// when TMeta extends ColumnMetaFn

interface AppColumnMetaShape<TValue> {
  format?: (value: TValue) => string
}
interface AppColumnMeta extends ColumnMetaFn {
  readonly meta: AppColumnMetaShape<this['TValue']>
}

columnHelper.accessor('age', { meta: { format: (age) => age.toFixed(0) } }) // age: number

I tried all of this against 9.3.1's published types, with ExtractTableMeta and ExtractColumnMeta patched in a local copy, going through createTableHook, useAppTable and createAppColumnHelper on TS 5.9 and 7.0. Correct handlers compile, typos and wrong row types are errors, columnHelper.columns([...]) still takes the columns, and plain object slots behave as before. The slots are already type-only, so nothing changes at runtime.

I'm not sure how you feel about a this-typed interface in the public API, and I'm open to a different encoding if you'd rather. The check is also structural, so an object slot that happens to have both a TData and a meta key would be read as a function. A branded unique symbol key would avoid that if you prefer it.

If the direction works for you, I'm happy to open a PR with the types, type tests next to tests/unit/core/table/metaTypeSlots.test.ts, and a short section in the meta guide.