我一直在使用 Flux，我真的很享受，但有一点我无法弄清楚什么是最好的解决方案。我制作了一个处理订单列表的应用程序，列表中的每个订单都分为不同的组件，这些组件可以具有读取/编辑模式(基本上更改为小形式)并触发更新(订单中的产品列表、运输费用等)。
一切正常，除了我必须处理订单更新时服务器的异常情况(例如，用户更改了其中一种产品数量，但库存不足，我希望组件显示该表单)该特定订单的特定产品显示内联消息，因此我必须将错误消息传递给非常特定的组件。该列表最多可以有 50 个订单，每个订单由 4-5 个可以触发更新的组件组成，因此我可以有大约 200 个可能对 ORDER_UPDATE_FAILED 操作感兴趣的组件。
我能想到的唯一两个选择是:
- 使组件同步调用 API 更新，以便在发生错误时可以检索错误(更新的订单将作为 ORDER_UPDATED 操作的有效负载发送，并保持其流通过正常的 Flux 流:调度程序、存储、触发更新)。但我知道这有点打破了 Flux 的哲学
异步更新并创建 ORDER_UPDATE_FAILED，并且 Store 具有将错误转换到可由订单部件组件识别的对象中的逻辑(考虑 orderID + errorID)。这样可以保持数据的单向循环和 Action 的异步性，但感觉太复杂和麻烦，并增加了一些更多的问题:
a) 如果错误存储在 Store 中，则当错误不再有效时，组件必须通知存储，但这可能无法始终做到。
b) 如果用户在不更改值的情况下单击“保存”，并且组件进入“正在加载状态”，即使调用成功，顺序也保持不变，因此不会重新渲染以退出“正在加载状态”。
有没有人找到更优雅的方法来解决这个问题？
请您参考如下方法:
我认为选项 1 有意义并且更容易管理，只要错误仅在该组件的范围内相关。我一直在使用这种方法来显示表单提交时的错误，例如用户注册，我知道唯一需要错误消息的地方是直接在表单上(“该用户名已被占用”)。我将这种错误消息视为表单/组件本身的一部分，更多的是本地状态而不是应用程序状态。这听起来很像你的情况，所以我想说这是更好的选择。
对于该错误将来可能在多个地方变得相关的可能性，选项 2 会更加稳健。但如果您确信这种情况不太可能发生，那么与选项 1 相比，我认为增加复杂性并没有什么优势。
