如何处理Flux中的异步错误？

Question

我一直在和Flux合作，我真的很享受，但我有一点我无法确定什么是最好的解决方案。我创建了一个处理订单列表的应用程序，列表中的每个订单都划分为不同的组件，这些组件可以具有读取/编辑模式（基本上变为小型）并触发更新（订单中的产品列表，发货成本等）。

除了我必须在订单更新时处理来自服务器的异常的情况外，所有工作正常（例如，用户更改了其中一个产品数量但库存不足，我希望组件显示该表单的内容特定订单的特定产品显示内联消息，因此我必须将错误消息传递给一个非常特定的组件。该列表最多可以有50个订单，每个订单由4-5个组件组成，可以触发更新，所以我可以拥有大约200个可能对ORDER_UPDATE_FAILED操作感兴趣的组件。

我能想到的唯一两个选择是：

1. 使组件同步调用API更新，以便在发生错误时检索错误（更新的订单将作为ORDER_UPDATED操作的有效负载发送，并保持其流经正常的Flux流：调度程序，存储，触发器更新）。但我知道这会打破一点Flux哲学

2. 以异步方式进行更新并创建ORDER_UPDATE_FAILED，并且Store具有将变换放入可由订单部件组件识别的对象中的逻辑（考虑orderID + errorID）。这将保持数据的单向循环和操作的异步，但感觉过于复杂和繁琐，并增加了一些问题：

   a）如果错误存储在Store中，则组件必须在错误不再有效时通知商店，这可能无法始终执行。

   b）如果用户在没有更改值的情况下点击“保存”并且组件处于“加载状态”，即使调用成功，订单也保持不变，因此不要重新退出“加载状态”。

有没有人找到更优雅的方法来解决这个问题？

Answer 1

我认为选项1有意义并且更容易管理，只要错误仅与该组件的范围相关。我一直在使用这种方法在表单提交上显示错误，例如用户注册，我知道我需要错误消息的唯一地方是直接在表单上（＆＃34;用户名已经是采取＆＃34）。我将这种错误消息视为表单/组件本身的一部分，比应用程序状态更多的本地状态。这听起来很像你的情况，所以我想说这是更好的选择。

选项2对于错误可能在未来不止一个地方变得相关的可能性更为强大。但如果您确信这不太可能发生，那么与选项1相比，我不会看到增加复杂性的优势。