我们如何在ItemProviderDelegate中等待Action/Effect的结果?

Question

在我的razor组件中，我使用Virtualize组件(这里的文档)和ItemsProviderDelegate, CC_2被实现为async方法，从API批量加载数据传输对象(dto)。该方法看起来像这样:

private async ValueTask<ItemsProviderResult<Dto>> LoadDtosAsync(ItemsProviderRequest request)
{
// Massage parameters and dispatch action
// _stateFacade is essentially a wrapper around 
// Dispatcher.Dispatch(new LoadDtosAction())
_stateFacade.LoadDtos(request.StartIndex, request.Count);
// I make the assumption here that 'IsLoading' is immediately 
// 'true' after the LoadDtosAction is dispatched. I think
// that this is probably a bad assumption because
// Dispatcher.Dispatch() is probably not synchronous
// under-the-hood.
// dtoState is an IState<Dto>
while(_dtoState.Value.IsLoading)
{
// My current 'solution' to wait for the data to be loaded.
await Task.Delay(100);
}
// Provide the items to the Virtualize component for rendering...
return new ItemsProviderResult<Dto>(
_dtoState.Value.VirtualizedDtos ?? new List<Dto>(),
_dtoState.Value.DtosServerCount ?? 0
);
}

这已被证明是一种有效的方法，可以在后端呈现来自模型集合的批量数据，这些数据可能非常大，同时保持请求大小较小。客户端应用程序一次只需要从API请求几个对象，而UI不需要愚蠢的"页面"。控件，用户可以直观地滚动显示数据的组件。

Fluxor用于管理客户端应用程序的状态，包括Virtualize组件请求的当前dto。这抽象了从API请求批量dto的逻辑，并允许根据哪个组件调度操作来触发副作用。

应用程序中的许多Action类型都有一个object? Sender属性，其中包含对发送动作的组件的引用。当发送所需操作的组件中的原始方法不需要返回操作的结果状态时，此方法有效。然后，效果可以根据发送动作的组件的类型调用回调方法，例如:

public class UpdateDtoEffect : Effect<UpdateDtoSuccessAction>
{
protected override async Task HandleAsync(UpdateDtoSuccessAction action, IDispatcher dispatcher)
{
var updateDtoForm = action.Sender as UpdateDtoForm;
if (updateDtoForm is not null)
{
await updateDtoForm.OnSuccessfulUpdate.InvokeAsync();
}
}
}

当OnSuccessfulUpdate被上述效果调用时，此操作的reducer将更新状态，以便回调方法可以依赖最新的状态信息。

一个ItemsProviderDelegate对这种方法提出了一个有趣的例外。为了正确实现委托，我们需要返回项目列表和服务器上可用项目的数量。此信息存储在此特性的状态中，当LoadDtosAction成功时，由reducer更新该状态。在当前的实现(上面一般表示)中，LoadDtosAsync方法做了两个我不喜欢的假设:

1. 状态值isLoading在LoadDtosAction被调度后立即设置为true。我不认为这总是正确的，所以组件有时会立即询问状态值来更新自己(这将导致显示先前的状态，而不是结果状态)。

2. 由此产生的动作减少-效应链将最终将状态isLoading的值更新为false。

是否有一种方法可以允许ItemsProviderDelegate实现调度LoadDtosAction和" wait"操作的结果返回ItemsProviderResult?

• 编辑-动作的流程看起来像这样:

LoadDtosAction => 
LoadDtosActionReducer (new state, 'isLoading':true) =>
LoadDtosActionEffect (performs asynchronous API call) =>
LoadDtosSuccessAction =>
LoadDtosSuccessActionReducer (new state, 'VirtualizedDtos':{IEnumerable<Dto>}, 'DtosServerCount':{int})
LoadDtosSuccessEffect (perform optional asynchronous callbacks to 'Sender')

Answer 1

我觉得你可以这样做

1. 在你的组件中添加一个TaskCompletionSource<ItemsProviderResult<Employee>>成员
2. 在LoadDtosAsync调度中，有一个包含对TaskCompletionSource
引用的属性的动作。
3. TaskCompletionSource

UI端完成了，现在是store部分

[ReducerMethod(typeof(LoadDtosAction))]
public static MyState ReduceLoadDtosAction(MyState state) => state with {IsLoading = true };
[ReducerMethod(typeof(LoadDtosActionResult))]
public static MyState ReduceLoadDtosActionResult(MyState state) = state with {IsLoading = false; }
[EffectMethod]
public async Task HandleLoadDtosAsync(LoadDtosAction action, IDispatcher dispatcher)
{
var yourData = await HttpClient.GetJson(............);
action.TaskCompletionSource.SetResult(yourData);
Dispatcher.Dispatch(new LoadDtosActionResult()); // Just to set IsLoading = false;
}

请注意，这是可以的，因为尽管TaskCompletionSource可以被认为是可变状态，但我们并没有将它存储在Store本身中——我们只是在动作状态(可以保存可变数据)中传递它。

Answer 2

对于未来的考古学家，我能想到的最佳解决方案是通过DI将Fluxor的IActionSubscriber添加到我的组件中(使用由redux状态管理的虚拟化列表)，并订阅当LoadDtosActionEffect试图与API对话以检索dto时发出的成功/失败动作。组件声明了一个简单的布尔标志，在LoadDtosAsync中立即设置为true，在动作订阅者处注册的动作在发送成功/失败动作时简单地将该标志设置为false。

我怀疑，因为Blazor WASM是单线程的，这个标志不应该被并发修改。当我尝试使用System.Threading.EventWaitHandle来阻塞等待dto加载时，我发现了这个问题。

Pro-tip:不要在Blazor WASM中阻塞，否则只会导致应用程序死锁。

这里最需要注意的是要给这段代码添加一个超时，如果将来的修改破坏了动作订阅所依赖的动作/效果链，循环仍然会退出，并使用不正确的状态。这个结果比缓慢地建立大量并发"线程"更可取。(这不是真正的线程)在async/await调度中，这将最终吃掉周期并杀死性能。

等待动作(或后续效果/动作分派)完成的结果代码:

// Private class member declaration
private bool _refreshingDtos;
// Called in OnInitialized() or OnInitializedAsync()
private void SubscribeToActions()
{
_actionSubscriber.SubscribeToAction<LoadDtosSuccessAction>(this, action =>
{
_refreshingDtos = false;
});
_actionSubscriber.SubscribeToAction<LoadDtosFailureAction>(this, action =>
{
_refreshingDtos = false;
});
}
private async ValueTask<ItemsProviderResult<Dto>> LoadDtosAsync(ItemsProviderRequest request)
{
_stateFacade.LoadDtos(request.StartIndex, request.Count);
_refreshingDtos = true;
var delay = 100;
var timeout = 0;
while(_refreshingDtos && timeout < 30000)
{
await Task.Delay(delay);
timeout += delay;
}
return new ItemsProviderResult<Dto>(
_dtoState.Value.VirtualizedDtos ?? new List<Dto>(), _dtoState.Value.DtoServerCount ?? 0
);
}

// Component class implements IDisposable
// to make sure the component is unsubscribed (avoid leaking reference)
void IDisposable.Dispose()
{
if (_actionSubscriber is not null)
{
_actionSubscriber.UnsubscribeFromAllActions(this);
}
}