[Table] upgrade to `@tanstack/table` v9

[miguelrk]

Package

v4.x

Description

TanStack Table has officially released version 9 (announcement blog post). The current implementation of UTable in @nuxt/ui relies on v8, which prevents users from leveraging new features, performance improvements, and updated TypeScript typing provided in v9.

Proposal: Upgrade the underlying @tanstack/vue-table (and related TanStack core table packages) dependency to v9 and update UTable to handle any breaking changes or updated APIs introduced in the new major release.

• Update @tanstack/vue-table / @tanstack/table-core dependencies to v9.x.
• Audit UTable component props, slots, and internals for breaking API changes in TanStack Table v9.
• Update internal table composables and types where applicable.
• Verify test suite and update documentation code examples.

Additional context

No response

[coderabbitai]

🔗 Related PRs

#6731 - feat(vue): support experimental.componentDetection [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Blakeing]

I'd like to take this on — working on a PR to upgrade @tanstack/vue-table / @tanstack/table-core to v9 and update UTable + docs/examples for the breaking API changes.

[benjamincanac]

I'm afraid this will be quite complex to achieve in v4 because of the breaking changes in the exposed tableApi, we might have to wait for v5 🤔

[benjamincanac]

I see this getting some traction and I'm re-thinking my previous statement as it would be a shame to wait for v5 to get this (have absolutely no idea how long it will take to release it).

Maybe we can release this in a minor as a breaking change with a clear migration guide to get things moving. What do you think?

[J0Z14H]

Having the TanStack Table v9 update as part of a minor release breaking change I think would be beneficial.

In the current Nuxt UI documentation, the various links to the TanStack Table documentation currently either route to the latest (v9) documentation or to now broken/missing links. And there isn't a specific mention that Nuxt UI currently uses v8 of TanStack Table.

So I think a breaking minor change now would also provide the opportunity to align Nuxt UI docs with the updated TanStack Table documentation where needed.

Also it may be a good idea to structure links to the TanStack docs as https://tanstack.com/table/v{{versionNumber}}/ to prevent pointing to the wrong TanStack Table release in the future.
(Note: That currently using a version below v8 resolves to the latest docs, but I would assume Nuxt UI probably wouldn't be more than 1 major version of TanStack Table behind at any given time)
(https://tanstack.com/table/v9/ does redirect to https://tanstack.com/table/latest/ and https://tanstack.com/table/v8/ goes to the expected v8 version docs)

[benjamincanac]

@J0Z14H Thanks for the feedback! #6864

[typed-sigterm]

Faster and granular major version updates aren't so bad IMO. (so tanstack table can have 9 major versions since stable) Users that need them can simply check the changelog and upgrade.

[KazimirPodolski]

Nuxt UI definitely should not bound itself to a particular Table version, as the latter is very sporadically maintained, and we need the updates when they finally come. In other words, Nuxt UI release cadence != Tanstack release cadence by quite a big margin.

[benjamincanac]

@KazimirPodolski I agree with the idea but in this case with a library as rich as @tanstack/table I'm not sure I see how we could absorb its breaking changes. UTable exposes the column definitions, the table options, the cell contexts in slots and the whole tableApi, so smoothing over a major would mean maintaining our own table API on top of theirs 🤔

[KazimirPodolski]

maintaining our own table API on top of theirs 🤔

Welp, I guess in a world of 13 "standard" rich table APIs you can only invent one more.

[khangln-amv]

I mean... the current table doesnt have feature parity with v8 anyway, resizable column, for example