AdaptTable v3 is live: a framework-neutral engine, smaller feature imports, and optional AI

In my last AdaptTable update, I wrote about how much the project had grown by v2.9.

By then, AdaptTable already had grouping, tree data, pivoting, editing, exports, virtualization, responsive layouts, and a lot more.

That growth created a different problem.

I didn't want every table to carry the weight of every feature, and I didn't want React itself to define the engine underneath the library.

v3 is the release where I cleaned that up.

React is no longer the engine

AdaptTable is still built for React developers today, and the same idea remains: use the UI kit already in your project instead of bringing in a table with a completely different look and feel.

What changed is the architecture underneath it.

Framework-neutral models and table operations now live in @adapttable/core.

React-specific hooks and subscriptions live in @adapttable/react.

The adapters then handle the actual UI for Mantine, MUI, Chakra UI, Ant Design, Radix Themes, Base UI, shadcn/ui, and the unstyled/Tailwind route.

Roughly:

@adapttable/core
        ↓
@adapttable/react
        ↓
Mantine / MUI / Chakra / Ant / Radix / Base UI / shadcn / unstyled

The engine no longer needs to know how React subscribes to state, while the React layer only handles the React-specific binding around the table logic.

It gives AdaptTable a cleaner foundation for other framework bindings later.

Vue and Angular bindings are not part of v3. The engine is ready for that direction, but React is still the shipped framework binding today.

Optional features are actually optional now

v2 had already started moving features behind separate import paths.

But there was still a problem.

A feature can have its own public subpath and still end up in the main dependency graph if the root DataTable imports its implementation internally.

So an import can look modular without really being a bundle boundary.

In v3, the old feature-enabling props are replaced by feature factories.

A basic table can stay basic:

import { DataTable } from "@adapttable/mantine";

<DataTable
  data={rows}
  columns={columns}
  rowKey={(row) => row.id}
/>;

If that table needs grouping, it adds grouping:

import { DataTable } from "@adapttable/mantine";
import { grouping } from "@adapttable/mantine/grouping";

<DataTable
  data={rows}
  columns={columns}
  rowKey={(row) => row.id}
  features={[grouping("team")]}
/>;

The same approach is used for editing, virtualization, row reordering, column menus and other optional features.

For applications that want the common controls together, there is still a convenient preset:

import { standardFeatures } from "@adapttable/mantine/preset";

So you can start with the preset for the common setup, or import individual features when you want a narrower table.

In practice, the bundle cost follows the features your table actually uses.

AI follows the same AdaptTable philosophy

v3 also adds @adapttable/ai.

I didn't want AI support to mean choosing a specific model provider, SDK or agent architecture just to use the table.

The AI layer is separate from the normal table packages.

A table exposes only the operations it actually supports. If editing is not enabled, the agent does not get editing tools. If a write needs approval or an application callback, it still has to go through that path.

The application keeps control of authorization, validation, and persistence.

There is a ready-made assistant UI, but it is optional. The same capabilities can also be connected to an existing chat interface or agent runtime.

This follows the same idea as the UI adapters: AdaptTable should work with the stack already used by the application.

AdaptTable has its own provider-neutral session and capability contract, and it also ships adapters for AI SDK and AG-UI, alongside integrations for OpenAI tools, MCP, and lower-level JSON.

So an application can keep its existing provider, backend, and agent setup instead of rebuilding around AdaptTable.

And like the rest of v3, AI is opt-in. If you never import the AI packages, the normal table does not depend on them.

I'll cover capability discovery, revisions, approvals, execution results, and the boundary between the agent, table, and application in a separate post.

Moving from v2

v3 is a major release, so there are breaking changes.

React-specific hooks that previously came from @adapttable/core move to @adapttable/react.

The old feature-enabling props are replaced by feature factories.

Deprecated routes and aliases that were being kept around for compatibility are removed.

The CLI can help with supported import migrations, but I would still review application behavior after upgrading. A codemod can move an import; it can't decide how your application wants editing, persistence, or a custom feature to behave.

The v2 → v3 migration guide covers the changes and replacements.

AdaptTable remains MIT licensed.

You can try the live demo, read the documentation or browse the source on GitHub.