Request for a complete example of QuickGrid integration with EF Core (Blazor Server)

[mikermnv]

Request for a complete QuickGrid + EF Core example + Blazor Server

Hello team,

First of all, thank you for the work you’ve done on QuickGrid — it’s a very promising component. While experimenting with it, I noticed that the documentation and samples currently available mostly cover basic usage. I haven’t been able to find a full, end‑to‑end example that demonstrates how to integrate the grid with Entity Framework Core in a real application.

Specifically, I’m looking for guidance or a sample that shows:

• Proper sorting and pagination wired up to EF Core queries
• Filtering with inputs that are applied only when the user clicks an Apply or Search button (rather than on every keystroke)
• How to handle projections (mapping EF entities into DTOs/records) while still keeping sorting and paging functional
• A full‑featured scenario with all of the above working together in Blazor Server

One particular challenge I’ve run into is that when using projections (e.g. mapping EF entities into DTOs or records), the built‑in sorting often stops working. EF Core throws exceptions such as “could not be translated to SQL” because the grid tries to sort on the projected properties. It would be very helpful to see a recommended approach or adapter pattern for integrating QuickGrid with EF Core in these cases, so that sorting, paging, and filtering continue to work correctly.

I believe such an example would be extremely valuable for developers trying to adopt QuickGrid in production scenarios. Could you please point me to an existing sample if one already exists, or consider publishing a more complete demo that covers these aspects?

Thank you very much for your time and for considering this request.

Best regards,
Michael

[InfinityZero3000]

Thanks for the detailed write-up — this is a very common pain point when combining QuickGrid + EF Core + server-side sorting/paging + projections.

Key idea: keep sorting/paging on the entity query, not on the projected type

EF Core can only translate an OrderBy if it can trace it back to a SQL-translatable expression. Once you project to a DTO/record that contains computed/non-translatable members (or the grid generates an OrderBy over something EF can’t bind back to SQL), you’ll hit the classic “could not be translated” errors.

The most robust pattern is:

1. Start from IQueryable<TEntity> (e.g., db.Customers.AsNoTracking()).
2. Apply filters to the entity query.
3. Apply sorting to the entity query (based on the grid’s requested sort column).
4. Apply paging (Skip/Take) to the entity query.
5. Only then Select(...) into DTOs for the grid.

Suggested adapter pattern (mapping sort columns -> EF expressions)

Because the grid’s sort state is typically tied to the grid item type (often the DTO), you generally need a small mapping layer so that “sort by column X” becomes “order by entity expression Y”.

Example skeleton:

// 1) Define your DTO for the grid
public sealed record CustomerRow(int Id, string Name, string Email, string? City);

// 2) Map sortable columns to EF-friendly expressions (entity-side)
static readonly Dictionary<string, Expression<Func<Customer, object>>> SortMap = new()
{
    ["Name"]  = c => c.Name,
    ["Email"] = c => c.Email,
    ["City"]  = c => c.Address!.City,  // OK if translatable
};

// 3) ItemsProvider that applies filter/sort/page server-side
private async ValueTask<GridItemsProviderResult<CustomerRow>> ProvideCustomers(GridItemsProviderRequest<CustomerRow> request)
{
    IQueryable<Customer> query = db.Customers.AsNoTracking();

    // Filters (apply to entity query)
    if (!string.IsNullOrWhiteSpace(_applied.Search))
        query = query.Where(c => c.Name.Contains(_applied.Search) || c.Email.Contains(_applied.Search));

    // Sorting (map grid sort -> entity sort)
    // Pseudocode: extract a "sort key" you control, e.g. column name
    var (sortKey, descending) = GetSortFromRequest(request); // implement based on your column setup
    if (sortKey is not null && SortMap.TryGetValue(sortKey, out var sortExpr))
        query = descending ? query.OrderByDescending(sortExpr) : query.OrderBy(sortExpr);
    else
        query = query.OrderBy(c => c.Id); // stable default

    // Total count *after filters*, before paging
    var total = await query.CountAsync();

    // Paging + projection
    var page = await query
        .Skip(request.StartIndex)
        .Take(request.Count ?? 50)
        .Select(c => new CustomerRow(
            c.Id,
            c.Name,
            c.Email,
            c.Address != null ? c.Address.City : null))
        .ToListAsync();

    return GridItemsProviderResult.From(page, total);
}

The missing piece is how you derive sortKey. The easiest approach is: ensure each sortable column has a known key (e.g., "Name", "Email") and read that from the grid request / current sort state. If the built-in request object only gives you an expression over the DTO, you can still avoid EF translation issues by not feeding that expression to EF; instead, translate it to your own key and use the map above.

“Apply/Search” button instead of filtering on every keystroke

Use two filter models:

• _draft bound to inputs
• _applied used by the query

On “Apply”:

• _applied = _draft;
• reset pagination to the first page
• call grid.RefreshDataAsync() (or equivalent)

This avoids query churn on every keypress and matches typical “Search” UX.

Projections that break sorting: what to do

If a projected property isn’t trivially SQL-translatable (custom methods, complex formatting, localization, etc.):

• Prefer sorting by an underlying translatable column (e.g., sort by LastName + FirstName instead of a formatted FullName), and display FullName purely for UI.
• If you must sort by a computed value, make it SQL-friendly (computed column / view / mapped scalar function), or accept client-side sorting only after materialization (but that generally conflicts with true server-side paging).

About a full end-to-end sample

I agree an end-to-end sample would be valuable: QuickGrid + EF Core ItemsProvider + sort/page/filter + “Apply” filters + a safe projection strategy. If there isn’t one published yet, the patterns above are what we typically recommend for production: keep EF query composable on entities, and use a small mapping layer to translate grid sort intent into EF expressions.