# Grid.Blazor: a data grid component split across a client and a back end

> GridBlazor renders a data grid in Blazor and ASP.NET Core MVC, but the paging, sorting and filtering live in a separate back end package such as GridCore, GridMvcCore, OData or GridJavaCore. It suits teams willing to run that split, and it is the wrong shape if you want one NuGet package to do everything.

**gustavnavar/Grid.Blazor** — Grid component with CRUD for Blazor (client-side and server-side) and ASP.NET Core MVC

- Repository: https://github.com/gustavnavar/Grid.Blazor
- Stars: 730 · Forks: 131
- Language: C#
- License: LGPL-2.1
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/gustavnavar-grid-blazor

## The grid is only the front end; the back end does the real work

The opening line of the project documentation sets the expectation: GridBlazor is a Blazor component that shows data in a grid, and it requires a back-end component that performs paging, sorting, filtering and others.

That sentence is the whole design. The rendering, the column definitions and the editing UI live in the Blazor component. The data operations live somewhere else, in a package you choose, and the component talks to it over a transport.

Three back ends are named. GridCore, at version 6.0.0 or later, supports ASP.NET Core 3.1 and ASP.NET 5.0 through 9.0, and GridMvcCore, its predecessor for earlier versions, was a fork of gridmvc.codeplex.com and used to work for earlier versions. GridMvcCore is now only needed for Blazor WASM with a REST back end and for ASP.NET MVC projects. An OData back end is the second option, with all samples based on the Microsoft.AspNetCore.OData library, though any other OData provider is said to work. The third is GridJavaCore, a back end for Java JPA and Hibernate projects.

The component itself supports.NET Core 3.1 and 5.0 through 9.0, and Blazor WebAssembly 3.2.0 and 5.0 through 9.0. There is a hosted demo at gridblazor.azurewebsites.net.

## Six documented setups, one per hosting combination

The repository separates the documentation by hosting model, and reading the list tells you how much configuration each combination needs.

For Blazor WebAssembly there are four variants: with GridMvcCore over a REST API, with GridCore over gRPC, with an OData back end, and with local data where the grid holds the rows itself. Blazor server-side has its own document, ASP.NET Core MVC has its own, and there is a separate document for using the GridBlazor component inside an ASP.NET Core MVC project.

The four WebAssembly variants are the interesting comparison. The gRPC route pushes the data operations into a GridCore service the browser talks to over gRPC. The REST route uses GridMvcCore, which the project notes was created by forking GridMvc from gridmvc.codeplex.com. The OData route leans on an existing standard rather than a bespoke protocol. The local data route has no server at all, which is useful for a client-only app whose dataset is small enough to sit in the browser.

The repository layout mirrors this. GridBlazor holds the component, GridCore the server side core, GridMvc and GridShared the MVC and shared pieces, GridSharedData the shared data types, and then a sample project per scenario: GridBlazorClientSide, GridBlazorGrpc, GridBlazorOData, GridBlazorServerSide, GridBlazorStandalone and GridMvc.Demo. Test projects sit alongside as GridBlazor.Tests and GridMvc.Tests, and the solution file is Grid.Blazor.sln.

## Version 6.4.0 changed date display, TimeSpan filters and the static assets

The most recent release, 6.4.0, is the one with the longest migration note, and it is worth reading before you plan an upgrade.

The wire format did not change. Filter values and query strings are still ISO 8601, in the form yyyy-MM-dd, so no back end change is needed and a grid can be upgraded on its own. What changed is display. A date used to be written the same way for everybody; it is now written the way the reader writes dates, with the day and month padded to two digits. A column that sets its own format keeps it, because Format now takes precedence over the locale.

```c#
        c.Add(o => o.OrderDate).Format("{0:yyyy-MM-dd}");   // before: the only stable option
        c.Add(o => o.OrderDate);                            // now: written as the reader writes it
```

A DateTime column with no format now shows its date alone, where it used to fall back to ToString() and append the time of day. Where the hour matters the column has to say so with Format("{0:g}") or a similar pattern, although editing is unaffected since the CRUD form still edits the whole value.

System.TimeSpan columns are now filtered as durations with their own filter type and clock widget, rather than falling through to the text filter and being compared as a string. The stated consequence is blunt: a stored grid state or a saved URL that applies a text operator to a TimeSpan column will no longer filter as it did.

## The static asset trap in gridblazor.js and the CSS files

Point five of the 6.4.0 notes is the one most likely to break an existing application without an obvious error message.

The rule is that gridblazor.js and the CSS files ship with GridBlazor and are versioned with it. Projects that copied those files into their own wwwroot, instead of referencing the _content/GridBlazor/... path, must take the new versions. The reason given is that the component calls JavaScript functions that did not exist before, and the new picker has no styles without the new CSS. A browser holding an old copy in cache shows the symptom as a picker that will not open, so a forced reload after upgrading is the recommended step.

Two smaller points ride along with it. SetDateInputMode is new and entirely opt-in. The default is DateInputMode.Browser, which is exactly the behaviour of earlier versions, using the native input type date control and its relatives. Only an application that picks its own culture instead of taking the browser's needs DateInputMode.Grid, and the notes point at the Using datetime filter document for that. And for anyone maintaining a CSS theme derived from the shipped ones, the picker rules now live only in gridblazor.css, since the per-theme files no longer carry a copy.

SetInputType is now honoured on DateOnly and TimeOnly columns, which previously ignored it and always rendered a plain date or time control. The reverse direction also changed: a date column set to an input type a date cannot be, such as Text, TextArea, File or Number, now falls back to its natural control instead of rendering an input with an empty type attribute.

## Package renames from 3.0.0 that still shape your code

Two older migrations are documented in the readme, and they explain a lot of the naming you will meet in the source and in other people's questions about it.

For Blazor WebAssembly projects with a REST back end, migrating to GridBlazor 3.5.0 and GridCore 5.5.0 means removing the GridCore package and installing GridMvcCore, upgrading the GridBlazor package, replacing all GridCore instances with GridServer ones, and changing references to the Grid property, which now has an SGrid<T> type where it had ISGrid<T> before. Some classes also moved from the GridCore package to the GridMvc one, so the using directives change.

The 3.0.0 migration for all other Blazor projects runs the other way. You remove GridMvcCore and install GridCore, replace GridServer instances with GridCore ones, and change the Grid property reference from SGrid<T> to ISGrid<T>. Classes move from GridMvc to GridCore for the same reason.

Two lessons carry over. The Grid property type is not stable across major versions, so code that stores a grid reference in a field or a service will need attention on an upgrade. And the choice between GridCore and GridMvcCore is not merely a version thing, it is determined by whether the application is Blazor WASM with a REST back end or one of the other combinations. The readme states that GridMvcCore is only required for Blazor WASM REST and ASP.NET MVC projects now.

## Where Grid.Blazor is the wrong choice

There are cases where the split design works against you.

The first is a project that wants exactly one dependency. If your team would rather add a single NuGet package that handles both the grid and the data operations, this architecture does not offer that, because the back end is a separate package by construction. For Blazor WebAssembly with REST that means GridMvcCore specifically, and for everything else GridCore, and for OData you bring your own provider.

The second is a Java backend. GridJavaCore exists for Java JPA and Hibernate projects, so the grid can be shared with a Java service, but that is a separate repository with its own release cadence, and the version compatibility between the two is not stated in this project's documentation.

The third is a Blazor WASM application with a large dataset and no appetite for server infrastructure. The local data route exists, but the whole point of the back end is to keep paging and filtering off the client, so using local data means giving up the component's main reason to exist.

The fourth is stability of your grid configuration. The 6.4.0 note about stored grid states and saved URLs no longer filtering as they did is a concrete reminder that this component persists user facing filter state in URLs, and that state is sensitive to version upgrades. A product that lets users bookmark and share filtered grid views should treat a major version bump as a data format change for its users.

## Licence and the maintenance picture

The project is licensed LGPL-2.1, with the LICENSE file at the repository root. That matters more here than it would for a small utility, because GridBlazor is a library that ships inside someone else's application. LGPL terms are designed for linking, and the practical question of whether your use counts as linking, and whether you need to ship source for modifications to the library itself, is a legal question rather than a technical one. Read the licence text and check with your own counsel if the distinction matters for your distribution model.

On maintenance, the repository is not archived and the last push was on 2026-08-30, which is the same day as the 6.4.0 release. The release before that, 6.3.2, came on 2026-05-04, and 6.3.1 on 2026-04-28.

There is no statement in the documentation about a support policy or a deprecation schedule for older back ends, and no changelog file at the repository top level. The migration notes in the readme are the primary record of what changed and what a consumer must do about it, which means an upgrade decision for GridBlazor 6.4.0 comes down to reading eight numbered points in the readme rather than checking a release feed.

## Conclusion

Adopt Grid.Blazor when your application already has, or can add, a server side component that performs paging, sorting and filtering, and when you want one grid markup across Blazor WebAssembly, Blazor server and ASP.NET Core MVC. Do not adopt it if you expected a single package to cover the whole stack, because the back end is a separate dependency and for Blazor WebAssembly with REST it is GridMvcCore rather than GridCore. Before upgrading, check the release notes for your version, since 6.4.0 changes date display, TimeSpan filtering and the static assets, and confirm that your project references _content/GridBlazor/... rather than copying gridblazor.js and the CSS files into its own wwwroot.

## FAQ

### What back end does GridBlazor need?

The component requires a back end that performs paging, sorting and filtering. The options are GridCore from version 6.0.0, GridMvcCore for Blazor WASM with a REST back end and for ASP.NET MVC projects, any OData provider, or GridJavaCore for Java JPA and Hibernate backends.

### Which .NET and Blazor versions does Grid.Blazor support?

The component supports .NET Core 3.1 and 5.0 through 9.0, and Blazor WebAssembly 3.2.0 and 5.0 through 9.0. GridCore from version 6.0.0 supports ASP.NET Core 3.1 and ASP.NET 5.0 through 9.0.

### What changed in GridBlazor 6.4.0?

Dates are now displayed following the reader's locale while the wire format stays ISO 8601, TimeSpan columns get their own duration filter, and the shipped gridblazor.js and CSS files must be updated together with the package.

### How do I keep the date picker working after upgrading Grid.Blazor?

Reference the shipped files through the _content/GridBlazor/... path rather than copying them into your own wwwroot, then take the new gridblazor.js and CSS versions. The component calls JavaScript functions that did not exist in earlier versions, and a browser holding a cached old copy shows a picker that will not open.

### What is the SetDateInputMode option in Grid.Blazor?

It is new in 6.4.0 and entirely opt-in. The default, DateInputMode.Browser, reproduces the behaviour of earlier versions using the native input type date control. Only an application that selects its own culture rather than taking the browser's needs DateInputMode.Grid.

## Sources

- [gustavnavar/Grid.Blazor on GitHub](https://github.com/gustavnavar/Grid.Blazor)
- [Issues](https://github.com/gustavnavar/Grid.Blazor/issues)
- [License: LGPL-2.1](https://github.com/gustavnavar/Grid.Blazor/blob/master/LICENSE)
- [README](https://github.com/gustavnavar/Grid.Blazor/blob/master/README.md)
- [Releases](https://github.com/gustavnavar/Grid.Blazor/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gustavnavar-grid-blazor