Question

我对如何优化典型的数据驱动Blazor组件的渲染感到困惑。考虑以下简化的组件（部分）：

public partial class FooComponent: ComponentBase
{
    [Inject]
    protected IBarService BarService { get; set; }

    [Parameter]
    public string OptionalParameter1 { get; set; }

    [Parameter] 
    public string OptionalParameter2 { get; set; };

    protected IEnumerable<BarItem> Items { get; set; }

    protected override Task OnParametersSetAsync()
    {
        this.Items = await this.BarService.GetItemsAsync(this.OptionalParameter1, this.OptionalParameter2);
    }
}

该组件具有两个可选参数。它们通常可以是服务调用的一些过滤值。该组件无法知道父组件是否会设置任何这些参数（因为它们是可选的）。无论何时设置参数，组件都会通过（昂贵的）异步服务调用来检索BarItem个项目的列表。然后，组件标记将以某种方式呈现Items列表。

问题在于，每次设置参数时都会调用OnParametersSetAsync，从而导致组件重新呈现并进行另一个服务调用。我可以通过检查参数值是否已更改来部分优化此操作，但是仍然会有多个服务调用。

如果两个参数都未设置，则服务调用将发生一次（良好）。
如果设置了一个参数，则服务调用会发生两次（第一次是参数值错误）。
如果同时设置了两个参数，则服务调用会发生3次（参数值错误的前2次）。

在具有更多属性的实际组件中，这可能会迅速导致许多不需要的服务调用。如果对所有参数都调用一次OnParametersSetAsync，那将不是问题（我知道Blazor不能这样工作）。

我是否可以做些事情以确保仅使用正确的参数值进行一次服务调用？在我看来，这似乎是数据驱动组件中非常普遍的情况，如果无法（有效地）实现，这对于Blazor来说将是一个真正的缺点。

Answer 1

昨天在互联网焦点会议剃须刀上，丹尼尔·罗斯展示了类似的东西。要解决此问题，可以使用一个计时器，该计时器在每次设置其中一个参数时启动。并且，如果计时器达到时间限制，则调用搜索请求。这称为反跳。

Youtube link to the part

如果可以的话，我将尝试为该示例挖掘github存储库。

Blazor渲染优化了数据驱动组件

1 个答案: