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 😃

[EOEboh]

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

[henry61024]

Just went across this discussion for the v10 roadmap. Thanks for the sharing!

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.

Does this mean that in v10, it will no longer be possible for one feature to depend on another?

In our use case, we enhance a shared custom table instance API across multiple features. This might sound unconventional, but it's incredibly powerful.
For example, we created a getXXXProps API (like cell.getCellProps), which is enhanced across difference features. Each feature will contribute its own properties to the return value of the getProps function. This allows callers to always use the same getProps function to receive fully calculated props, regardless of which features they are using.

It would be great if v10 still allows features to depend on each other in some way, as this could unlock various possibilities.

[KevinVandy]

You will still be able to use all features

[henry61024]

That's awesome, thanks for the clarification!

[henry61024]

Another question came to my mind.

Regarding the upcoming v9 release with React compiler support, will there be significant breaking changes to both the built-in and customized features?

Additionally, I'm curious about how the React compiler will be supported. Are there any documents or code examples that I could dive into?