TanStack Table V9 Roadmap #5270

KevinVandy · 2024-01-12T05:14:31Z

KevinVandy
Jan 12, 2024
Collaborator

TanStack Table V9 Roadmap

This is the first draft of ideas for what a TanStack Table V9 could look like. V9 does not have to have that many breaking changes (though there inevitably will still be some), but there are new paradigms that we could introduce that could give you the option to use TanStack Table in a new way that may use significantly less bundle size.

We can, of course, just keep improving TanStack Table V8 with new features, bug fixes, better docs and examples (and we will!), but there are some architecture changes that we could introduce that could unlock untapped potential in TanStack Table, warranting an investment in a full V9 release.

Down below, we will list ideas for new features and improvements that we could make to TanStack Table. If some of these ideas are able to be introduced without breaking changes, we can ship them in a V8.x release. If they require breaking changes, we can ship them in a V9 release.

Not all of these ideas will make it into V9. Some of these ideas may just be experimental, and we'll make considerations based on community feedback. If you have additional ideas you would like to be discussed here, feel free to add to the discussion down below, but please try to offer realistic solutions that should be core to the library.

1. Statically Defined and Importable API Functions and Core Hooks

This a proposal for a new "core" way to use TanStack Table that could have a bundle size starting as low as 2-3kb, while still allowing you to use all of the TanStack Table features that you need.

The useReactTable, useVueTable, createSvelteTable, createSolidTable and createTable hooks/functions would be unchanged, but new lightweight "core" versions of these hooks would be introduced with no built-in feature APIs.

Click to expand core proposal

Consider how the row models already work in V8, or how the old feature hooks worked in V7. If you want to add features like client-side filtering, pagination, grouping, etc. You have to import those feature's respective row models.

import {
  getCoreRowModel,
  getPaginationRowModel,
  useReactTable,
} from '@tanstack/react-table';

const table = useReactTable({
  columns,
  data,
  getCoreRowModel: getCoreRowModel(),
  getPaginationRowModel: getPaginationRowModel(),
  // etc...
});

This is already great, as we are only adding the code for rendering the rows that we actually need. If you're table does not need filtering or pagination, you don't have to import those row models, and they won't be included in your bundle. This already saves you up to ~20% of the projected 16kb bundle size of TanStack Table V8. But we can do better.

With the remaining ~80% of the core code, we could be loading just the code for the feature APIs that your table needs.

Internally, the code for loading all of the feature code looks like this:

const features = [
  Headers,
  Visibility,
  Ordering,
  Pinning,
  Filters,
  Sorting,
  Grouping,
  Expanding,
  Pagination,
  RowSelection,
  ColumnSizing,
] as const;

features.forEach((feature) => {
  //connect feature code to the core table instance
});

All of these features are hard coded into the table core, and are 1-2kb in size, each. Even if you never plan on using row selection features, there will still be row selection APIs and code in your bundle.

Now with a maximum of 16-18kb, this is not really a huge deal for most people. But if we want to have room to grow these features and handle more edge cases without having to worry so much about bundle size, we have a few options.

One option for TanStack Table v9 would be to remove all built-in feature APIs from the core table instance.

What? Why?! ...Let me explain.

This line of thinking is inspired by another library recently introduced to the TypeScript ecosystem, Valibot

Valibot is a competitor to the popular library Zod. It does pretty much the same thing as Zod, but while Zod is a 13kb library, Valibot claims to be a "< 1kb Zod Alternative".

Valibot mostly does this by making you import every function that you want to use, instead of providing every imaginable API on a core object with the builder patter. For example, instead of:

import { z } from 'zod'; // 13kb z object with all APIs on it
const schema = z.object({
  email: z.string().email().endsWith('@example.com'),
});

You would do:

import { email, endsWith, string } from 'valibot'; // <details 1kb pure functions
const EmailSchema = string([email(), endsWith('@example.com')]);

So, what if we introduced the same pattern to TanStack Table? Instead of:

//TanStack Table V8
import {
  flexRender,
  getSortedRowModel,
  useReactTable,
} from '@tanstack/react-table';

const table = useReactTable({
  columns,
  data,
  getSortedRowModel: getSortedRowModel(),
  // etc...
});

return (
  <table>
    <thead>
      {table.getHeaderGroups().map((headerGroup) => (
        <tr key={headerGroup.id}>
          {headerGroup.headers.map((header) => (
            <th key={header.id} colSpan={header.colSpan}>
              {header.isPlaceholder ? null : (
                <div
                  {...{
                    className: header.column.getCanSort()
                      ? 'cursor-pointer select-none'
                      : '',
                    onClick: header.column.getToggleSortingHandler(),
                  }}
                >
                  {flexRender(
                    header.column.columnDef.header,
                    header.getContext(),
                  )}
                  {{
                    asc: ' 🔼',
                    desc: ' 🔽',
                  }[header.column.getIsSorted() as string] ?? null}
                </div>
              )}
            </th>
          ))}
        </tr>
      ))}
    </thead>
    <tbody>
      {table.getRowModel().rows.map((row) => (
        <tr key={row.id}>
          {row.getVisibleCells().map((cell) => (
            <td key={cell.id}>
              {flexRender(cell.column.columnDef.cell, cell.getContext())}
            </td>
          ))}
        </tr>
      ))}
    </tbody>
  </table>
);

You would do:

//TanStack Table V9 (hypothetical)
import {
  useReactTableCore, //core instead of useReactTable
  flexRender,
  getTableHeaderGroups,
  getHeaderContext,
  getTableRowModel,
  getRowVisibleCells,
  getCellContext,
  getCanColumnSort,
  getToggleSortingHandler,
  getIsColumnSorted,
} from '@tanstack/react-table';

const table = useReactTableCore({
  columns,
  data,
  // etc...
});

return (
  <table>
    <thead>
      {getTableHeaderGroups({ table }).map((headerGroup) => (
        <tr key={headerGroup.id}>
          {headerGroup.headers.map((header) => (
            <th key={header.id}>
              {header.isPlaceholder ? null : (
                <div
                  {...{
                    className: getCanColumnSort({
                      column: header.column,
                      table,
                    })
                      ? 'cursor-pointer select-none'
                      : '',
                    onClick: getToggleSortingHandler({
                      column: header.column,
                      table,
                    }),
                  }}
                >
                  {flexRender(
                    header.column.columnDef.header,
                    getHeaderContext({ header, table }),
                  )}
                  {{
                    asc: ' 🔼',
                    desc: ' 🔽',
                  }[
                    getIsColumnSorted({
                      column: header.column,
                      table,
                    }) as string
                  ] ?? null}
                </div>
              )}
            </th>
          ))}
        </tr>
      ))}
    </thead>
    <tbody>
      {getTableRowModel({ table }).rows.map((row) => (
        <tr key={row.id}>
          {getRowVisibleCells(row).map((cell) => (
            <td key={cell.id}>
              {flexRender(
                cell.column.columnDef.cell,
                getCellContext({ cell, table }),
              )}
            </td>
          ))}
        </tr>
      ))}
    </tbody>
  </table>
);

This does not even look like that much of a radical change, but it theoretically takes this from being ~14kb to ~2-3kb. (TBD on the actual numbers). That's a potential 6x or 80% reduction in bundle size for simple use cases.

Now I want to point out, that we want to introduce as few breaking changes as possible. I think that the current useReactTable, createSvelteTable, createSolidTable, useVueTable and createTable hooks/functions should retain all of their current APIs. But we could introduce a new useReactTableCore, createSvelteTableCore, createSolidTableCore, useVueTableCore and createTableCore hooks/functions that would be the new way to use TanStack Table.

How are we going to accomplish this?

The @tanstack/table-core package is going under a significant refactor. All API functions are being refactored to be statically defined functions that consume table, column, row, cell, etc. instances and perform the state mutations that they need to or return the output that they need. These functions will be importable from whichever framework adapter package that you are using.

TanStack Table will then offer 2 ways to create a table instance:

One where all APIs will be hooked up in the core table instance so that you can continue to use the builder pattern like you have in previous versions of TanStack Table.
One where none of the APIs will be hooked up in the core table instance, and you will have to import the APIs that you need from the framework adapter package.

What about TypeScript?

Getting the TypeScript types to work perfectly with all of this is still a work in progress, but promising. More to come on this. We won't ship anything that is not a leading TypeScript experience.

2. Make Extending TanStack Table with Custom Features Easier

As mentioned in the previous section, the current TanStack Table features are all hard coded into the core table instance. We can make it easier to add custom features/plugins to TanStack Table.