You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When using RadzenDropDown to make multiple selections bound to a collection, with AllowClear set to true, a user can click to clear all choices from the collection. This results in the bound collection property being set to null, instead of clearing the collection entries. I understand this may be by design, but, especially when using nullable annotations in a codebase, results in easy-to-miss null reference exceptions.
To Reproduce
Steps to reproduce the behavior:
public class Foo
{
public ICollection<string> Settings { get; set; } = new List<string>();
}
var foo = new Foo() { Settings = ["Two"] };
var values = new string[] { "One", "Two", "Three" };
<RadzenDropDown Multiple="true" AllowClear="true" @bind-Value="@foo" Data="@values" />
After clicking the X in the control to clear the selections, foo.Settings is null instead of an empty collection.
Expected behavior
If the property bound to value started as a non-null collection instance, I would expect that collection to remain, but be empty.
I understand this may be breaking behavior, so, as a potential mitigation, if the property bound to value started as null, we could have that property be set to null on clear...
Additional context
If this is something the team is ok changing, let me know and I'm happy to post a PR.
The text was updated successfully, but these errors were encountered:
Blazor bindings works only null/not null expression - they will not understand if a property is collection, if you clear the collection, remove or add items. We prefer not to do that since it will be exception compared to all other two-way bindings.
Describe the bug
When using
RadzenDropDown
to make multiple selections bound to a collection, withAllowClear
set to true, a user can click to clear all choices from the collection. This results in the bound collection property being set to null, instead of clearing the collection entries. I understand this may be by design, but, especially when using nullable annotations in a codebase, results in easy-to-miss null reference exceptions.To Reproduce
Steps to reproduce the behavior:
After clicking the X in the control to clear the selections,
foo.Settings
is null instead of an empty collection.Expected behavior
If the property bound to value started as a non-null collection instance, I would expect that collection to remain, but be empty.
I understand this may be breaking behavior, so, as a potential mitigation, if the property bound to value started as null, we could have that property be set to null on clear...
Additional context
If this is something the team is ok changing, let me know and I'm happy to post a PR.
The text was updated successfully, but these errors were encountered: