DEV Community: Orwa Mahmoud

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

Orwa Mahmoud — Sun, 20 Sep 2026 13:16:09 +0000

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.

From v1 to v2.9: how AdaptTable grew into a full React data-grid toolkit

Orwa Mahmoud — Thu, 03 Sep 2026 19:44:50 +0000

Back in July I wrote the first post about AdaptTable.

The project was still v1, and the idea was fairly focused: one table engine that could sit behind the UI kit a React project already uses.

MUI project? Use the MUI adapter.

Mantine? Use Mantine.

Ant Design, Chakra, Radix, shadcn, Base UI, or your own Tailwind styles all sit on the same engine too.

That model is still there. The engine behind it has just grown a lot since then.

The core is at v2.9 now.

GitHub · Live demo · Getting started

The feature set got much bigger

The first release already covered the things I kept needing in application tables: sorting, filtering, pagination, URL state, saved views, column controls, server-side data, mobile layouts, selection, and row/card virtualization.

Since then I've added quite a bit on top of that.

Grouping now supports multiple levels and aggregates.

There is tree data, pivot tables, formula/computed columns, and sparklines.

The editing side grew a lot too.

AdaptTable now has keyboard cell navigation, rectangular range selection, clipboard copy/paste, cut, fill handle behavior, and edit history.

Editing can happen at cell level, row level, or as batched changes. There is validation, async validation, dirty-state tracking, and conflict handling for cases where live data changes while somebody is editing.

Rows have more control now as well:

Row reordering
Top and bottom row pinning
Row and column spanning
Full-width rows
Custom row heights and styling
Tree and nested structures

Export also moved beyond CSV and print, with XLSX and PDF support now available.

Keeping the feature API manageable

As the feature set grew, I wanted a basic table to stay basic.

A normal table can still look like this:

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

v2 introduced a feature composition API for optional behavior.

For example, row reordering can be added through its own entry point:

import { DataTable } from "@adapttable/mantine";
import { rowReorder } from "@adapttable/mantine/row-reorder";

<DataTable
  data={rows}
  columns={columns}
  rowKey={(row) => row.id}
  features={[
    rowReorder(handleReorder)
  ]}
/>

Grouping, editing, virtualization, cell navigation, saved views, and other features follow the same direction.

There is also a public TableFeature API behind this. A feature can register its own editors, aggregators, commands, filters, menu items, panels, and other extensions through the same feature system.

That gives me a cleaner way to keep expanding AdaptTable without turning every new capability into another permanent special case inside DataTable.

Some of the heavier code is already separate

I also started splitting heavier capabilities into their own entry points instead of exporting everything from the main core package.

Today the core has separate entries for things like:

@adapttable/core/xlsx
@adapttable/core/pdf
@adapttable/core/formula
@adapttable/core/pivot
@adapttable/core/stream
@adapttable/core/sparkline

Those are outside the main core entry, so the application pays the bundle-size cost for those features only when it imports and uses them.

The adapters have feature-specific entry points too. Mantine, for example, exposes paths such as:

@adapttable/mantine/row-reorder
@adapttable/mantine/grouping
@adapttable/mantine/editing
@adapttable/mantine/virtualize
@adapttable/mantine/cell-navigation

v2 still keeps some optional feature implementations reachable from the main DataTable import graph, so the adapter side doesn't get the full bundle-size benefit from those entry points yet.

v3 will move those optional implementations out of the root import graph so applications only pay for the features they actually import and use.

The deprecated v2 APIs will be removed at the same time.

The server side changed a lot too

The original TableSource idea is still there: the table can work with local data or with data controlled by a backend.

That area has expanded quite a bit.

There is now a separate @adapttable/server package for parsing and validating AdaptTable query state on the server.

Pagination, sorting, filters, filter trees, grouping, and pivot state can use the same table query model on both sides instead of needing a second representation just for the backend.

Real-time updates are in now too.

AdaptTable can consume row patches coming through WebSocket or SSE flows instead of reloading the entire dataset whenever something changes.

The live-update work also connects with editing. A remote update can arrive while somebody is changing the same row locally, so those two parts of the table need to understand each other.

There is support for SSR, React Server Components, and streaming as well.

A lot of the work after v1 ended up happening around the data flow and lifecycle of the table, not only in the rendered grid.

Eight adapters, one engine

The public adapters today are:

Mantine
MUI
Chakra UI
Ant Design
Radix Themes
Base UI
shadcn/ui
unstyled/Tailwind

They all use the same underlying table state and feature logic while rendering with the components and conventions of their own UI stack.

A Mantine project gets Mantine components. An MUI project gets MUI components. A project with its own design system can use the unstyled path.

The core behavior stays shared across them.

Everything is still MIT licensed.

v3 is next

While working on v2, I kept running into one thing I want to fix properly in v3: too much of the engine is still tied to React.

A lot of what AdaptTable does has nothing inherently React-specific about it.

Sorting, filtering, grouping, pivots, formulas, query state, editing state, row models, and feature logic can all exist without React.

For v3 I'm moving that logic into framework-neutral engine modules, with React hooks and components living in a separate binding layer.

React will remain fully supported, but it won't define the architecture of the engine underneath it.

That also opens the door to Vue and Angular integrations later without rebuilding the same table logic for each framework.

v3 will also remove the deprecated v2 APIs and continue the bundle cleanup by moving optional feature implementations out of the root import graph.

I'm also working on optional AI capabilities for v3.

I Stopped Treating Long AI Coding Runs Like Chats — Nightshift Now Treats Them Like Shifts

Orwa Mahmoud — Wed, 02 Sep 2026 16:28:10 +0000

A while ago I wrote about a problem I kept hitting with Claude Code: I could give it a large task, walk away, and come back later to find that it had stopped somewhere in the middle.

That problem is what originally pushed me to build Nightshift.

At first, the goal was mostly:

How do I keep the agent working?

Once I got the agent to reliably work for hours, my focus shifted.

The problem was no longer just keeping it alive. I started focusing on improving the shift itself:

If I leave a coding agent working for several hours, how do I make that run something I can actually understand, trust, review, recover, and keep as history afterward?

That changed how I think about long-running agent work.

I don't really want a six-hour conversation.

I want a shift.

The shift should exist outside the chat

The core idea in Nightshift is:

The work contract and run state live on disk, not only in the conversation.

During a shift, I want to be able to open the files and see:

what is done
what is being worked on now
what is still open
what is parked or blocked
what decisions were made
what was tried and rejected
what still needs verification

The conversation is still useful for instructions, reasoning, and following the work as it happens. But for a multi-hour shift, I don’t want it to be the only place that remembers what was agreed, what changed, what failed, and what is still left.

That becomes especially important when context gets compacted, a session fails, or I come back the next morning and need to understand what happened without scrolling through one giant chat.

Two kinds of shifts

Nightshift currently supports two main ways of working.

1. Planned shifts

You define the work up front as a concrete feature plan.

For example:

[ ] build the Products module
[ ] add product categories
[ ] add coupons and discount rules
[ ] add inventory tracking
[ ] add product search and filters
[ ] audit the whole module end-to-end and make sure every backend flow has the required UI and works correctly
[ ] add tests and verification

Each item can have its own quality or verification requirements, and/Or you can also define checks that apply to the whole shift.

The shift keeps working until every contracted item is ticked off. Owner-defined quality checks describe what “done” should mean, but the model decides when an item is ready to tick. Nightshift tracks that state and mechanically prevents the model from clocking out while anything is still open. Whether the work is actually good enough is still for the human reviewer to decide.

2. Open-ended shifts

This mode became one of my favorite parts of Nightshift.

Instead of giving it a fixed checklist, I give it:

a goal + a strict time budget

For example:

Improve this product for the next four hours.

The agent can inspect the product, codebase, history, tests, existing issues, comparable approaches, technical debt, UX problems, or other useful opportunities.

It finds useful work, ranks it, works on the strongest opportunities, and then keeps going.

If it finishes one thing early and tries to stop while meaningful time is still left, the shift pushes it to continue exploring and improving until the time budget is actually over.

The stopping condition becomes less:

"The model feels finished."

and more:

"The shift is over."

A side effect I ended up liking a lot

This created a use case I didn't originally build Nightshift for.

Sometimes my Claude, Codex, or Cursor usage is going to reset the next day, and I still have a chunk of allowance left.

Maybe I don't have a feature prepared.

Maybe nothing is currently planned on the timeline.

Maybe I just have a few hours of usage that are going to disappear anyway.

Instead of wasting that capacity, I can start an open-ended shift and say:

You have three hours. Find useful work and improve the project.

Nightshift keeps the model working within that time budget instead of letting it finish one small task and stop after 20 minutes.

So the ready-made and open-ended shifts also give me a way to spend otherwise-expiring usage usefully when I don't already have anything planned.

Ready-made shifts

You don't always need to design the shift yourself.

Nightshift also has a catalog of reusable shifts for things like:

defect hunting
test coverage
quality debt
dependency upgrades
codebase review
Product Evolution

For example, Product Evolution is an open-ended shift that studies the product, its history, user needs, and relevant standards, ranks opportunities by evidence, value, effort, reversibility, and risk, then works on the strongest ones within the available time.

The catalog is useful when I know I want to spend a few hours of agent time productively but don't have a detailed backlog ready.

Longer term, I want this catalog to grow beyond my own workflows.

If someone has a long-running workflow that consistently works well, it should be possible to turn that into a reusable shift that other people can install, customize, and contribute back.

And I don't think those shifts necessarily need to be coding-only.

Recurring workflows like SEO, research, audits, or other reviewable agent work can fit the same model too.

I didn't want to build another agent runtime

This became an important design decision as Nightshift grew.

I don't want Nightshift to replace Claude Code, Codex, or Cursor.

Those tools already have their own ecosystems, commands, skills, hooks, capabilities, and ways of working.

Nightshift is designed to augment those ecosystems, not sit in front of them as another agent platform.

There is no Nightshift cloud service or account.

You don't need another npm CLI or Homebrew-installed orchestration runtime that proxies the agent.

Claude Code should still feel like Claude Code.

Codex should still feel like Codex.

Cursor should still feel like Cursor.

Nightshift adds the shift contract, state, enforcement, recovery, review, and archive layer around them.

Long-running doesn't just mean "keep looping"

There are already good ideas for keeping agents working for a long time.

Ralph-style loops, for example, already established patterns around persistent plans, specs, repeated iterations, and state that survives outside a single chat.

So Nightshift isn't trying to claim that file-backed plans or long-running loops are new.

The part I'm interested in is the accountability around the run:

what exactly was contracted
what is still unfinished
what quality bar applies
what decisions were made
what got blocked
what failed
what was verified
whether the session died
how it recovered
what evidence exists afterward

Keeping an agent running for six hours is useful.

Being able to understand what actually happened during those six hours is much more useful.

Recovery should survive the agent itself

Another part I didn't want to trust only to prompting was recovery.

If the process doing the work is also the only thing responsible for noticing that it died, that isn't very helpful.

Nightshift therefore has an external watchman.

For example, if a Claude Code session hits a structured API failure such as:

API Error: 500

the watchman can keep attempting to recover the recorded conversation when the API becomes available again.

For Codex, the watchman can recover a session once it is proven dead, preferring the recorded session when its identity is resumable. If that isn't possible, the on-disk contract still provides the handoff for a fresh recovery.

Failures will happen.

The goal isn't to pretend they won't.

The goal is that a temporary API or session failure doesn't silently throw away the remaining hours of work.

The shift doesn't disappear when it ends

This is one of the parts I appreciate more the longer I use Nightshift.

When I want to file away finished work, Nightshift can archive the completed part of the shift.

Nightshift moves completed items, handled snags, and the rotated journal into a dated archive. Receipts are copied into the dated archive too, while the live copies stay in place.

The active contract and any still-open work stay intact instead of being filed away as if they were finished.

Over time, those dated archives become a much cleaner history of previous shifts.

The original conversation might be thousands of lines long, but the archive gives me a short, structured record of what was completed, what decisions were made, what went wrong, and what evidence was left behind.

So instead of reopening an old marathon chat and trying to reconstruct what happened, I can open the archive for that date and understand the shift much faster.

Even a shift I decide not to merge can leave useful history.

Maybe the implementation wasn't good enough, but the investigation found something important.

Maybe an approach failed, and I don't want the next agent rediscovering the same dead end.

Maybe a decision needs to be revisited later.

That history is worth keeping.

Read the receipts, not the promise

The direction I'm pushing Nightshift toward is pretty simple.

I don't want the final handoff to just be:

"Done! Everything looks good."

I want to be able to inspect the actual state, diff, commits, verification, decisions, failures, and receipts myself.

Long-running autonomy becomes easier to trust when you don't have to trust the agent's summary of its own work.

Read the receipts, not the promise.

Where Nightshift is now

Nightshift is open source under MIT and currently supports:

Claude Code
OpenAI Codex
Cursor

It runs locally and is designed to augment those tools rather than replace them.

The project is still evolving, especially around reusable shifts, stronger review workflows, and making the same model useful beyond coding.

But the basic idea has become pretty clear to me:

Give the agent a real shift instead of one enormous chat.

Define the work or the time budget.

Keep the state outside the conversation.

Keep it working while the shift is active.

Recover when things fail.

Keep the evidence.

Archive the result.

Then review what actually happened.

Nightshift

If you're already leaving coding agents working unattended for hours, I'd be especially interested in the workflows you've found that consistently work well.

Some of them might make good reusable Nightshift shifts.

Why Claude Code Stops Halfway Through Long Tasks—and the Harness I Built to Keep It Moving

Orwa Mahmoud — Tue, 28 Jul 2026 17:08:23 +0000

I kept giving Claude Code long task lists, stepping away, and coming back to find it had completed the easy parts and stopped before the difficult ones.

Sometimes it was worse.

Claude would work until 2 AM, ask one non-critical question, and then sit idle for six hours until I woke up at 8.

The question was usually reasonable, but it was not truly blocking. Claude could have chosen a safe default, continued working, and left the decision for me to review later.

That is a harness problem, not only a model problem. The layer around the agent loop decides what “done” means, when the run may stop, and what happens when human input is unavailable.

That problem led me to create Nightshift, an open-source reliability harness plugin for long unattended Claude Code sessions.

Update (v0.6, July 2026): the night the API died

Since publishing this, the other overnight killer got its fix. Claude had elevated errors across multiple models one evening — API Error: 500, 529 Overloaded — right as I was about to start an overnight run. That is the failure no prompt can fix: once a session dies on an API error, nothing inside it can restart it. And I was not going to sit up watching status.claude.com.

nightshift now ships a night watchman — a small process outside the session that wakes every 10 minutes and reads only the session's own signals: its transcript, its recorded process, Claude Code's session roster. A session that died — or one wedged with an API error as the transcript's last word — gets claude --resume fired into the same conversation, and the watchman keeps knocking until the API answers. Esc or Ctrl-C always wins: it revives the endings nobody chose, never the ones you did. In the morning the whole night is one thread — the error, the revival, the finished work — with a direct link back to it.

Full details: the nightshift site · GitHub repo

Keeping the task outside the conversation

Nightshift uses a persistent Markdown punch list as the source of truth.

# Nightshift Punch List

- [ ] Add rate limiting
- [ ] Add tests for failed login attempts
- [ ] Update the API documentation
- [ ] Run the full test suite

Claude works through the list one item at a time.

Because the work is stored in a file rather than only inside the current context window, the session can recover after context compaction, interruption, or restart.

Preventing quiet early exits

Nightshift includes a stop hook that checks the punch list whenever Claude tries to finish.

If unchecked items remain, the normal stop is blocked and Claude is instructed to continue.

The shift ends only when:

every item is completed
the deadline is reached
an optional stall limit is reached
or the owner explicitly stops it

If no stall limit is configured, stalled work stays held and visibly flagged rather than quietly clocking out.

This is stronger than simply prompting Claude to “continue until finished” because the completion condition is checked against persistent state.

Non-blocking questions should not stop the night

Most human-in-the-loop systems pause the agent whenever it has a question.

That makes sense for destructive or high-risk decisions. It does not make sense for every naming choice, implementation preference, or reversible decision.

During a Nightshift session, non-blocking questions are parked with the default Claude chose.

## Parking Lot

- Question: Should the endpoint return 200 or 201?
- Default used: 201, matching the existing creation endpoints.
- Review later: Confirm API consistency.

Claude continues working, and the developer reviews those decisions in the morning.

The goal is not to remove human oversight. It is to make some of that oversight asynchronous instead of forcing the whole session to wait.

Guardrails for unattended work

Long-running autonomy needs clear boundaries.

Nightshift can mechanically enforce restrictions such as:

blocking git push
denying dangerous commands
protecting selected directories
checking diffs for secret-like content
enforcing a specific Git identity
preventing non-blocking questions from pausing the shift

A prompt saying “do not push” is helpful.

A hook that rejects git push is stronger.

These guardrails are not a security sandbox, but they reduce the risk of relying only on the model to remember every instruction.

Verification before completion

A checked box is still a claim made by the agent.

Nightshift cannot guarantee that the implementation is correct or replace code review. What it can do is enforce a more disciplined workflow:

implement the change
run the relevant verification
inspect the result
commit the completed item
mark the checkbox complete

Verification can include commands such as:

npm test
npm run lint
npm run typecheck

Nightshift also encourages one commit per completed item, making the run easier to inspect or partially revert.

Resumability and receipts

Nightshift stores operational state inside .nightshift/, including punch lists, parked questions, logs, deadlines, stop signals, and completion snapshots.

This state can have its own local Git history, separate from the main project repository.

That gives the developer two different records:

project commits showing what changed
Nightshift receipts showing what happened during the run

If the session is interrupted, a new session can inspect the same state and continue from the remaining work.

What Nightshift does not solve

Nightshift does not eliminate hallucinations.

It does not guarantee that:

every completed item is actually correct
tests cover every requirement
every chosen default is good
every unsafe command will be detected
a poorly written task list will produce a good result

It adds persistence, constraints, verification habits, resumability, and visibility around Claude Code.

Human review is still required.

Installation

Inside Claude Code:

/plugin marketplace add orwa-mahmoud/nightshift
/plugin install nightshift

Then initialize it inside your project:

/nightshift:setup

Review the generated punch list and start the shift:

/nightshift:start

Overview and FAQ:

Nightshift — Accountable autonomous engineering shifts

Give coding agents a durable punch list, safety rules, recovery, and a reviewable morning handoff.

nightshift.orwamahmoud.com

Nightshift is free, open source, and MIT licensed.

Contributions, issues, and feedback are welcome:

https://github.com/orwa-mahmoud/nightshift

One headless table engine, every React UI kit

Orwa Mahmoud — Sat, 04 Jul 2026 08:06:43 +0000

Every React project reaches for a data table eventually, and the choice always feels like a trap:

Reach for ag-Grid or MUI X DataGrid and you get power — but their look, their DOM, and (for the good features) their license.
Reach for TanStack Table and you get total freedom — but now you build every cell, header, filter, and pagination control from scratch.
Reach for a kit-specific table (Mantine, Chakra, Ant) and you're locked to that one kit, re-learning a new API each time.

I wanted one table that renders natively in whatever UI kit a project already uses, with the same features everywhere, and a headless escape hatch when the defaults aren't enough. So I built AdaptTable.

One API, real native components

The whole table is five lines:

import { DataTable, useFrontendData, type ColumnDef } from "@adapttable/mantine";

const columns: ColumnDef<Person>[] = [
  { key: "name", header: "Name", accessor: (r) => r.name, sortable: true },
  { key: "email", header: "Email", accessor: (r) => r.email },
];

function People({ rows }: { rows: Person[] }) {
  const source = useFrontendData({ data: rows, columns });
  return <DataTable source={source} columns={columns} rowKey={(r) => r.id} />;
}

Swap the import for @adapttable/mui, @adapttable/chakra, @adapttable/antd, @adapttable/radix, @adapttable/shadcn, or @adapttable/unstyled — same props, different kit.

The key part: it is not a wrapper that looks the same everywhere. Each adapter renders that kit's actual components — MUI gets Material elevation, Ant gets Ant's compact density, Chakra gets Chakra's tokens. Same behavior, native skin. Flip the switcher in the live demo and watch one dataset re-render through each kit: https://orwa-mahmoud.github.io/adapttable/demo/

Filters and state that live in the URL

My favorite part: open the filter drawer, set a status and a date range, copy the link — whoever opens it sees the exact same view. Search, filters, sort, and page all serialize into query params (q, page, f_status, …), so every view is refresh-safe, back/forward-safe, and shareable. No useState juggling, no wiring: declare the filters and the URL sync comes with them, identically for client-side data and server-side fetching (there's a router adapter for Next.js and react-router).

What you get for free

Sorting, filtering (with removable chips), global search
Row selection + bulk actions
Column management — show/hide, reorder, pin (sticky), resize
Pagination — numbered or infinite scroll, auto by device
Shareable URL state + saved views
First-class RTL / Arabic and dark mode
Optional virtualization — a 10k-row list mounts ~24 DOM rows
Client-side data and server-side (you supply the fetch) through one contract

Headless when you need it

Under every adapter is @adapttable/core — a headless engine with prop-getters (getTableProps, getRowProps, …). If the batteries-included adapter isn't enough, drop down and render your own markup on the same engine. You never hit a wall.

What it's not

No pivoting, grouping, or Excel-style editing yet— this is for the CRUD tables most apps ship, not analytics grids. If you need those, ag-Grid is the right tool.

Try it

Try it in your browser (no install): https://stackblitz.com/github/orwa-mahmoud/adapttable/tree/main/starters/mantine
Live demo (flip the kit switcher): https://orwa-mahmoud.github.io/adapttable/demo/
Docs: https://orwa-mahmoud.github.io/adapttable/getting-started/
npx @adapttable/cli init
MIT, stable v1 (1.1 just brought every adapter to full feature parity): https://github.com/orwa-mahmoud/adapttable

Feedback very welcome — especially whether the per-kit rendering holds up in your stack, and how the declarative API feels next to what you use today.