[Feature] Support enumerable/collection interfaces for bindable parameters/`EventCallback<T>`

[bzd3y]

Currently Razor doesn't seem to support binding to a parameter that is a generic collection interface from something that implements that interface. It will produce an error along the lines of:

Argument 10: cannot convert from 'Microsoft.AspNetCore.Components.EventCallback<System.Collections.Generic.List>' to 'Microsoft.AspNetCore.Components.EventCallback<System.Collections.Generic.IEnumerable>'

Of course this issue isn't specific to collections (or interfaces), but they seem to be the area that would require the least amount of effort while also providing the most value.

Two things that come to mind:

1. EventCallback<T> may need to be made covariant (or maybe I am reversing that)?
2. Or, perhaps the code generator just needs to pay attention to the type of the parameter instead of the type of the object it is being bound to?

In both cases, the generated delegate would need to know to handle the "known" collections and their conversions, i.e. use methods like Enumerable.ToList() when necessary.

A simplified but contrived example:

@code
{
    List<string> strings = [ "a", "bunch", "of", "strings" ];
    HashSet<string> importantStrings = [];
}
@* FindImportantStrings.ImportantStrings is a [Parameter]IEnumerable<string>*@
<FindImportantStrings AllStrings="strings" @bind-ImportantStrings="importantStrings" />

This would generate an error like the one above, which forces components to be opinionated/lock down the types of collections the consuming developer uses or the author has to create a variant of the component for each type of collection they might want to support.

It's probably worth pointing out that AllStrings could also be an IEnumerable<string> and, as we would expect, there is no problem assigning a List<string> to it.

But it seems like all (easier said than done, I'm sure) that needs to happen is that the code generator could check the types involved and see if they are different and if they are, then generate code that:

1. Calls the appropriate Enumerable conversation method.
2. Or, ideally, just uses the spread operator and lets the compiler take care of calling the appropriate conversion method.

Possible problems: I suppose it is possible that there are some semantics with binding that require or expect the source and destination to be the same object and not copies, at least in the case of reference types. If that is the case, then maybe there could just be some way to opt in (or out?) to this, e.g. [Parameter(convertCollections = true)].

[davidwengier]

@bzd3y Could you post a more complete example please, including the FindImportantStrings component? Perhaps even a whole repo project.

[bzd3y]

Hmm, this makes me think I might be missing something. I'm not sure there is much more to an example. The FindImportantStrings component was just something I completely made up, but maybe it caused confusion. I actually deliberately avoided fleshing it out because I think one of the principles involved here is that the internals of the component don't (read: shouldn't) matter, like whether it uses a List<string> or a HashSet<string> internally.

With that being said, I think it could look something like this:

@code
{
    private List<string> _importantStrings = [];

    [Parameter]
    public IEnumerable<string> AllStrings { get; set; }
    [Parameter]
    public IEnumerable<string> ImportantStrings { get; set; }
    [Parameter]
    public EventCallback<IEnumerable<string>> ImportantStringsChanged { get; set; }

    public async Task AddImportantStringAsync(string value)
    {
        _importantStrings.Add(value);

        await ImportantStringsChanged.InvokeAsync(_importantStrings); // the consumer might save these to a database or something, display them elsewhere on the page or do something else with them.
    }
    public async Task RemoveImportantStringAsync(string value)
    {
        _importantStrings.Remove(value);

        await ImportantStringsChanged.InvokeAsync(_importantStrings); // the consumer might save these to a database or something, display them elsewhere on the page or do something else with them.
    }
}

<div>
    @foreach (string value in AllStrings)
    {
        <div>Is &qt;@(value)&qt; an important string?
            <button @onclick="async () => await AddImportantStringAsync(value)">Yes</button>
            <button @onclick="async () => await RemoveImportantStringAsync(value)">No</button>
        </div>
    }
<div>

Hopefully this all "compiles" and more or less fits my first example. But the overall idea is that a component like this shouldn't have to care what kind of collection the consuming code uses, nor should it force them to use a particular collection type.

[davidwengier]

Thanks, that does indeed demonstrate the issue and fail to compile. Essentially within the generated code, when ImportantStringsChanged fires, it needs to do Component.importantStrings = FindImportantStrings._importantString, which is trying to assign a List to a HashSet, and obviously fails. I think us fixing this is unlikely because it could trivially cause data loss, and also breaks user expectations of referential integrity. I bind my list to the control, I change item 0 in my list, but the control doesn't change because its not bound to the list at all, but rather to an intermediate collection that the compiler generated.

Additionally, changing your Razor file to the below compiles fine:

@code
{
    List<string> strings = [ "a", "bunch", "of", "strings" ];
    HashSet<string> importantStrings = [];
}
<FindImportantStrings 
    AllStrings="strings" 
    @bind-ImportantStrings:get="(IEnumerable<string>)importantStrings"
    @bind-ImportantStrings:set="s => importantStrings = [.. s]"
    />

That puts you in control of deciding how a list should be mapped to a hashset etc., whether you care references being consistent etc.

BUT having said that, we can leave this open and gauge the community demand.