Integration and Extensibility Model
The Syncfusion React Data Grid is designed to fit into existing enterprise system architectures. It connects to the organization's data sources, respecting its state management layer, aligning to its design system, and enforcing its security model without requiring reengineering of the layers around it. This section covers the data source integration model, authentication passthrough, versioning and API stability, extensibility points, state management compatibility, programmatic API surface, and multi-instance runtime behavior.
Data source integration
The Data Grid connects to back-end data sources through DataManager and adaptor architecture. An adaptor is a built-in translation layer that converts Data Grid actions such as paging, sorting, filtering, searching, grouping, aggregating, and CRUD operations into the request format that the back end expects and maps the API response back into a format the Data Grid can render. No manual request or response handling is required on the front end.
The adaptor is selected based on the back-end pattern already in use:
For non-standard back ends, the custom adaptor extends any of the above by intercepting and reshaping requests and responses without building from scratch. Common use cases include custom field name mapping, special auth headers, and token injection per request.
Back-end framework coverage
The table below maps each major back-end framework to its recommended adaptor and links to the corresponding integration guide.
Database integration
The Data Grid does not connect to databases from the client side. All data access goes through back-end API endpoints. Documented integration guides are available for the following databases:
ORM compatibility
The Data Grid communicates only through back-end API endpoints and has no direct ORM dependency. Any ORM can be used on the server side as long as the back end exposes endpoints that match the adaptor's request and response contract.
Verified compatible ORMs include:
- Entity Framework Core(EF Core)
- Hibernate and Java Persistence API
- Django ORM
- SQLAlchemy
- Sequelize and Prisma
- Laravel Eloquent
- Dapper
- Custom ADO.NET, raw SQL, and stored procedures
Authentication passthrough
Authentication headers including JWT Bearer tokens, are configurable on the DataManager and applied to every request automatically, covering all Data Grid operations like data load, paging, sorting, filtering, searching, grouping, aggregation and CRUD.
Refer to our documentation on custom headers and applying middleware logic via the DataManager
Versioning and API stability
The Data Grid follows semantic versioning. All public properties, events, methods, and template APIs are part of the stable public API surface.
Extensibility model
The Data Grid exposes all visual layers as configurable extension points that accept standard React components. All extension points use documented public APIs, so customizations remain stable across version upgrades without requiring source-level changes to the Grid. Custom components placed in any template slot are rendered by React. The Data Grid does not use innerHTML or dangerouslySetInnerHTML to mount them. XSS risk from the Grid's rendering layer is not a concern; any HTML injection risk comes only from content the application explicitly renders as raw HTML inside its own template components.
State management compatibility
The Data Grid operates as a pure presentation component. It accepts data through a standard prop and returns user actions as events. It does not introduce a global store, context provider, or parallel data layer into the application. Any React state management library already in use connects to the Data Grid without refactoring the existing state architecture.
Compatibility Matrix
Refer to the guide on integrating Redux Services with the React Data Grid component
Programmatic API: Events and methods
The Data Grid's Event and Method APIs give the application complete control over Data Grid behavior at every stage—before, during, and after execution. All events and method signatures are fully typed and published in a versioned API reference. It provides an extensive set of properties that allow complete control over its behavior. To help users explore these capabilities, a feature-rich interactive sample is available, offering a real-time playground for testing and experimenting with the Data Grid.
Multigrid and micro front-end runtime behavior
Each Data Grid instance operates in full isolation. It maintains its own state, event pipeline, data adaptor, and rendering lifecycle independently of any other Data Grid instance on the same page or across micro front-end modules. No state or behavior is shared across instances unless the application explicitly coordinates them through its own state layer.
Explore the micro front-end architecture blog to understand why and how micro front-end architectures are used in modern applications.