Add new prop to ignore deep nested accessorKey

[davidyeiser]

We’re using TanStack/table in our React project and it works great. The documentation is easy to follow and the feature set is wonderful. Much thanks to those who have worked on it!

I've run into a situation where it seems the “best” option is adding a small, new feature.

Situation

We have data in our product that is submitted as JSON and we provide a table view on top of that data. There is no enforced schema on the JSON data and it also varies in size (a file may be 1kb or 100MB).

At times, the JSON data will have object keys with dots in them, but they are just names and have no association with how to access the data. For example, something like this:

"coefficients": {
  "L(region)[S.Arkansas]": -0.2426,
  "L(region)[S.Maine]": 1.4330,
  "L(region)[S.Nebraska]": -1.8150,
  "L(region)[S.Florida]": 0.5839
}

The tables are built dynamically and the accessorKey is defined by the object property. So the accessorKey for the first column in the data above would be L(region)[S.Arkansas] but the lookup fails as expected because of the . that is present.

One option would be to run all the object properties keys through a sanitation function, but I don’t really want to add extra processing when the data is on the large end.

Proposed

The new feature would be adding an optional ignoreDeepNested property (or whatever the best name for it would be) that could be passed to the Column Definition and if true the data accessor function would ignore the dot notation and just treat it as a flat string lookup.

I ran a quick test locally and it seemed feasible with minimal changes, but I could be missing some things. Here are the changes I made:

table-core/src/core/column.ts

export interface CoreColumn<TData extends RowData, TValue> {
  ...
  /**
   * If true, the dot notation in the accessorKey property will be ignored and treated as a regular string for an object property lookup.
   * @link [API Docs](https://tanstack.com/table/v8/docs/api/core/column#ignoredeepnested)
   * @link [Guide](https://tanstack.com/table/v8/docs/guide/column-defs)
  */
  ignoreDeepNested?: boolean;
  ...
}

...

  if (resolvedColumnDef.accessorFn) {
    accessorFn = resolvedColumnDef.accessorFn
  } else if (accessorKey) {
    // Support deep accessor keys
    if (accessorKey.includes('.') && !resolvedColumnDef.ignoreDeepNested) {
    ...

I updated the AccessorKeyColumnDefBase type in table-core/src/types.ts and then I added this quick test to run locally:

it('should access row data with object properties with dots when ignoreDeepNested is active', () => {
  const data = [
    {
      "name.first": 'Hattie',
      "name.last": 'Bosco',
    }
  ]
  const columns = [
    { id: 'name.first', accessorKey: 'name.first', ignoreDeepNested: true },
    { id: 'name.last', accessorKey: 'name.last', ignoreDeepNested: true },
  ]

  const table = createTable<Person>({
    enableRowPinning: true,
    keepPinnedRows: false,
    onStateChange() {},
    renderFallbackValue: '',
    data,
    state: {
      pagination: {
        pageSize: 5,
        pageIndex: 1, //pinned rows will be on page 0, but this is page 1
      },
      rowPinning: {
        top: ['0', '1'],
      },
    },
    columns,
    getPaginationRowModel: getPaginationRowModel(),
    getCoreRowModel: getCoreRowModel(),
  })

  const result = table.getRowModel().rowsById["0"].getValue("name.first")

  expect(result).toBe("Hattie")
})

It passes when ignoreDeepNested: true is present, and fails when it’s not.

[davidyeiser]

If anyone wants to try it out: https://www.npmjs.com/package/react-table-with-skip-accessor-key-dot-notation

Use when defining table headers:

{
  accessorKey: "example.with.dots",
  header: "Example",
  ignoreDeepNested: true,
}

Data like so:

{
  "example.with.dots": "data"
}

Would output:

Example
data

[KevinVandy]

Funnily enough, we're most likely just removing accessorKeys entirely in the next version in favor of just accessorFns, so this won't be a problem anymore

[davidyeiser]

Do you have a general idea of how it would work with v9? I looked at accessorFn but it seemed like it was for a different use case

[KevinVandy]

accessorFns let you deal with the data however you want. If you have nullish data, you should already choose to be using that in v8.