TypeScript thinks that accessorKey is not an accessible property when column is defined with createColumnHelper

[jacksonblankenship]

Describe the bug

When I describe columnDefs via the createColumnHelper api, TypeScript informs me that accessorKey is unavailable. But when I console log the contents of the defined columns, accessorKey is very clearly available.

Your minimal, reproducible example

https://codesandbox.io/s/tanstack-react-table-accessorkey-issue-v68163

Steps to reproduce

1. Run the codesandbox
2. Examine the typescript issue on line 22
3. Examine the rendered content and the console log

Expected behavior

As a user, I expect to be able to access accessorKey without typescript issues when defining my columns via the createColumnHelper API, but typescript doesn't think the field exists or is available

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

  System:
    OS: macOS 12.5.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 182.22 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.17.1 - ~/.nvm/versions/node/v16.17.1/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.17.1/bin/yarn
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.1/bin/npm
  Browsers:
    Chrome: 105.0.5195.125
    Safari: 15.6.1
  npmPackages:
    @tanstack/react-table: 8.5.15 => 8.5.15 
    react: 18.0.0 => 18.0.0 
    typescript: ^4.6.2 => 4.8.3

react-table version

8.5.15

TypeScript version

4.8.3

Additional context

No response

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct
• I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

[Tushara710406]

any updates on this issue

[karedas]

Same problem here

[Tushara710406]

My project is purely typescript basis.. I am unable to use the new version of react table. we are using old version react-table but for some features we want to upgrade it ...

[jonahallibone]

+1 Same issue here

const [columnVisibility, setColumnVisibility] = useState(
  columns.map((column) => ({ [column.accessorKey]: true }))
);

Property 'accessorKey' does not exist on type 'ColumnDef<DataType, DataType[string]> | ColumnDef<DataType, DataType[number]> | ColumnDef<DataType, DataType[symbol]>'.
  Property 'accessorKey' does not exist on type '{ footer?: ColumnDefTemplate<HeaderContext<DataType, DataType[string]>> | undefined; cell?: ColumnDefTemplate<CellContext<DataType, DataType[string]>> | undefined; meta?: ColumnMeta<...> | undefined; } & ... 6 more ... & StringHeaderIdentifier'.ts(2339)

[KevinVandy]

The intent with this is that you are supposed to access the id property instead of accessorKey in a ColumnDef. The accessorKey value gets copied over to id internally. I guess we could add accessorKey as a optional type, but it's not guaranteed to be present if an accessorFn is used instead.

[nik-lampe]

We're trying to wrap our column Definitions into a wrapper that creates a translated title for the columns based on the resource the table is holding.

I don't want to pass the resource all the way through to the table instance, so we thought we just run the column definitions that we created through a mapping function.
In this we set the header to a translated version or the next best thing available. Something like this:
col => col.header || ${resource.name.plural}.fields.${col.id || col.accessorKey} || col.id || col.accessorKey || ''

In this case it would be sufficient to have the accessorKey as an optional type, but with it being absent the typechecking fails.

[xkomiks]

@KevinVandy

The intent with this is that you are supposed to access the id property instead of accessorKey in a ColumnDef. The accessorKey value gets copied over to id internally. I guess we could add accessorKey as a optional type, but it's not guaranteed to be present if an accessorFn is used instead.

Actually it looks like a bug because #4754

Idea to add accessorKey to ColumnDef as optional parameter looks good

[ScripterSugar]

The intent with this is that you are supposed to access the id property instead of accessorKey in a ColumnDef. The accessorKey value gets copied over to id internally. I guess we could add accessorKey as a optional type, but it's not guaranteed to be present if an accessorFn is used instead.

This is not current behaviour. When I console log header.column.columnDef.id it just says undefined even if accessorKey is present in the column definition. It's either bug in the id getter or accessorKey should be listed as optional parameter.

[tushar-rupani]

Did you guys come up with a solution?

In my case, when I access some of my columns, such as "column.name," it gets converted to "column_name" by the id field. However, I need to access "column.name" because I need to perform some calculations based on it.

[ScripterSugar]

@tushar-rupani I just ended up using meta field.

[tushar-rupani]

@tushar-rupani I just ended up using meta field.

I just tried using header.column.columnDef.meta and it returned undefined. Would that be possible for you to share a snippet of your code?

[tushar-rupani]

@tushar-rupani I just ended up using meta field.

Quick Update: Thank you for your help, I was able to solve this using Meta. (:

[Tushara710406]

Using version of 8.5.13 which is not throwing any errors

[ScripterSugar]

I'm using 8.9.4 and the issue remains still.

[carstenblt]

This should be available as an optional field. The data is there.