4.12.0 Bug on FluentDataGrid

[MmMapIoSpace]

Hello,

Today, I performed an upgrade of the package from version 4.11.9 to 4.12.0. I did not make any changes to my code — I only updated the package via NuGet.

However, it appears that something is behaving differently than usual.

Issue 1: Table does not reflect new items instantly
Previously, when I added a new item to the collection bound to a DataGrid table, the new item would appear instantly without needing to call InvokeAsync(StateHasChanged) or @ref.RefreshDataAsync.

But today, after the upgrade, the item does not appear immediately. Initially, I thought that perhaps the new version requires manual intervention to refresh the UI. However, after filtering/searching the table, I noticed that the new data is actually present — it's just not displayed initially.
So I suspect this might be a bug introduced in version 4.12.0.

Issue 2: Blue line appearing in the table
Secondly, I noticed a blue line appearing in the table, and I’m not sure what it represents.

I have several projects using FluentUI, and after checking them all — only those that were upgraded today are affected. This issue is consistent across upgraded projects.

[vnbaaij]

Issue 1)
We must have ready to run reproduction code if you want us to take a look at this. It is impossible to know what is happening in your application and the provided image does not give any insight (and we can't run or even copy that code)

Standard response below

Please supply us with ready-to-run reproduction code in the form of something we can copy/paste, a (zipped) project structure or a GitHub repository.

We do not have capacity to craft or compose a reproduction for every issue that gets raised.

If no code or repository is provided, this issue will be closed in 3 days

Help us to help you. Thanks.

---

Issue 2) Not an issue.
When a DataGrid has resizable columns, you can now start a resize action on the edge of a cell on all rows instead of only at the header cell edge. We show the blue bar (across the whole column on mouse over) to indicate that.
In v4.12.1 we will offer a parameter to disable this new option and revert back to the previous behavior. Also we will include CSS variables that allow you to change the color of the bar.

[vnbaaij]

Do you have more than 250 items in your grid? And is the item being added to the end of the collection? If so, it might be this change in v4.12 is affecting you. See #3864.
Maybe you can try to add the new item at the start.

[MmMapIoSpace]

Do you have more than 250 items in your grid? And is the item being added to the end of the collection? If so, it might be this change in v4.12 is affecting you. See #3864. Maybe you can try to add the new item at the start.

I'm not sure how to create reproduction code for you to analyze.
But yes, I have around 12K items. I'm not certain whether they're added to the end of the collection, but usually, since I use a sort order based on descending creation datetime, they should appear at the top without me needing to explicitly refresh the table.
The point is, the item is already present in the search results (it's already added), but the behavior of how it's added and sorted seems different than usual.
So in this version, in other words, I need to explicitly add code to restore the expected behavior.

[vnbaaij]

For reproduction you can just use our templates as a starting point. Create an app and create a page that has a copy of your code and is made to work with a static/made up set of data. It might be a bit of work but so is maintaining this library. You need to help us to help you...

It could be as easy as adding a StateHasChanged or calling RefreshDataAsync in one place.

I'll see if the optimization we did can be made opt-in

[MmMapIoSpace]

For reproduction you can just use our templates as a starting point. Create an app and create a page that has a copy of your code and is made to work with a static/made up set of data. It might be a bit of work but so is maintaining this library. You need to help us to help you...

It could be as easy as adding a StateHasChanged or calling RefreshDataAsync in one place.

I'll see if the optimization we did can be made opt-in

Here is a comparison I created between version 4.12 and 4.11.7.
Some key points:

DateTimeOffset is used as the default sorting field with descending direction.

The behavior is exactly the same between both versions when dealing with small datasets. I'm not exactly sure about the limit, but you previously mentioned it was 250. In my testing, the value around 500.

Based on testing, the operation completes, but the table data does not change at all, meaning the DataGrid does not refresh even when items are modified—if the item count exceeds 250.

Calling StateHasChanged has no effect.

It's the RefreshDataAsync call that triggers the table and data to be fully reloaded; only then does the item count update and new entries appear.

So, new data is not simply appended to the end of the table. Instead, the data is not added at all / Fluent does not reload until RefreshDataAsync is explicitly called. This is why a search query can trigger the reload.

Repos link:
https://github.com/MmMapIoSpace/FluentUIDataGrid

• Test on Weather pages

bandicam.2025-06-15.13-30-14-474.mp4

I'm not entirely sure about the performance impact of this update, but from the client's perspective, I feel it's somewhat irrelevant when we are required to explicitly call RefreshDataAsync once the data count exceeds 250.

If a manual call is necessary, then it would be better to not have the 250 threshold at all — it should either always refresh automatically regardless of the item count, or require explicit interception when a refresh is needed. The threshold value can be a bit confusing, especially considering that we already have multiple options for supplying the data provider.

So, if we are providing an IQueryable property, in my opinion, it would be much better if Fluent handled the refresh process entirely automatically. That said, this is just my perspective — I'm not entirely certain about the detailed performance impact.

[vnbaaij]

I'm adding an IsFixed parameter with PR #3921. We'll revert to the 4.11.9 behavior by default (IsFixed="false") and you can manually set it to true if you know your data is static and you do not need to have it refreshed during the grid's lifetime.