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.

[xkomiks]

@KevinVandy can you pay attention to this and #4754?

[step2341]

@KevinVandy I'm having this issue also. I have a scenario now where i require user defined columns, but also need to persist the column order and allow the user to rename the column. if you use the accessor only, and the user renames the column, the order gets destroyed because a column of that name no longer exists. To get it working, on column creation I assign GUID as the ID to each column, that way the GUID persists and its always unique. This also allows the user to copy columns and generate a scenario where 2 columns can have the same name.

So everything works except for warning:
"Property 'accessorKey' does not exist on type 'ColumnDef<TData, unknown>'.
Property 'accessorKey' does not exist on type 'ColumnDefBase<TData, unknown> & StringHeaderIdentifier'.ts(2339)"

adding the accessor key as an optional type per above would fix this issue.

[step2341]

has anyone found a fix for this? @ScripterSugar @KevinVandy @xkomiks. still an annoying issue..

[slhsxcmy]

Hey guys, I just found this issue that seem related to an issue I created: #5423. I have this PR that I think solves the problem #5424, let me know what you think : )

[slhsxcmy]

Should be fixed in v8.15.2 by PR #5424

If you have let col = columnHelper.accessor('some_property', { ... }), you can use col.accessorKey without type error

[mshahzebraza]

@slhsxcmy I'm using v8.16.0 and the issue still persists.

[KevinVandy]

This was fixed only for when you accessing the column inside the column helper column defs. In other places, you shouldn't try to access accessorKey. Just use the column id as intended.