希望优化 Autocompletes 组件性能

[LittleFish-233]

如果候选列表项目过多，会出现明显卡顿

例如以下代码：

<MCard Class="mb-4">
    <MCardTitle>Masa Blazor</MCardTitle>
    <MCardText>
        @foreach (var item in _items)
        {
            <MAutocomplete @bind-Value="item.Text"
                           Items="_autoCompleteItems"
                           ItemText="r=>r"
                           ItemValue="r=>r"
                           Dense
                           Filled></MAutocomplete>
        }
        <MButton Color="primary" OnClick="OnClick">添加</MButton>
    </MCardText>

</MCard>

@code {
    List<Model> _items { get; set; } = new List<Model> { new Model() };

    List<string> _autoCompleteItems { get; set; } = new List<string>();

    protected override void OnInitialized()
    {
        _autoCompleteItems.Clear();
        foreach (var item in Enumerable.Range(1, 5000))
        {
            _autoCompleteItems.Add(Guid.NewGuid().ToString());
        }
    }

    private void OnClick()
    {
        _items.Add(new Model());

    }

    class Model
    {
        public string Text { get; set; }
    }

}

效果如下，可以观察到明显的卡顿

并且这种卡顿似乎会影响到页面的其他部分

稍微提一下下，BootstrapBlazor 的自动补全组件使用同样的数据量时很流畅，感觉不完全是动画的问题 不知道能不能在不显示下拉列表时不加载候选数据来缓解一下

[doddgu]

AutoComplete 前端渲染是需要取 top n 的，后端 like top n 返回。

我知道很多人想我们支持虚拟滚动，但我觉得这个问题也要反问一下，一次性返回这么大数据真的合适么？对于服务器来说是上行流量，是需要付出带宽费用的。

可能我们文档应该给出这个优化给出最佳实践。比如百度搜索框的autocomplete，我们希望开发者是有意识的理解autocomplete的使用场景是它应有的限制，而不是被我们吞掉。虽然这个实现很简单，但隐藏风险的背后是更昂贵的代价。

[OmidAtaei1984]

Hello. In some cases, such as choosing the names of cities in a country, it is necessary to retrieve a large amount of data. Another example can be searching in the phone book based on the name or family name of a person. If Cascade Dropdown can be used, this can be controlled to a large extent, but in some cases, there is no other choice but to download a large amount of information from the server.