Interesting that the sync version Show fails, while async doesn't. Forgot to update it's code...
But before I invest more time in this and add tests for #10036 (works visually)
I need to know if we event want such fundamental changes.
@henon @danielchalmers

Please read carefully the description.

1. Introducing GetOptions() in the MudDialogInstance to return _dialogOptionsState.Value.

Isn't this the easiest solution?

I decided that the most appropriate solution is to introduce two-way binding for the parameters we modify.
To achieve this, I had to create an additional layer, MudDialogInstanceParent, because for two-way binding to work, I need a reference to ComponentBase.

Are you sure this is worth it? I mean if a simple GetOptions() can do the job why complicate things with two-way bindings?

Codecov Report

Attention: Patch coverage is 77.21519% with 18 lines in your changes missing coverage. Please review.

Project coverage is 91.15%. Comparing base (336434d) to head (6266371).
Report is 6 commits behind head on dev.

@@            Coverage Diff             @@
##              dev   #10066      +/-   ##
==========================================
+ Coverage   91.13%   91.15%   +0.02%     
==========================================
  Files         410      411       +1     
  Lines       12459    12466       +7     
  Branches     2419     2419              
==========================================
+ Hits        11354    11364      +10     
+ Misses        560      557       -3     
  Partials      545      545              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Are you sure this is worth it? I mean if a simple GetOptions() can do the job why complicate things with two-way bindings?

Obviously, GetOptions would be the easiest solution. However, looking from a user perspective, it’s not logical to have two options: Options and GetOptions. People typically do not read breaking change documentation unless something fails to compile, and they often do not look examples either. We get a lot of issues because of that.
If we simply add GetOptions, existing code that uses Options will break, and users might not even notice the problems. I would prefer a more complicated solution on our side if it offers an intuitive API for consumers.
Sadly, you cannot hide a component's parameters, I would agree on this solution if it was possible.
However, I can suggest an alternative approach. Exposing MudDialogInstance was a poor decision from the start, as it is a Blazor component and allowing access to the parent's parameters is a code smell.

We can create a IMudDialogInstance, which exposes only the necessary stuff, and MudDialogInstance can implement this interface. Its explicit implementation will return _dialogOptionsState.Value for Options. We also change CascadingValue to <CascadingValue Value="((IMudDialogInstance)this)" IsFixed="true">.

We will also need to rename the current MudDialogInstance (I’m unsure what to name it) so that users gets a compilation error to force them to change to the new usage from MudDialogInstance to IMudDialogInstance. This way everything will be more beautiful ;)

We will also need to rename the current MudDialogInstance (I’m unsure what to name it)

Maybe MudDialogInstanceInternal or just DialogInstance ?

Maybe MudDialogInstanceInternal or just DialogInstance ?

Ig, we can discuss it once the implementation is ready.

@henon, done. Called it MudDialogContainer.

Haha, after this change, I want to rewrite the dialogs, especially finally add a IDialogReference<T> that points to a non-generic IDialogReference. Then, you'd return IDialogReference<T> for all ShowAsync<T> APIs and IDialogReference for ShowAsync(Type component). This way, there would be no more Dialog as an object and no more casts. However, it would break the promise of no huge rewrites in v8. Since dialogs are a core part of the system, it would also require a clean up the old API, so I guess I’ll save it for next time.

For now, I'm casting IMudDialogInstance to MudDialogContainer to access HandleKeyDownAsync

However, when I will rewrite this for v9, I will use KeyInterceptorService directly. In my opinion, bUnit tests should be closer to real conditions. We rely too much on invoking internal methods directly instead of simulating actions via bUnit.

@henon, done. Called it MudDialogContainer.

That is a great name

Ideas for v9:

1. Implement more strongly typed interfaces, such as IDialogReference<T> and potentially IDialogResult<T>.
2. Introduce MudGlobal for global settings, instead of using cascading parameters.
3. Remove the old API.
4. IDialogReference should not expose InjectDialog or InjectRenderFragment, as these are only used internally within the service. Therefore, the public IDialogReference should not expose them, as they can be dangerous, however, the implementation of this interface can expose them.
5. The DialogService should maintain a list of current dialogs. Currently, this is handled in the dialog provider via DialogInstanceAddedAsync and OnDialogCloseRequested, but we should align the API more closely with IPopoverService, which manages this logic. Providers should only be responsible for displaying the dialogs.
6. Address the issue of TitleContent not updating automatically, which requires calling MudDialog.StateHasChanged. If this cannot be resolved, consider adding a base class, BaseDialogSomething, which would be an optional base class that provides a more user-friendly API and includes IMudDialogInstance, Cancel and MudDialog.StateHasChanged as just StateHasChanged, etc., automatically.
7. Make sure API for getting the dialog return value is intuitive. Currently you have to do something like instance.Result.Result which is horrible.

LGTM

I will add test for #10036 and then merge it.

Great, I added a point to the ideas:

7. Make sure API for getting the dialog return value is intuitive. Currently you have to do something like instance.Result.Result which is horrible.

Added to the v8 migration guide at #9953

We ran into a minor issue with unit testing some of our dialogs using bunit. We rendered the dialog instance cascading value in the unit tests previously using MudDialogInstance and the change to IMudDialogInstance prevents rendering. The simple fix was to render it in the unit test using MudDialogContainer which I found in this thread. Something that others might also run into.