[Bug]: DataGrid DetailsRowTemplate doesn't show if event calls Mediator.Send (MediatR)

[joergkrause]

Blazorise Version

1.4.2

What Blazorise provider are you running on?

Bootstrap5

Link to minimal reproduction, or a simple code snippet

https://github.com/joergkrause/BlazorizeMediatRIssue.git

Steps to reproduce

Using the repo, on start page is a simple DataGrid. Click a row --> template details appear. Set checkbox (this let the SelectedRowChanged event forward a call to Mediator.Send. This executes fine, but it somehow "eats" the event to open the details template. The code definitely returns.

This is basic grid definition:

<DataGrid TItem="WeatherForecast" SelectedRow="@State.Selected" SelectedRowChanged="@SetSelected" Data="@State.AllItems"

This is the event handler:

async Task SetSelected(WeatherForecast archive)
{
  if (c)
  {
    await Mediator.Send(new WeatherState.SetSelected.SetAction { Item = archive });
  }
}

if c==true it's in error, if c==false it works. Mediator.Send itself works and does what's supposed to do (call the handler code and executes it).

What is expected?

Detailsrowtemplate becomes visible on click, regardless the actions in the handler function (as along as without errors)

What is actually happening?

Detailsrowtemplate becomes not visible on click, if the handler contains a call to Mediator.Send from MediatR library.
There is no error or warning or exception.

What browsers are you seeing the problem on?

No response

Any additional comments?

The effect is only on "open" / "show". If the detailstemplate is already visible and you turn the error on, it closes as expected. After this, it doesn't open again. From that I assume that's not really an "eaten" event.

[David-Moreira]

Hello @joergkrause
It's verified that the object reference for the Selected Item is not contained in the AllItems.
I have to say, I don't fully understand how that library works behind the scenes, but if new object references are being generated, I guess this can happen.

I solved your issue by just loading the data outside of the MediaR usage. This makes sure the object references don't change.

So it seems like to me that the DataGrid is working as expected with what's bound reference wise.

Let us know if this helps.

[joergkrause]

Thanks for digging into this. It's weird that I used Fluxor now whoch has a similar approach and don't see the effect there. I'm going to reach out to the MediatR guys to see whether they can have a look.
However, the approach to exclude the data from state feels wrong and makes the whole code more complex.

Also, as far as I remember in Blazor the @key property can be set to anything to handle such scenario. Would that be possible in the Grid here?

[David-Moreira]

Thanks for digging into this. It's weird that I used Fluxor now whoch has a similar approach and don't see the effect there. I'm going to reach out to the MediatR guys to see whether they can have a look.

Well I guess you're just further concluding that something with the MediatR internals works differently then what we would be expecting. I'm guessing it somehow produces different in memory references. I would expect that they would be the same, but maybe that's something that can be configurable, or maybe even a conscious part of their implementation for some special reason.

I would try to focus on the MediaR object reference thing, and show them an example where the original reference you gave it is lost. I would make sure you take as many things out of the equation as possible and nothing in your code is producing those "unexpected" results before giving them the example.
Keep us updated.

---

This Key implementation would be different then the @key property reserved for Blazor.
It could also be named Id, but I think Key better represents it. I'm thinking that you could even bind something like a complex key or something. So Func<TItem,object> would work nicely I think?
It does not necessarily need to be named Key either, we usually use verbs as suffixs to represent Func, i.e KeyGetter KeyAccessor etc..

[github-actions]

This is an automated message reminding that this issue is expecting the author's answer.