ngx-datatable makes no assumptions about your data, which moves filtering and paging into your code

No external dependencies is the constraint everything else follows from

The pitch is stated in one sentence and then repeated in the feature list as Light codebase / No external dependencies.

That constraint rules out a lot of what tables usually bundle. There is no theme framework, no grid engine, no state library, no date adapter. Installing it is a single npm command:

npm i @swimlane/ngx-datatable --save

The feature list says the component has all the features you would expect from any other table but in a light package with no external dependencies.

The consequence shows up in theming. The list says decoupled theme'ing with an included Google Material theme, and decoupling a theme without a theme framework means writing your own CSS against the component's class names, with one bundled theme as a starting point rather than as the mechanism.

The other visible consequence is AoT Compilation Support in the feature list. A component with no runtime reflection and no external services to resolve compiles ahead of time, which is what makes it usable in an Angular application that has turned AOT on.

Universal support is listed too, which was the phrase for server-side rendering in that generation of Angular.

So the dependency count is not an accident of packaging. It is the design constraint, and the features listed are the ones achievable without pulling anything else in.

It refuses to own your data, so filtering, sorting and paging are your code

This is the most consequential line in the README and it is easy to skim: the table was designed to be extremely flexible and light, and it doesn't make any assumptions about your data or how you filter, sort or page it.

The feature list confirms the consequence. Client/Server side Pagination & Sorting are both offered, which only makes sense if the component is not deciding which one applies. Your rows array is the source, and if it is a full in-memory array the component paginates and sorts locally, and if it is a slice from a server the component tells you which page or sort it wants and you supply it.

The same applies to filtering, which is not in the feature list at all. A component that makes no assumptions about how you filter leaves the filter to your own inputs and your own predicate, which means a search box above the table is your code rather than a property binding.

So the trade is explicit. You get a well-tested rendering layer, virtual DOM scrolling, column pinning and row detail views, and you give up a data layer. If your data is genuinely local and modest, that is a good deal. If you expected a grid to manage a query for you, it will not.

Integrating filtering means writing the predicate yourself and passing rows in, which is also why the demos matter more here than the API list.

Large data sets are handled by the virtual DOM, not by paging alone

The first item in the feature list is Handle large data sets, and the parenthetical says Virtual DOM.

That is the rendering strategy, and it is separate from pagination. Virtual rendering means only the rows in view exist in the DOM, so a table with tens of thousands of rows scrolls without creating tens of thousands of elements. Combined with Horizontal & Vertical Scrolling and Fixed AND Fluid height, it is what makes the component viable for data volumes that a naive table cannot take.

The sizing features are the pair around it: Intelligent Column Width Algorithms with two named behaviours, Force-fill and Flex-grow. Those are automatic column sizing modes rather than fixed pixel widths, and they are the answer to a problem most tables punt on, which is what happens when the viewport changes and the columns do not.

Column Reordering & Resizing is separate again, since users dragging a column boundary is a different problem from the component choosing widths initially.

Left and Right Column Pinning is the feature that tends to matter most in practice, because a table with a dozen columns is unusable when the identifier column scrolls off screen. Pinning first and last columns is the kind of thing you either need on day one or never.

Row Detail View is the other one: an expanded row per record, which turns a table into a list of nested views without a second screen.

Header and cell templates carry the customisation burden

Expressive Header and Cell Templates is listed second among the features, and with no external dependencies it is the main extension point.

Angular templates are the mechanism, so what you can put in a cell is limited by what you can render, which is a large set. The consequence is that cell rendering performance is your problem rather than the component's, and a template that runs a function per cell for every visible row is exactly the pattern virtual rendering does not protect you from.

Selection is the feature list's counterpart: Cell & Row Selection with four named modes, Single, Multi, Keyboard, and Checkbox. Keyboard selection in particular implies focus and key handling inside the table, which is the kind of behaviour that has to be tested against your own row content rather than assumed.

Integrated Pager is listed as its own item, so the pager is a component of the table rather than something you build from a separate paginator.

Together these describe a component that renders and interacts but does not fetch, filter or persist. Everything about the data lifecycle around the table is yours.

The publish path runs the full check suite before anything ships

The package scripts reveal the release mechanics, and they are stricter than the README's own checklist suggests.

The publish chain is layered. `publish` calls `publish:lib`, which runs `npm publish ./dist/swimlane/ngx-datatable`. That is guarded by `prepublish:lib`, which runs `yarn ci` and then `yarn package`. And `yarn ci` is `yarn lint && yarn prettier:ci && yarn test:ci`.

So linting, a prettier check and the CI test configuration all have to pass before a version reaches the registry. The test script is split too: `test` is `yarn lint && yarn test:unit`, while `test:unit` is `ng test @swimlane/ngx-datatable --watch=false`, and `test:ci` uses a separate ci configuration.

The README describes a simpler thing by comparison. Its release section is a manual checklist: checkout master, pull, `yarn install --frozen-lockfile`, run tests, examine the log to determine the next version, branch as release/X.Y.Z, update the version in projects/swimlane/ngx-datatable/package.json, update docs/CHANGELOG.md, run `yarn package`, commit, tag, push with tags, publish, submit a PR.

Note that the README's list omits the lint and prettier gates that the scripts enforce, and it does say to run tests, so read the scripts rather than assuming the checklist is complete.

The build writes to dist/swimlane, while the package is scoped @swimlane

There is a naming detail in the scripts that will cost you an afternoon if you do not expect it.

The build target is `ng build @swimlane/ngx-datatable --configuration production`, and everything downstream writes into `dist/swimlane/ngx-datatable`. The copy step copies the changelog, README and LICENSE into that directory, copies assets from src/assets into `dist/swimlane/ngx-datatable/assets`, and copies themes from `projects/swimlane/ngx-datatable/src/lib/themes/` into `dist/swimlane/ngx-datatable/themes`.

The CSS step then runs scss-bundle with a configuration file and sass over the same directory. And the pack and publish targets both target `./dist/swimlane/ngx-datatable`.

So the on-disk output path is scoped-like while the published package name carries the scope, and there is a scss-bundle.config.json at the root to make the theme compilation reproducible.

The release checklist also tells you where the version lives: the version to bump is in projects/swimlane/ngx-datatable/package.json, not the root package.json. The root manifest identifies itself as ngx-datatable at version 0.0.0, which is the application and workspace rather than the published artifact.

If you are forking this, that path structure is the first thing to get right.

Playwright and an eslint config migration are visible in the tree

The top-level listing shows a repository that has been modernised in pieces, and the mismatches between old and new are informative.

There is both an .eslintrc.js and an eslint.config.mjs, and both .prettierrc.json and prettier.config.js. That is a migration in progress rather than a finished state, and it means lint behaviour may differ depending on which file your tooling picks up.

Testing shows the same pattern from the other direction. There is a playwright/ directory and an e2e/ directory, while the README describes running yarn test as executing the linter, prettier check, unit and end-to-end tests. The package scripts show an `e2e` target wired to `ng e2e`, which is the older Angular end-to-end runner, alongside the newer Playwright directory.

Documentation is built by Angular as well. `build-docs` runs an ng build in production mode with a base href of /ngx-datatable/, and deploy-docs uses angular-cli-ghpages against the dist output, which is what publishes the demos site.

There is also book.json at the root, which is a GitBook configuration, matching the gitbook-hosted documentation link in the README alongside the demos site and a docs directory with the changelog.

Security.md and .codeclimate.yml are both present, and the badge row at the top of the README points at Code Climate for both the main badge and coverage.

Editorial conclusion

ngx-datatable fits an Angular team that wants a table with server side paging, column pinning and row detail views without adding a dependency that also brings a theme, a grid engine and its own opinions about your data shape. It does not fit someone who wants a batteries-included grid with built-in editing, or a team still on an old Angular major, since the newest tagged releases are 4.x from 2016 and 2017 while the last commit was 2026-08-11. Before upgrading, read the changelog rather than the version number, run yarn test before publishing since it gates the publish script, and check the build output path, because the package scripts write to dist/swimlane/ngx-datatable while the npm package is scoped as @swimlane/ngx-datatable.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. swimlane/ngx-datatable on GitHub