Search intent and what users actually want (so your article ranks)

Across queries like React data grid DevExtreme, DevExtreme React Grid installation,
and DevExtreme React Grid example, the dominant intent is mixed:
users want quick “get it running” instructions (informational) and also want reassurance the grid is “enterprise enough” (commercial investigation).
People rarely ask for theory; they ask for a working baseline that won’t collapse when requirements show up with a clipboard.

In the English SERP, top results typically fall into three buckets: official docs (navigational + informational),
tutorial posts (informational), and “comparison” pages (commercial investigation) targeting React enterprise data grid terms.
The best-performing pages usually include: installation steps, a minimal working code sample, and “how to do X” blocks
(filtering, grouping, paging, editing).

One pattern that consistently wins featured snippets and voice search: short, direct answers (“To add paging, install X and add Y plugins”),
followed by an example. So that’s what we’ll do—because your readers and Google both appreciate it when you don’t hide the point.

DevExtreme React Grid installation and setup (minimal, predictable, scalable)

The fastest way to fail with an advanced React table component (advanced) is to start by over-engineering state management.
DevExtreme’s grid is plugin-driven: you compose behavior from small blocks. That’s great for large apps, but it also means your
first step should be a clean baseline with a small data set and a stable column definition.

For a typical DevExtreme React Grid setup, you’ll install the grid package and a UI integration layer (commonly Material UI).
Then you build the grid from plugins: a “state” plugin (sorting/filtering/paging/editing), an “integrated” plugin (does the work),
and a “table UI” plugin (renders controls).

If you’re building a React interactive grid for internal tools, dashboards, or admin panels, this modularity is a feature:
you can ship a read-only grid first, then add editing, grouping, or column resizing without rewriting everything.

• Install checklist: grid core + UI binding (e.g., Material UI) + theme styles (if required in your stack).
• Start small: 5–20 rows, 3–6 columns, no remote data yet. Prove the pipeline first.
• Then add features: filtering → paging → grouping → editing (or in the order your users complain about).

# Example installation (verify latest versions in npm)
npm i @devexpress/dx-react-grid @devexpress/dx-react-grid-material-ui

# If your project uses Material UI, ensure it’s installed and configured
npm i @mui/material @emotion/react @emotion/styled

Official references you’ll likely want open in another tab:

DevExtreme React Grid documentation

and a real-world write-up for advanced implementation patterns:

advanced data grid implementation with DevExtreme React Grid
.

A working DevExtreme React Grid example (sorting + baseline table)

Let’s build a minimal but “real” React data grid DevExtreme example: define columns, rows, and render a table.
The key to staying sane is to keep data shaping outside the grid. The grid is not your ORM, your API client, or your therapist.
It’s a view layer with powerful state plugins.

Below is a baseline component you can paste into a React app. It includes sorting because (a) it’s common,
and (b) it demonstrates the plugin chain pattern you’ll reuse for filtering, paging, and grouping.

For voice-search style queries like “How do I add sorting to DevExtreme React Grid?”, the answer is: add
SortingState + IntegratedSorting + TableHeaderRow showSortingControls.
Short, direct, shippable.

import * as React from "react";
import Paper from "@mui/material/Paper";
import {
  Grid,
  Table,
  TableHeaderRow,
} from "@devexpress/dx-react-grid-material-ui";

import {
  SortingState,
  IntegratedSorting,
} from "@devexpress/dx-react-grid";

const columns = [
  { name: "id", title: "ID" },
  { name: "name", title: "Name" },
  { name: "status", title: "Status" },
];

const initialRows = [
  { id: 1, name: "Alpha", status: "Active" },
  { id: 2, name: "Beta", status: "Paused" },
  { id: 3, name: "Gamma", status: "Active" },
];

export function BasicDevExtremeGrid() {
  const [rows] = React.useState(initialRows);
  const [sorting, setSorting] = React.useState([{ columnName: "id", direction: "asc" }]);

  return (
    <Paper>
      <Grid rows={rows} columns={columns}>
        <SortingState sorting={sorting} onSortingChange={setSorting} />
        <IntegratedSorting />

        <Table />
        <TableHeaderRow showSortingControls />
      </Grid>
    </Paper>
  );
}

Filtering, grouping, and pagination (the “enterprise grid” trio)

When people say React enterprise data grid, they usually mean three things:
users can find rows fast (filtering), understand structure (grouping),
and navigate without killing performance (pagination or virtualization).
DevExtreme React Grid handles this through separate plugins, which is both powerful and—at first—slightly like assembling furniture from 47 bags of screws.

Here’s the mental model: “State” plugins hold user intent (filter values, current page, grouping columns).
“Integrated” plugins apply that intent to the data.
UI plugins render controls. That’s why you can swap UI layers or customize pieces without rewriting the data logic.

The following snippet shows DevExtreme React Grid filtering, DevExtreme React Grid grouping,
and DevExtreme React Grid pagination together. If your roadmap includes server-side data operations,
you can later replace the “Integrated” plugins with remote calls and keep a similar UI.

import * as React from "react";
import Paper from "@mui/material/Paper";
import {
  Grid,
  Table,
  TableHeaderRow,
  TableFilterRow,
  TableGroupRow,
  PagingPanel,
} from "@devexpress/dx-react-grid-material-ui";

import {
  SortingState,
  IntegratedSorting,
  FilteringState,
  IntegratedFiltering,
  GroupingState,
  IntegratedGrouping,
  PagingState,
  IntegratedPaging,
} from "@devexpress/dx-react-grid";

const columns = [
  { name: "id", title: "ID" },
  { name: "name", title: "Name" },
  { name: "status", title: "Status" },
  { name: "team", title: "Team" },
];

const rows = [
  { id: 1, name: "Alpha", status: "Active", team: "A" },
  { id: 2, name: "Beta", status: "Paused", team: "B" },
  { id: 3, name: "Gamma", status: "Active", team: "A" },
  { id: 4, name: "Delta", status: "Active", team: "B" },
];

export function EnterpriseFeaturesGrid() {
  const [sorting, setSorting] = React.useState([{ columnName: "id", direction: "asc" }]);
  const [filters, setFilters] = React.useState([]);
  const [grouping, setGrouping] = React.useState([{ columnName: "team" }]);

  const [currentPage, setCurrentPage] = React.useState(0);
  const [pageSize, setPageSize] = React.useState(5);

  return (
    <Paper>
      <Grid rows={rows} columns={columns}>
        <SortingState sorting={sorting} onSortingChange={setSorting} />
        <IntegratedSorting />

        <FilteringState filters={filters} onFiltersChange={setFilters} />
        <IntegratedFiltering />

        <GroupingState grouping={grouping} onGroupingChange={setGrouping} />
        <IntegratedGrouping />

        <PagingState
          currentPage={currentPage}
          onCurrentPageChange={setCurrentPage}
          pageSize={pageSize}
          onPageSizeChange={setPageSize}
        />
        <IntegratedPaging />

        <Table />
        <TableHeaderRow showSortingControls />
        <TableFilterRow />
        <TableGroupRow />
        <PagingPanel pageSizes={[5, 10, 20]} />
      </Grid>
    </Paper>
  );
}

If you’re comparing options for a React data grid library, this is the point where DevExtreme starts to feel “enterprise”:
adding capabilities is mostly additive, not a refactor. The trade-off is you need to learn the plugin vocabulary—but it pays off quickly.

React table with editing: inline CRUD without turning state into spaghetti

Editing is where many grids either shine or reveal their true nature as a “demo component.” A solid React table with editing
needs clear rules: how changes are validated, how they’re committed, and what happens when the API says “no.”
DevExtreme’s approach is to keep editing state and “commit changes” as explicit steps.

In practice, your commit handler becomes the boundary between UI intent and persistence.
For a prototype, you can update local state. For production, you call your API and either accept (update rows) or reject (revert).
The grid stays the grid; your data layer stays your data layer. That separation is the whole point of “enterprise,” minus the PowerPoint.

Here’s a minimal inline editing example. It uses local state updates to keep it self-contained; swap the commit logic with a request to your backend
when you’re ready.

import * as React from "react";
import Paper from "@mui/material/Paper";
import {
  Grid,
  Table,
  TableHeaderRow,
  TableEditRow,
  TableEditColumn,
} from "@devexpress/dx-react-grid-material-ui";

import { EditingState } from "@devexpress/dx-react-grid";

const columns = [
  { name: "id", title: "ID" },
  { name: "name", title: "Name" },
  { name: "status", title: "Status" },
];

const initialRows = [
  { id: 1, name: "Alpha", status: "Active" },
  { id: 2, name: "Beta", status: "Paused" },
];

export function EditableGrid() {
  const [rows, setRows] = React.useState(initialRows);

  const commitChanges = ({ added, changed, deleted }) => {
    setRows((prevRows) => {
      let nextRows = prevRows;

      if (added && added.length) {
        const startingAddedId =
          nextRows.length > 0 ? Math.max(...nextRows.map(r => r.id)) + 1 : 1;
        nextRows = [
          ...nextRows,
          ...added.map((row, index) => ({ id: startingAddedId + index, ...row })),
        ];
      }

      if (changed) {
        nextRows = nextRows.map((row) =>
          changed[row.id] ? { ...row, ...changed[row.id] } : row
        );
      }

      if (deleted && deleted.length) {
        const deletedSet = new Set(deleted);
        nextRows = nextRows.filter((row) => !deletedSet.has(row.id));
      }

      return nextRows;
    });
  };

  return (
    <Paper>
      <Grid rows={rows} columns={columns}>
        <EditingState onCommitChanges={commitChanges} />

        <Table />
        <TableHeaderRow />
        <TableEditRow />
        <TableEditColumn showAddCommand showEditCommand showDeleteCommand />
      </Grid>
    </Paper>
  );
}

Common production hardening for editing includes validation, optimistic updates, row-level locking, and “dirty state” indicators.
DevExtreme won’t magically decide these product rules for you (sadly), but it gives you a stable place to implement them: the commit boundary.

• Validation: validate before commit; reject with a clear message. Don’t “half-save” rows.
• Remote mode: replace local commit with API calls; on success update rows, on error revert.
• Performance: memoize columns/rows where appropriate; avoid recreating arrays on every render.

Choosing DevExtreme for a React enterprise grid (and not regretting it later)

“Enterprise” isn’t a badge; it’s a list of unpleasant constraints: long-lived codebases, changing requirements,
non-technical users who will click everything, and stakeholders who believe “export to Excel” is a fundamental human right.
A good React enterprise grid is one you can extend without tearing up the foundation.

DevExtreme React Grid’s plugin architecture is the reason teams pick it for internal platforms:
you can add features incrementally and keep them testable.
Filtering and grouping stay separate from editing, paging stays separate from sorting, and UI stays separate from data logic.
It’s not the shortest learning curve, but it’s a reasonable trade for control.

If you’re ready to go deeper, start from the official

DevExtreme React Grid

docs, then review an implementation-focused walkthrough like this

DevExtreme React Grid tutorial

to see how others structure a more advanced React interactive grid in the wild.