Let InputFile's AdditionalAttributes be of type `IReadOnlyDictionary<string object>?`

[RiRiSharp]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I'm building a component library and want to reuse ASP.NET Core's input components as much as possible. I created a base class like this:

public class LibraryBaseComponent {
    [Parameter(CaptureUnmatchedValues = true)]
    public IReadOnlyDictionary<string, object>? AdditionalAttributes { get; set; }
    //...
}

Since multiple inheritance isn't possible, I use an interface with the same property. This works well, except for InputFile, which uses IDictionary<string, object>? instead of IReadOnlyDictionary<string, object>?.

This inconsistency makes integration harder and seems arbitrary.

Describe the solution you'd like

Update InputFile to use IReadOnlyDictionary<string, object>? for AdditionalAttributes, aligning it with other components. Ideally, this pattern would be consistent across all ASP.NET Core components.

Additional context

No response

[javiercn]

@RiRiSharp thanks for contacting us.

Unfortunately, that would be a breaking change that we aren't willing to take unless we have stronger reasons to do so, as it breaks binary compatibility unnecessarily with newer versions.

[RiRiSharp]

Allright, I was afraid so. I am still curious whether this was an intentional design decision or not. Thanks for the reply!

[kodonaut]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I'm building a component library and want to reuse ASP.NET Core's input components as much as possible. I created a base class like this:

public class LibraryBaseComponent {
[Parameter(CaptureUnmatchedValues = true)]
public IReadOnlyDictionary<string, object>? AdditionalAttributes { get; set; }
//...
}
Since multiple inheritance isn't possible, I use an interface with the same property. This works well, except for InputFile, which uses IDictionary<string, object>? instead of IReadOnlyDictionary<string, object>?.

This inconsistency makes integration harder and seems arbitrary.

Describe the solution you'd like

Update InputFile to use IReadOnlyDictionary<string, object>? for AdditionalAttributes, aligning it with other components. Ideally, this pattern would be consistent across all ASP.NET Core components.

Additional context

No response

Sorry if this is a dumb question — I'm still a beginner — but why should the dictionary entries be readonly?
I mean, isn't it valid to want to modify them?
I can imagine writing a Blazor component that needs to dynamically change an attribute at runtime.

[RiRiSharp]

It's not a dumb question but I'm not sure I have the complete knowledge to answer this.
That being said, the first thing to note is that all the other input components do utilize the IReadOnlyDictionary, as do NavLink, EditForm, ValidationMessage, for example.

I think the underlying assumption in all of these cases is that the AdditionalAttributes are set by the user of the component. If you make it a IReadOnlyDictionary you sort of make a promise to that user, and to yourself, that you leave that dictionary intact. We can see in InputBase.cs that this is exactly what ASP.NET Core does:

    protected string CssClass
    {
        get
        {
            var fieldClass = EditContext?.FieldCssClass(FieldIdentifier);
            return AttributeUtilities.CombineClassNames(AdditionalAttributes, fieldClass) ?? string.Empty;
        }
    }

It creates a new property CssClass which combines both the user supplied class attribute with the CSS class for the (in)validity of the input, without making any modifications to AdditionalAttributes itself. When rendering an input component a component is rendered using the (simplified) Blazor code: <input @attributes="AdditionalAttributes" class="@(CssClass)" />. Keep in mind that a later attribute specification overwrites earlier specifications, so the rightmost one "wins".

Also, I ran into a bug a few days ago, where I did not treat it as read-only, and I did something like the following:

    protected override void OnParametersSet()
    {
        base.OnParametersSet();
        var classes = DetermineClasses();
        AdditionalAttributes = AddClasses(AdditionalAttributes, classes);
    }

    internal static Dictionary<string, object> AddClasses(Dictionary<string, object> additionalAttributes, string classes)
    {
        var dictionary = additionalAttributes?.ToDictionary() ?? new Dictionary<string, object>();
        if (dictionary.TryGetValue("class", out var existingClass))
        {
            dictionary["class"] = $"{existingClass} {classes}";
        }
        else
        {
            dictionary["class"] = classes;
        }
        
        return dictionary;
    }

Now, every time the OnParametersSet gets called, classes gets appended to all the already existing classes. But after the first call, classes is already part of AdditionalAttributes["class"], creating a longer and longer class name each time the function gets called. Would I have respected the read-onlyness of the dictionary, and created a similar property like CssClass, this would not have occurred.

I hope my answer gives at least some insight into why they are possibly using the IReadOnlyDictionary instead of IDictionary.

[kodonaut]

@RiRiSharp

Yes, I see, I was going through the source code and you’re right that inputFile is the only one that doesn’t have a read-only dictionary :) besides, it hardly does anything with that parameter except passing it to the builder. Thanks for the explanation, it’s interesting to me.

[dotnet-policy-service]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.