TanStack Table V9 and V10 Roadmap and Future

[KevinVandy]

Roadmap

The previous discussion was a draft for brainstorming potential TanStack Table v9 features. This discussion is more of an official plan for moving forward with the future of TanStack Table. Outside Help and Collaboration from developers like you may be wanted/needed in order to ship these ideas as soon as they potentially can be.

Update: some things that were being saved for v10 should now make it into V9.

We may be able to release 2 new versions of TanStack Table within the next year or so.

V9

• A release focused on internal restructuring of how features are applied with better tree shaking and newer build configs.
  • new build configs with newer build targets - ES2020+ should result in slightly smaller bundle sizes
  • new minimum peer Dependencies with better support for
    • React (Compiler) (Will most likely still support React 17+ or even React 16.8+, though if USES is required React 18+ may be minimum)
    • Svelte 5 (May only support Svelte 5 and up)
    • maybe Qwik 2 (Truly better Qwik support may not arrive until TanStack Table v10, more to come)
  • New "required" _features table option and TFeatures generic. In order to use features in TanStack Table, you will need new simple imports for the features you actually want to use. The code for the features you don't use won't have to be included in the bundle anymore.
  • The static functions that create each underlying feature will also be available as standalone static functions imports, though the builder pattern from the table instance will still be encouraged.
  • Move row model table options to their own section _rowModel section, similar to _features
  • Some smaller API breaking changes and renames will occur here too, but will be kept to a minimum.
  • Unify API design with TanStack Query and TanStack Form as much as possible
    • New tableOptions util for better sharing of common table options
      • (This replaces the plan for a tableFactory that once being copied from TanStack Form v0's now deprecated formFactory
    • Rename use/create[Framework] hooks/functions again! i.e. useReactTable -> useTable

V10

• A potentially very large update to TanStack Table with much better tree shaking, TypeScript type inference, and more features.
  • New state management with @tanstack/store solutions by default. (Subscribable state sliced?) - Could move up to v9
  • Refactor major built-in features
    • Column Filtering refactor to allow for much more complex filters out of the box. (And/Or logic, multiple filters per column, etc.)
    • Grouping/Aggregation refactor to allow for more aggregation scenarios. (Multi-agg per column, much more to be rethought here)
  • More Features! With better tree shaking, we'll be able to include more official TanStack Table features without having to worry too much about how the bundle size will impact everyone anymore. Some new features could include
    • Built in accessibility helpers for setting roles and aria attributes. (almost like bringing back v7's getHeaderCellProps, etc.
    • Keyboard shortcuts for focusing on active cells, etc.
    • Pivot Tables! (This is a large complex feature that could be shipped later in V10's lifetime)
    • More can be considered.
  • Custom _features -> plugins refactor. The way the internal interfaces and types are being refactored for v10 may not allow for the custom _features that were added to v8 in the same way. We may want to create a dedicated _plugins table option for 3rd party features.
  • Much, much more internal unit and type testing with a new internal static function architecture. The new refactor for how features are defined internally should allow for unit tests to be created much more easily.

Here is what using TanStack Table v10 could look like:

const table = useTable({
  _features: { ColumnFiltering, RowSorting }, //imported features
  _rowModels: { FilteredRowModel, SortedRowModel }
  columns,
  data,
  ...options
)}

The table instance would only have options and APIs for the features that you specify, so if you are only using a subset of table features, your bundle will be much lighter. You will also have much fewer APIs and table options to have to comb through in your TS hints and suggestions, making the DX a bit more friendly for beginners, or when your making simpler tables.

For those who don't care about this new "_feature", there will be a simple allFeatures export available to simplify the upgrade.

The way you currently call table, row, cell, etc. APIs while building your markup would remain almost exactly the same. No major rethinking there. The same builder pattern for all APIs on the table, row, cell, column, and header instances would remain the same.

How can you help?

If you want to help update the framework adapters to be more compatible with your favorite framwork, we can still use help with that for v9.

Work on V10 is also underway, and will require a lot more work. This would be a great thing for others to help with. Much of the work needed is going to be well-defined repetitive refactoring. Please reach out to me if you are interested in contributing your time.

Expertise on TypeScript, TypeScript performance, and JavaScript performance in general will also be very welcome during this period.

The End Goal

The end goal of these roadmaps is to get TanStack Table to be the most versatile, yet small and stable table library out there. Whether you are building a very basic table, or an extremely complex table that needs tons of customizable logic and UI, TanStack Table should be the first choice you think of.

[EOEboh]

I love the well defined proposal. This is an awesome library I’ve been using even at work. Where do we start from 😃

[KevinVandy]

The V10 POC branch is here: https://github.com/TanStack/table/tree/kevins-alpha

I should document all what needs to be done soon. It boils down to refactoring all "feature" code to be defined as static functions instead of referencing the table instance APIs internally.

For example instead of calling table.getPreFilteredRowModel() in the column_getFacetedRowModel function, we'll call the table_getPreFilteredRowModel function that will be defined statically.

Why? Because this will start to make all features not dependent on each other. All features will will automatically import and use the code they need. This will allow developers to only import the ColumnFiltering feature, for example, without worring if the Pagination feature is a pre-req dependency.

Also all code is being refactored with the TFeatures extends TableFeatures generic. I'm guessing this will be confusing to anyone looking to help that is not familiar with the codebase, but this is what will eventually drive the next-level TypeScript experience.

I don't expect the code in this branch to be able to compile successfully without TS errors for a bit as the refactor happens. But anyone who is willing to help is welcome.

Anyone else who's interested in coordinating development, we should probably do it on the discord. Feel free to discuss here first.

[EOEboh]

No, it's fine, I don't need to know the codebase to understand what you are trying to explain.
What exactly is being prioritized? V9 upgrade or V10 full upgrade?

I'd appreciate the discord link too

[KevinVandy]

same as its linked on Tanstack.com: https://discord.com/invite/WrRKjPJ

[KevinVandy]

There is obviously a priority on v9. It's just that outside of getting it to work better with the React 19 compiler and Svelte 5, there's not many hard issues there. The development of v10 will take a lot of dev work.

[EOEboh]

Got it. I’ll be on the lookout for your documentation of what needs to be done