# MGGRID — TODO

For known issues / bugs see `MGGRID_ISSUES.md`.

## Priority legend
- **P0** blocker · **P1** important · **P2** nice-to-have · **P3** idea

---

## ACBLAZOR-GRID-T-V4P7: Generic ID generation in `MgGridBase.SetNewId`
**Priority:** P2 · **Type:** Refactor (framework-first) · **Origin:** 2026-04-24 in-code TODO audit · **Area:** `Components/Grids/MgGridBase.cs:460`

`SetNewId(TDataItem dataItem)` branches on `dataItem.Id is Guid` vs `dataItem.Id is int` to produce a new ID, and converts through `TypeConverter` back to `TId`. The in-code comment `//TODO: int !!! - J.` flags this as unfinished — the logic is not cleanly generic over `TId`.

```csharp
private void SetNewId(TDataItem dataItem)
{
    //TODO: int !!! - J.
    if (dataItem.Id is Guid)
    {
        dataItem.Id = (TId)(_typeConverterId.ConvertTo(Guid.NewGuid(), typeof(TId)))!;
    }
    else if (dataItem.Id is int)
    {
        var newId = -1 * AcDomain.NextUniqueInt32;
        dataItem.Id = (TId)(_typeConverterId.ConvertTo(newId, typeof(TId)))!;
    }
}
```

Problems:
- Runtime type switch on a generic parameter defeats the point of generics.
- Silent no-op for any other `TId` (e.g., `long`, `short`, custom struct) — no compile error, no throw.
- The negative-int convention (`-1 * AcDomain.NextUniqueInt32`) is not expressed as a contract; consumers cannot override.

### Fix options
- **(a)** Introduce `IAcNewIdGenerator<TId>` framework abstraction (in AyCode.Core) with default implementations for `Guid` and `int`. `MgGridBase` takes it via DI or generic parameter. Consumer-specific `TId` types register their generator.
- **(b)** Virtual protected method: `protected virtual TId GenerateNewId()` on `MgGridBase`, with default implementations for `Guid` and `int` preserved. Consumer overrides for custom `TId`.
- **(c)** Static strategy map keyed by `typeof(TId)` — registered once per app startup, resolved at runtime.

### Acceptance criteria
- No runtime type-switch in `MgGridBase`.
- Throws explicit `NotSupportedException` (or similar) for unregistered `TId` types.
- Existing `Guid` and `int` consumers unaffected.
- Remove the `//TODO: int !!! - J.` comment.

## ACBLAZOR-GRID-T-S2L9: Implement local grouping in `MgGridSignalRDataSource.GetGroupInfoAsync`
**Priority:** P3 · **Type:** Feature · **Origin:** 2026-04-24 in-code TODO audit · **Area:** `Components/Grids/MgGridSignalRDataSource.cs:202`

```csharp
public override async Task<IList<GridCustomDataSourceGroupInfo>> GetGroupInfoAsync(
    GridCustomDataSourceGroupingOptions options,
    CancellationToken cancellationToken)
{
    _logger?.Debug("[MgGridSignalRDataSource] GetGroupInfoAsync");

    // TODO: Implement local grouping when needed
    return await base.GetGroupInfoAsync(options, cancellationToken);
}
```

Currently delegates to the DevExpress base implementation, which for a server-side `GridCustomDataSource` triggers a server round-trip. With `MgGridSignalRDataSource` already holding a local cache (see `MGGRID_DATASOURCE.md`), grouping over the cached rows would avoid that round-trip.

Not urgent — only light grouping usage so far; the base path works. Promote to P2 if a consumer hits perceptible grouping latency.

### Acceptance criteria
- Local grouping computed from the cached list when the full dataset is cached.
- Falls back to base (server) path when the cache is partial / paginated.
- Unit / integration test with a grouped column.
- Remove the `// TODO: Implement local grouping when needed` comment.

## TODO entry template

```
## ACBLAZOR-GRID-T-XXXX: Short title
**Priority:** P0 / P1 / P2 / P3 · **Type:** Bug fix / Feature / Refactor / Docs · **Related:** `MGGRID_ISSUES.md#acblazor-grid-i-XXXX` (if applicable)

Description of what and why, including the trigger (user request, audit finding, incident).

Options / sub-tasks / acceptance criteria.
```