Skip to content

DialogService: Add title-less ShowAsync<T> overloads for options and parameters - #13501

Merged
danielchalmers merged 1 commit into
MudBlazor:devfrom
danielchalmers:daniel/dialog-titleless-showasync
Jul 18, 2026
Merged

DialogService: Add title-less ShowAsync<T> overloads for options and parameters#13501
danielchalmers merged 1 commit into
MudBlazor:devfrom
danielchalmers:daniel/dialog-titleless-showasync

Conversation

@danielchalmers

@danielchalmers danielchalmers commented Jul 18, 2026

Copy link
Copy Markdown
Member

Description

Adds two title-less generic ShowAsync<T> overloads to IDialogService / DialogService:

  • ShowAsync<T>(DialogOptions options)
  • ShowAsync<T>(DialogParameters parameters, DialogOptions options)

Today a dialog can be opened with parameters but no title via the existing ShowAsync<T>(DialogParameters), but there is no equivalent for passing DialogOptions (or parameters + options) without a title, so callers have to pass an explicit null/empty title. These overloads round out the generic set and forward using string.Empty, matching the convention already used by ShowAsync<T>() and ShowAsync<T>(DialogParameters).

Non-breaking (default interface methods)

The two new members are declared as default interface methods on IDialogService, so existing hand-written IDialogService implementations keep compiling with no changes; DialogService still provides concrete overrides. This came directly out of dogfooding: adding them as plain abstract members broke a downstream app's hand-rolled IDialogService test double (CS0535). The default bodies avoid that while keeping the overloads on the interface, consistent with the rest of the ShowAsync family. (Happy to switch these to plain abstract members if you'd prefer to treat it as a normal interface-growth breaking change.)

Scope

Limited to the generic ShowAsync<T> family, not the Type-based ShowAsync(Type, ...) family. The generic family already has a title-less overload (ShowAsync<T>(DialogParameters)), so ShowAsync<T>(null) is already ambiguous and these additions introduce no new ambiguity. The Type-based family has no title-less overload today, so adding one would newly make ShowAsync(type, null) ambiguous between string? title and a reference-typed parameter, a source-breaking change. Keeping this to the generic form makes it purely additive.

Tests

Added DialogTests.ShowAsync_TitlelessOverloads_ForwardOptionsAndParameters (both overloads open a dialog with no title and forward options + parameters). Also validated end-to-end by consuming a locally-built package from a downstream .NET MAUI Blazor app (JournalApp): a bUnit test opens a dialog via the native ShowAsync<T>(DialogOptions) (the app's former extension-method workaround removed), and the app's hand-rolled IDialogService implementation compiles unchanged. Verified on net10.0.

…parameters

Adds ShowAsync<T>(DialogOptions) and ShowAsync<T>(DialogParameters, DialogOptions), mirroring the existing title-less ShowAsync<T>(DialogParameters) overload so callers can pass options (or parameters and options) without supplying an empty title. Both forward to the titled implementations using string.Empty, matching the existing convention.
@mudbot mudbot Bot added API change Modifies the public API surface in a non-breaking way (ex: adds a new property) enhancement Adds a new feature or enhances existing functionality (not fixing a defect) in the main library labels Jul 18, 2026
@danielchalmers
danielchalmers merged commit cc14900 into MudBlazor:dev Jul 18, 2026
11 checks passed
@danielchalmers
danielchalmers deleted the daniel/dialog-titleless-showasync branch July 18, 2026 13:59
This was referenced Aug 5, 2026
This was referenced Aug 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

API change Modifies the public API surface in a non-breaking way (ex: adds a new property) enhancement Adds a new feature or enhances existing functionality (not fixing a defect) in the main library

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant