starred/radzen-blazor
1
0
Fork 0
mirror of https://github.com/radzenhq/radzen-blazor.git synced 2026-02-04 05:35:44 +00:00
Code Issues 1.3k Packages Projects Releases 22 Wiki Activity

[PR #2051] [MERGED] Enhance dialog options with property change notifications to support automatic UI updates #3055

New Issue
Open
opened 2026-01-29 18:21:42 +00:00 by claunia · 0 comments
claunia commented 2026-01-29 18:21:42 +00:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/radzenhq/radzen-blazor/pull/2051
Author: @JvanderStad
Created: 3/23/2025
Status: ✅ Merged
Merged: 3/24/2025
Merged by: @enchev

Base: master ← Head: development/jeffrey/notify-change-dialog-change

📝 Commits (4)

  • bd2f98d Enhance dialog options with property change notifications
  • 7b6b9a2 Update dialog properties and functionality
  • dd065a3 Add unit tests and improve DialogService options handling
  • 40a44a7 Allow internal methods visibility for unit tests

📊 Changes

7 files changed (+931 additions, -183 deletions)

View changed files

➕ Radzen.Blazor.Tests/DialogServiceTests.cs (+287 -0)
📝 Radzen.Blazor/DialogService.cs (+579 -170)
📝 Radzen.Blazor/Radzen.Blazor.csproj (+6 -0)
📝 Radzen.Blazor/Rendering/DialogContainer.razor (+26 -0)
📝 RadzenBlazorDemos/Pages/DialogPage.razor (+2 -2)
📝 RadzenBlazorDemos/Pages/DialogWithCascadingValueCaller.razor (+2 -2)
📝 RadzenBlazorDemos/Pages/DialogWithCascadingValueImplementation.razor (+29 -9)

📄 Description

Implemented INotifyPropertyChanged in DialogOptionsBase and DialogOptions to support automatic UI updates for dialog properties.

  • The DialogOptionsBase and DialogOptions classes now implement INotifyPropertyChanged, allowing dynamic updates to dialog properties to reflect immediately in the UI.
  • Subscribed to the PropertyChanged event in DialogContainer.razor, triggering StateHasChanged() automatically when any dialog property changes.
  • As a result, calling DialogService.Refresh(); manually after changing a dialog property is no longer necessary — UI updates will happen automatically.

Updates to Dialog Methods

  • The OpenDialog, Confirm, and Alert methods previously created a new DialogOptions instance based on an existing one, which resulted in property values being reset.
  • This behavior has been changed: the original DialogOptions instance is now used if provided, ensuring that PropertyChanged subscriptions remain intact.
  • If no DialogOptions are passed, a new instance will still be created — the same null-check logic and default value assignments remain in place.
  • In DialogService.cs, method signatures for OpenAsync, Confirm, and Alert are updated to include an optional CancellationToken parameter for cancellation control (used in unit tests)
  • The visibility of the private OpenDialog method is changed to internal, making it accessible for testing.

Updated Dialog page to reflect changes

image

Unit tests

  • Allow internal methods visibility for unit tests
    • Added an ItemGroup in the project file to include an InternalsVisibleTo attribute for the Radzen.Blazor.Tests assembly, enabling unit tests to access internal methods.
  • Add unit tests and improve DialogService options handling
    • Focusing on DialogOptions, ConfirmOptions, and AlertOptions. The tests ensure default values are set correctly, provided values are retained, and null options are handled.

image

Question ❓

Is there a specific reason the original implementation created a new instance of DialogOptions, even when one was already provided?
As far as I can tell, this was primarily to ensure default values were applied — but I'm wondering if there are any other reasons I might have overlooked.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/radzenhq/radzen-blazor/pull/2051 **Author:** [@JvanderStad](https://github.com/JvanderStad) **Created:** 3/23/2025 **Status:** ✅ Merged **Merged:** 3/24/2025 **Merged by:** [@enchev](https://github.com/enchev) **Base:** `master` ← **Head:** `development/jeffrey/notify-change-dialog-change` --- ### 📝 Commits (4) - [`bd2f98d`](https://github.com/radzenhq/radzen-blazor/commit/bd2f98d6881b8cf483d1e28d8e69f017b6fe274a) Enhance dialog options with property change notifications - [`7b6b9a2`](https://github.com/radzenhq/radzen-blazor/commit/7b6b9a2e4435dff323f711991c5e3e4239bb5b2b) Update dialog properties and functionality - [`dd065a3`](https://github.com/radzenhq/radzen-blazor/commit/dd065a38a8123ae2f6cf78913a8ed3c914587b34) Add unit tests and improve DialogService options handling - [`40a44a7`](https://github.com/radzenhq/radzen-blazor/commit/40a44a7077a590168e28e4bd1cc3c2fa82e0630e) Allow internal methods visibility for unit tests ### 📊 Changes **7 files changed** (+931 additions, -183 deletions) <details> <summary>View changed files</summary> ➕ `Radzen.Blazor.Tests/DialogServiceTests.cs` (+287 -0) 📝 `Radzen.Blazor/DialogService.cs` (+579 -170) 📝 `Radzen.Blazor/Radzen.Blazor.csproj` (+6 -0) 📝 `Radzen.Blazor/Rendering/DialogContainer.razor` (+26 -0) 📝 `RadzenBlazorDemos/Pages/DialogPage.razor` (+2 -2) 📝 `RadzenBlazorDemos/Pages/DialogWithCascadingValueCaller.razor` (+2 -2) 📝 `RadzenBlazorDemos/Pages/DialogWithCascadingValueImplementation.razor` (+29 -9) </details> ### 📄 Description **Implemented `INotifyPropertyChanged` in `DialogOptionsBase` and `DialogOptions` to support automatic UI updates for dialog properties.** - The `DialogOptionsBase` and `DialogOptions` classes now implement `INotifyPropertyChanged`, allowing dynamic updates to dialog properties to reflect immediately in the UI. - Subscribed to the `PropertyChanged` event in `DialogContainer.razor`, triggering `StateHasChanged()` automatically when any dialog property changes. - As a result, calling `DialogService.Refresh();` manually after changing a dialog property is no longer necessary — UI updates will happen automatically. ### Updates to Dialog Methods - The `OpenDialog`, `Confirm`, and `Alert` methods previously **created a new `DialogOptions` instance based on an existing one**, which resulted in property values being reset. - This behavior has been changed: the **original `DialogOptions` instance is now used** if provided, ensuring that `PropertyChanged` subscriptions remain intact. - If no `DialogOptions` are passed, a new instance will still be created — the same null-check logic and default value assignments remain in place. - In `DialogService.cs`, method signatures for `OpenAsync`, `Confirm`, and `Alert` are updated to include an optional `CancellationToken` parameter for cancellation control (used in unit tests) - The visibility of the `private` `OpenDialog` method is changed to `internal`, making it accessible for testing. ### Updated `Dialog` page to reflect changes ![image](https://github.com/user-attachments/assets/270f60ea-bde1-448b-80c9-7957691ba9ac) ### Unit tests - Allow `internal` methods visibility for unit tests - Added an `ItemGroup` in the project file to include an `InternalsVisibleTo` attribute for the `Radzen.Blazor.Tests` assembly, enabling unit tests to access internal methods. - Add unit tests and improve DialogService options handling - Focusing on `DialogOptions`, `ConfirmOptions`, and `AlertOptions`. The tests ensure default values are set correctly, provided values are retained, and null options are handled. ![image](https://github.com/user-attachments/assets/6dd26e21-e514-4cfb-9090-3d555f84d3fe) ### Question ❓ Is there a specific reason the original implementation created a *new* instance of `DialogOptions`, even when one was already provided? As far as I can tell, this was primarily to ensure default values were applied — but I'm wondering if there are any other reasons I might have overlooked. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-29 18:21:42 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
enhancement
good first issue
pull-request
Mirrored from GitHub Pull Request
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/radzen-blazor#3055
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?