我们如何在 ItemProviderDelegate 中等待 Action/Effect 的结果?
How do we await the result of an Action/Effect in an ItemProviderDelegate?
在我的剃刀组件中,我使用 Virtualize
组件 (docs here) 和 ItemsProviderDelegate
实现为 async
方法来加载数据传输对象 (DTO) ) 从 API 分批处理。该方法看起来像这样:
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
属性,其中包含对调度操作的组件的引用。当分派所需操作的组件中的原始方法不需要从操作到 return 的结果状态时,此方法有效。然后 Effects 可以根据发送动作的组件类型调用回调方法,例如:
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
对这种方法提出了一个有趣的例外。为了正确实施委托,我们需要 return 项目列表和服务器上可用项目的数量。此信息存储在该功能的状态中,当 LoadDtosAction
成功时,该状态由 reducer 更新。在当前的实现中(上面一般表示),LoadDtosAsync
方法做了 2 个我不喜欢的假设:
状态值 isLoading
在 LoadDtosAction
被调度后立即设置为 true。我不认为这总是正确的,因此组件有时会立即询问状态值以更新自身(这将导致显示先前的状态而不是结果状态)。
由此产生的 action-reducer-effect 链最终会将状态 isLoading
值更新为 false
.
是否有一种方法允许 ItemsProviderDelegate
实现分派 LoadDtosAction
并“等待”操作结果到 return 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')
对于未来的考古学家,我能想到的最好的解决方案是通过 DI 将 Fluxor 的 IActionSubscriber
添加到我的组件中(使用由 redux 状态管理的虚拟化列表)并订阅 success/failure 当 LoadDtosActionEffect
尝试与 API 对话以检索 DTO 时调度的操作。该组件声明了一个简单的布尔标志,它在 LoadDtosAsync
中立即设置为 true
,当 success/failure 动作是时,向动作订阅者注册的动作只需将该标志设置为 false
已派出。
我怀疑,因为Blazor WASM是单线程的,所以这个标志不应该被并发修改。我在等待 DTO 加载时尝试使用 System.Threading.EventWaitHandle
进行阻塞时发现了这一点。
专业提示:不要在 Blazor WASM 中阻塞,您只会在应用程序中实现死锁。
这里最大的注意事项是在此代码中添加超时,如果将来的某些修改破坏了操作订阅所依赖的 actions/effects 链,循环仍将退出并简单地使用不正确的状态。这个结果比在 async/await 计划中慢慢建立大量并发“线程”(实际上不是线程)更可取,因为后者最终只会耗尽周期并降低性能。
等待动作(或后续 effects/actions 分派)完成的结果代码:
// 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);
}
}
我想你可以这样做
- 您的组件中有一个
TaskCompletionSource<ItemsProviderResult<Employee>>
成员。
- 在
LoadDtosAsync
中调度一个具有 属性 的动作,其中包含对该 TaskCompletionSource
的引用
await
即 TaskCompletionSource
那是 UI 的一面,现在是商店部分
[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
本身中——我们只是在动作(可以保存可变数据)。
在我的剃刀组件中,我使用 Virtualize
组件 (docs here) 和 ItemsProviderDelegate
实现为 async
方法来加载数据传输对象 (DTO) ) 从 API 分批处理。该方法看起来像这样:
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
属性,其中包含对调度操作的组件的引用。当分派所需操作的组件中的原始方法不需要从操作到 return 的结果状态时,此方法有效。然后 Effects 可以根据发送动作的组件类型调用回调方法,例如:
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
对这种方法提出了一个有趣的例外。为了正确实施委托,我们需要 return 项目列表和服务器上可用项目的数量。此信息存储在该功能的状态中,当 LoadDtosAction
成功时,该状态由 reducer 更新。在当前的实现中(上面一般表示),LoadDtosAsync
方法做了 2 个我不喜欢的假设:
状态值
isLoading
在LoadDtosAction
被调度后立即设置为 true。我不认为这总是正确的,因此组件有时会立即询问状态值以更新自身(这将导致显示先前的状态而不是结果状态)。由此产生的 action-reducer-effect 链最终会将状态
isLoading
值更新为false
.
是否有一种方法允许 ItemsProviderDelegate
实现分派 LoadDtosAction
并“等待”操作结果到 return 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')
对于未来的考古学家,我能想到的最好的解决方案是通过 DI 将 Fluxor 的 IActionSubscriber
添加到我的组件中(使用由 redux 状态管理的虚拟化列表)并订阅 success/failure 当 LoadDtosActionEffect
尝试与 API 对话以检索 DTO 时调度的操作。该组件声明了一个简单的布尔标志,它在 LoadDtosAsync
中立即设置为 true
,当 success/failure 动作是时,向动作订阅者注册的动作只需将该标志设置为 false
已派出。
我怀疑,因为Blazor WASM是单线程的,所以这个标志不应该被并发修改。我在等待 DTO 加载时尝试使用 System.Threading.EventWaitHandle
进行阻塞时发现了这一点。
专业提示:不要在 Blazor WASM 中阻塞,您只会在应用程序中实现死锁。
这里最大的注意事项是在此代码中添加超时,如果将来的某些修改破坏了操作订阅所依赖的 actions/effects 链,循环仍将退出并简单地使用不正确的状态。这个结果比在 async/await 计划中慢慢建立大量并发“线程”(实际上不是线程)更可取,因为后者最终只会耗尽周期并降低性能。
等待动作(或后续 effects/actions 分派)完成的结果代码:
// 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);
}
}
我想你可以这样做
- 您的组件中有一个
TaskCompletionSource<ItemsProviderResult<Employee>>
成员。 - 在
LoadDtosAsync
中调度一个具有 属性 的动作,其中包含对该TaskCompletionSource
的引用
await
即TaskCompletionSource
那是 UI 的一面,现在是商店部分
[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
本身中——我们只是在动作(可以保存可变数据)。