AG Grid Community

AG Grid Community is the open-source, MIT-licensed edition of AG Grid, a feature-rich data grid used to render, sort, filter, and edit large tabular datasets in the browser. It ships as a plain JavaScript library with dedicated wrappers for React, Angular, and Vue, so teams can drop it into whichever framework they’re already using without rewriting grid logic per platform.

The Community edition covers the core feature set expected of a modern data grid — column sorting and filtering, in-place cell editing, drag-and-drop column reordering, CSV export, infinite/client-side row models, theming, and accessibility support — while more advanced capabilities like row grouping, pivoting, Excel export, and integrated charting are reserved for the commercial AG Grid Enterprise package, which lives in the same monorepo. Because both editions share the same core engine and module system, upgrading from Community to Enterprise is a matter of adding modules rather than switching libraries.

What You Get

• A dependency-free core grid engine (ag-grid-community) usable from plain JavaScript, plus framework packages (ag-grid-react, ag-grid-angular, ag-grid-vue3) that wrap it for each ecosystem
• A modular architecture (allCommunityModule.ts and per-feature modules like ClientSideRowModelModule, CsvExportModule, PaginationModule) so you register only the features you use and keep bundle size down
• Built-in sorting, multi-column filtering (text, number, date, custom), in-place cell editing with multiple editor types, and drag-and-drop column reordering out of the box
• Client-side and infinite row models for handling anything from small in-memory datasets to large virtually-scrolled tables without writing your own virtualization logic
• Theming via prebuilt themes (Alpine, Balham, Material, Quartz) or CSS custom properties, with light/dark variants shipped as separate stylesheets
• CSV export, aligned grids (keeping multiple grids in sync), and a documented public API surface (GridApi) for programmatic control of the grid after it’s rendered

Common Use Cases

• Rendering large tabular datasets (thousands to hundreds of thousands of rows) in admin panels, back-office tools, and internal dashboards where a plain <table> doesn’t scale
• Adding spreadsheet-like inline editing to a React, Angular, or Vue app without building custom cell-editing state management
• Building financial, inventory, or HR data screens that need dense, sortable, filterable grids with export-to-CSV
• Starting on the free Community tier and later enabling AG Grid Enterprise modules (row grouping, pivoting, charts) in the same codebase without migrating to a different grid library

Under The Hood

Architecture The grid is built around a bean-style dependency-injection container (src/context/context.ts, AgCoreBeanCollection) that wires together dozens of singleton services (ColumnModel, EventService, FocusService, GridOptionsService, RowRenderer, and more) rather than relying on a monolithic grid class. Features are composed as discrete modules (ClientSideRowModelModule, CsvExportModule, PaginationModule, SortModule, etc., wired together in gridCoreModule.ts and allCommunityModule.ts) registered at runtime through a ModuleRegistry, so a consuming app only pays for the modules it explicitly imports. This separates the DI/bean layer (wiring and lifecycle), the module layer (feature boundaries and public API surface via _ModuleWithApi/_ModuleWithoutApi), and the rendering/controller layer (gridBodyComp, headerRendering, rendering) cleanly enough that swapping the row model (client-side vs infinite) doesn’t require touching sorting, filtering, or rendering code — a change to the core bean graph would be the one place that ripples across the whole grid.

Tech Stack Written entirely in TypeScript inside an Nx-managed monorepo (nx.json, @nx/esbuild, @nx/rollup), with ag-grid-community as the framework-agnostic core and separate ag-grid-react, ag-grid-angular, and ag-grid-vue3 packages providing thin framework bindings over the same engine. Builds are produced with esbuild/Rollup via Nx generators, styles are authored in SCSS and compiled to prebuilt theme CSS (Alpine, Balham, Material, Quartz) alongside a CSS-custom-property-based theming API, and the package ships both ESM and CJS output plus type declarations generated from the TypeScript source.

Code Quality Tests are written with Vitest (vitest.config.ts, vitest.umd.config.ts) and colocated with source as *.test.ts files (e.g. main-internal.test.ts, columnNameService.test.ts), covering unit-level behavior of individual services; end-to-end coverage is handled separately via Playwright (@playwright/test, e2e/ directory). The codebase is fully typed, lints with a heavily configured ESLint setup (typescript-eslint, eslint-plugin-sonarjs, eslint-plugin-unicorn, eslint-plugin-import-x) and is formatted with Prettier, and naming/module boundaries are consistent throughout (services suffixed Service, modules suffixed Module). CI enforcement comes through the Nx toolchain’s lint/test/build targets rather than a single ad hoc script.

API Design The public surface is deliberately narrow: consumers call createGrid() with a GridOptions object and interact afterward through a single GridApi object, while internal services stay behind the DI container and are never exposed directly. Feature modules are opt-in and additive, so enabling more functionality (e.g. CsvExportModule) never changes the shape of the existing API — it only adds new methods to GridApi. This gives the library room to add advanced (Enterprise-only) modules later without breaking the Community API contract, at the cost of some upfront complexity in module registration for consumers who want fine-grained bundle control.