ka-table: a React data grid with editing, filtering and grouping built in

One element, and a list of features that are all props

ka-table describes itself as the customizable, extendable, lightweight and fully free React table component, and the repository description is more specific about the feature set: Sorting, Filtering, Grouping, Virtualization, Editing and many more.

That list is the pitch, because every item on it is a thing a data grid usually needs and most of them are a separate library in a normal project. The library site is at ka-table.com, there is a docs page at ka-table.com/docs_get_started.html, and the demos are published as a browsable application at the project's GitHub Pages site, with one demo page per feature, such as the delete-row demo the README links. The README carries a Coveralls badge for coverage, which tells you the project reports its test coverage rather than leaving it unstated.

The licence is MIT, the primary language is TypeScript, the default branch is master, and the last push was on 2026-10-19.

What is notable is the shape of the API rather than the size of the feature list. There is one component, Table, and the capabilities are configured through props and through enums imported from a dedicated subpath. A team that wants sorting, filtering and inline editing in one place has a single dependency here rather than a grid framework plus a state library plus an export library plus a date picker integration.

The basic example shows the whole API surface

The README's example is short, and it is worth reading closely because it exposes the conventions.

Installation is a single package in either package manager:

npm install ka-table

yarn add ka-table

The example imports the component and, separately, the enums that configure it:

import { Table } from 'ka-table';
import { DataType, EditingMode, SortingMode } from 'ka-table/enums';

That split is a design decision rather than a convenience. The enums live in their own module path, so a consuming application imports the values it needs to configure behaviour without pulling in the component's internals, and the values are named rather than stringly typed, which means the configuration is checked by the compiler.

The props themselves then follow one pattern. Each column is an object with a key, a title and a data type, and the data is a plain array of objects:

      columns={[
        { key: 'column1', title: 'Column 1', dataType: DataType.String },
        { key: 'column2', title: 'Column 2', dataType: DataType.String },
      ]}

And the behaviour is chosen by named modes rather than by boolean flags:

      editingMode={EditingMode.Cell}
      rowKeyField={'id'}
      sortingMode={SortingMode.Single}

The rowKeyField is the one prop with no default that you will always need, because a grid has to know which field identifies a row in order to edit it, sort it and select it. The example data is a ten-row array built with a map, each row carrying four columns and an id.

The modes are expandable: EditingMode.Cell is the narrowest of the editing options, and SortingMode.Single is one end of the sorting range, which is where the grouping, filtering and virtualization features of the description come in.

The dependency list is the feature list again

The package.json dependencies tell you what the component is made of, and they explain most of the feature claims.

The rendering is Material UI, @mui/material at ^7.0.2 with @mui/x-date-pickers at ^8.1.0 for date input, styled through @emotion/react and @emotion/styled. So the table looks like a Material Design component, which is the single most important fact for anyone choosing a grid, because it means the grid inherits the look and the behaviour of the rest of a Material application rather than shipping its own design system.

State and data come from react-redux at ^9.2.0 and react-query at ^3.39.3, so the table can be connected to a store and can fetch its own data. The export features are visible in the dependencies as well: react-csv for comma separated output, jspdf with jspdf-autotable for PDF, and react-to-print for printing. There is bootstrap at 5.3.5 and date-fns at ^4.1.0 for date handling, lodash.orderby for the ordering behind the sorting and grouping, and lorem-ipsum, which is the demo data generator and is a sign that the demo site ships inside the package.

Two things in that list are mild smells rather than faults. The @types packages, for enzyme, react, react-csv and react-redux, are listed as runtime dependencies rather than dev dependencies, which pulls type definitions into the installed tree of every consumer. And react-query is still on the 3.x line while react-redux is on 9.x, so the two state-related dependencies are a generation apart.

React itself is at 19.1.0 with react-dom beside it, and the peerDependencies field is the interesting bit, because it allows ^16.8.3, ^17, ^18 and ^19. The component therefore claims to work across four React generations, which is generous and useful, and it is also a promise that only the newest of them has been exercised by the last release.

The build is a hybrid of react-scripts, tsc and gulp

The scripts reveal a project that uses more than one build system, which is normal for a library that also ships a demo site.

The start, build and test scripts are react-scripts start, react-scripts build and react-scripts test, with test:all and test:coverage as variants, and there is an eject script. That is a Create React App based setup, which is what the demo application in public/ is built with, and it is also where the coverage run and the coveralls upload come from.

The library build is different. The dist script compiles the library entry point with the TypeScript compiler, using --declaration to emit type declarations and --esModuleInterop, and then runs a gulp build. The compile script does the same thing with a different target, --target es5, and --skipLibCheck. The pack script runs the gulp build, changes into the dist directory, runs npm pack and changes back, which is how the tarball that ends up on the registry is produced.

So there are three build paths in one manifest: react-scripts for the demo, tsc for the declaration output, and gulp for packaging. The presence of a gulpfile.js in the repository root confirms that gulp is still a live part of the toolchain rather than a leftover.

The eslintConfig extends react-app, and the lint scripts run eslint over src with a fix variant, so linting is the same tool the demo uses.

The linting migration is visible in the file list

The top-level listing is small and shows a project in the middle of a cleanup.

There is a .eslintrc.js, which is the current lint configuration, and a tslint.json, which is the previous one. Next to it is tslint-to-eslint-config.log, the output log of the tool that converts a tslint configuration into an eslint one. That log file is a development artefact that was committed, and it is the clearest evidence in the repository of a linting migration that was run and then partly tidied up.

Otherwise the listing is what you would expect from a TypeScript React library: src/ for the code, public/ for the demo application, a .github/ directory for workflows, a .travis.yml from the earlier continuous integration era, a .vscode/ directory, CONTRIBUTING.md, LICENSE, README.md, package.json, tsconfig.json and a yarn.lock. The lockfile being yarn while the README offers both npm and yarn for installation is a small inconsistency, and publishBuild.js sits next to the build scripts for whatever the publishing step needs.

The documentation is in three places rather than one. The README covers installation and a basic example, the docs site at ka-table.com holds the getting started guide, and the demo application on GitHub Pages is where the features are shown in action, one page per feature. For a component library, having the demos be real pages with real URLs is worth more than any amount of prose, and the README links into them throughout.

Version numbers, and what the release titles say about the work

The version story needs two numbers, and they do not match.

The manifest in the repository is at 12.0.3. The newest published release is 12.0.2, whose title is Use react v19.0, update all dependencies to the latest version, dated 2025-04-24. So the working version is one ahead of the last tag, which is the normal state of a repository between releases, and it means the version you get from npm is not the version in the tree.

Before that, two feature releases landed on the same day, 2024-09-26. Version 11.2.0 added isDraggable to disable Drag&Drop for specific column, and 11.3.0 added an IsNotEqual filter operator to the Filter Row. Both titles are specific and both are exactly the kind of small ergonomic additions a table library accumulates, and together they tell you what the maintainer spends time on: per-column control over drag and drop, and a richer filter vocabulary.

The React 19 move in 12.0.2 is the more consequential of the three, because a table component touches every row, every cell and every event handler, and a major React version changes how children are rendered and how effects behave. A maintainer taking that on and shipping a dependency refresh alongside it is doing the unglamorous half of library maintenance.

The last push was on 2026-10-19, so the tree is active even though the newest release is from April 2025. There is no changelog file in the repository listing, so the release titles on the platform are the record of what changed, which is thinner than most maintainers of a twelve-version library would like.

Editorial conclusion

Adopt ka-table when you need an editable data grid quickly and your team already lives in Material UI, because the whole feature set is driven by props on one element and the styling comes from MUI rather than from a parallel design system you would have to adopt. Do not adopt it if you need a grid that is fully headless and unstyled, since this one renders Material components and ships bootstrap in its dependency list, and check the peer range before you install, because the package declares support from React 16.8 through 19 while the bundled React 19 is what the last release was tested against. Before you commit, compare the version in package.json with the tag you would install, since the manifest is at 12.0.3 while the newest release is 12.0.2, and read the release titles, because the two most recent feature changes were filter operators and per-column drag control, which tells you what the maintainer is working on.

Frequently asked questions

Official sources

1. komarovalexander/ka-table on GitHub
2. License: MIT
3. Project website
4. README
5. Releases