AyCode.Blazor/AyCode.Blazor.Components/docs/MGGRID/MGGRID_TODO.md

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.

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

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.