FluentUI Blazor 组件中 Select 控件的无限递归问题解析

问题现象

在使用 FluentUI Blazor 的 Select 组件时，当用户尝试在 SelectedOptionChanged 事件处理程序中修改当前选中的值而非直接使用用户选择的值时，在 WebAssembly 模式下会出现无限递归的问题。

问题复现

假设我们有一个包含三个选项的 Select 组件："A"、"B"和"Still A"。当用户选择"Still A"时，我们希望实际选中的是"A"而非"Still A"。在 Blazor WebAssembly 模式下，这种操作会导致无限递归。

技术分析

这种无限递归现象源于 Blazor 的渲染机制和组件生命周期：

1. 用户选择"Still A"触发 SelectedOptionChanged 事件
2. 事件处理程序将选中值改为"A"
3. 组件检测到值变化，触发重新渲染
4. 重新渲染后，Select 组件再次触发 SelectedOptionChanged 事件
5. 循环往复，形成无限递归

值得注意的是，这个问题仅在 WebAssembly 模式下出现，在 Blazor Server 模式下不会发生。这是因为 WebAssembly 的渲染和事件处理是即时且同步的，而 Server 模式存在网络延迟，打破了这种即时循环。

官方立场

FluentUI Blazor 维护团队认为：

1. Select 组件的主要设计目的是作为表单输入控件使用
2. 修改用户选择的值超出了组件的基本设计用途
3. 团队不会为所有可能的用例场景提供支持

解决方案

虽然官方不建议这种用法，但开发者可以通过以下方式实现需求：

使用 @key 指令强制 Blazor 在值变化时创建新的 Select 组件实例，而非重用现有实例：

<FluentSelect @key="version" TOption="string" Items="items" 
              SelectedOption="selected" SelectedOptionChanged="Change"></FluentSelect>

@code {
    string[] items = ["A", "B", "Still A"];
    int version = 0;
    string selected = "A";
    
    void Change(string value) {
        if (value == "Still A") {
            selected = "A";
        } else {
            selected = value;
        }
        version++;
    }
}

这种方法通过每次值变化时递增 version 变量，使 Blazor 创建新的 Select 组件实例，从而避免了递归问题。

最佳实践建议

1. 尽量避免在事件处理程序中修改用户选择的值
2. 如果必须修改，考虑使用数据预处理或过滤的方式
3. 对于复杂的选择逻辑，可以考虑使用自定义组件
4. 注意 WebAssembly 和 Server 模式下的行为差异

总结

FluentUI Blazor 的 Select 组件设计主要用于标准表单输入场景。当开发者尝试实现更复杂的交互逻辑时，可能会遇到 WebAssembly 模式下的无限递归问题。虽然可以通过技术手段解决，但从架构设计角度，建议重新评估这种需求的必要性，寻找更符合组件设计初衷的实现方式。