…ousData`

The error path in `handleDataUpdate` and `handleGroupedDataUpdate` cleared
rows unconditionally, so a rejected refetch wiped the last known-good data
even when `dataSourceKeepPreviousData` was on — the opposite of what users
opt into the prop for. Gate both `setRows([])` calls behind the prop so a
failed refetch leaves the previous rows visible while `onDataSourceError`
delivers the error.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

…mmetry

The community handler had a redundant `if (standardRowsUpdateStrategyActive)`
guard inside the callback even though the event listener is already wired
with `runIf(standardRowsUpdateStrategyActive, ...)`. Drop the inner guard
and add a comment so the gating intent is explicit. This also restores the
pre-PR behavior of unconditionally clearing rows on non-standard strategies
(the outer `runIf` skips the handler entirely instead).

The Premium row-grouping handler is wired without a strategy check at the
event level, so it could call `setLoading(true)` while `fetchRows` would
not call the matching `setLoading(false)` (cleared only on standard
strategies). Add an inline strategy check there so the loading flag is
only flipped when `fetchRows` will eventually clear it again.

Tests:
- Add `state.rows.loading === false` assertion to the error-recovery test.
- Add Premium row-grouping regression tests that exercise the loading
  toggle and the keep-previous-data behavior on grouping model change.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Per review on mui#22465 (mui#22465 (comment)),
the opt-in prop has the same shape as the bug mui#21619 fixed: skipping the
synchronous `setRows([])` would leave tree-data sort/filter changes rendering
rows in stale order until the user collapsed/re-expanded. Keep this PR focused
on the reported `noRowsOverlay` flicker and ship the controllable prop in a
follow-up that handles the tree-data interaction.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

When `true`, the Data Grid keeps the previously displayed rows visible while
new rows are being fetched after pagination, sorting, or filtering changes,
rather than blanking the grid and showing the skeleton loading overlay.
The loading overlay (linear-progress variant, since rows are non-empty) is
rendered on top of the previous rows. Mirrors React Query's
`placeholderData: keepPreviousData` and SWR's `keepPreviousData`.

Scope: the opt-in only applies to the flat `Default` strategy. For tree-data
and row grouping (`GroupedData` strategy), the Data Grid always resets the
rows on refetch — otherwise the existing tree would be merged on top of the
new response via `updateRows` and rows would render in stale sort order
(the regression mui#21619 fixed by adding the synchronous `setRows([])` to
`handleFetchRowsOnParamsChange`).

Tests:
- Flat data: previous rows stay visible during fetch; loading overlay does
  not switch to `noRowsOverlay`; previous rows persist on error.
- Tree data (regression coverage for mui#21619): root rows are still re-ordered
  on sort change when `dataSourceKeepPreviousData` is enabled.

Builds on mui#22465.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The `icon` prop is `React.JSXElementConstructor<...> | React.ReactNode`. Under
React 19, `ReactNode` expands to a union that includes `Iterable`, `bigint`,
and `Promise`, which `typescript-to-proptypes` serializes using TypeScript's
internal `Symbol.iterator` / `Symbol.toStringTag` ids (e.g. `__@iterator@659`).
Those ids are assigned lazily by the TS checker, so they shift whenever the
package's type graph changes -- any unrelated prop addition flips `659` to
`660` and forces a churn diff in this file, failing the `pnpm proptypes` CI
check. This was the only file in the repo carrying these volatile symbol ids.

Pin a stable, faithful representation with the established
`@typescript-to-proptypes-ignore` directive (as used in DataGrid.tsx,
GridPanel.tsx, the pickers inputs, etc.), collapsing the prop to
`oneOfType([elementType, node])`.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

The demo intentionally sets a 500-1500ms mock-server delay so the
keep-previous-data behavior is visible when paginating. An explicit delay
bypasses the regression build's delay-zeroing (`__DISABLE_CHANCE_RANDOM__`
-> `DEFAULT_SERVER_OPTIONS` delays of 0), and the screenshot harness's
`aria-busy` gate only tracks font loading, not async demo data -- so the
initial skeleton overlay was being captured instead of the loaded grid.

Add a `waitForSelector` rule that waits for a real, non-skeleton row before
screenshotting, mirroring the existing GridToolbarCustom handling.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Per review (mui#22554 (comment)),
`oneOfType([elementType, node])` allowed component types (functions), which
break at runtime: the non-menu variant clones the icon via
`React.cloneElement(icon!)` (its type is `React.ReactElement`), and the menu
variant renders it as a node -- a function child throws "Functions are not
valid as a React child". Every in-repo usage passes an element. Tighten to
`PropTypes.element`, keeping the `@typescript-to-proptypes-ignore` directive
that stabilizes the generated proptype.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>