相关疑难解决方法(0)

我一直在使用React + Flux应用程序中的乐观更新,并看到两件事:

1. 如果用户在存在一些未完成的操作时尝试关闭窗口会发生什么.例如在Facebook中,即使没有真正持久化,也会在墙上显示一条消息(这是乐观更新所做的,对用户来说响应更快的应用程序).但是,如果用户在墙上发布并立即关闭应用程序(在注销或窗口关闭时),帖子可能会失败并且他不会收到警报.
2. 我不喜欢Stores管理他自己的实体(例如消息)的想法以及为persiste消息触发的动作的情况(加载,成功,失败？).它混合了一些东西.

因此,我致力于此并创建一个ActionStore来管理由组件触发的操作的状态.这是源代码,这是一个现场演示.

它的工作方式或多或少是这样的:

1. 组件层次结构的根(redux中的容器)获取新操作的nextId并将其传递给他的子项,如props(这很难看).
2. 子组件触发一个动作:它保持actionId以便在之后向商店询问并调用动作创建者.
3. 动作创建者创建一个新的Action并将函数返回给中间件.
4. 从Action返回的函数使用API​​调用创建一个新的Promise,并调度类型为XX_START的操作.
5. ActionStore会侦听XX_START操作并保存它.
6. 子组件接收新状态并找到具有已保存ID的操作,并询问当前情况:加载,成功或失败.

我这样做主要是为了将"实体"的状态与动作的状态分开,但允许具有相同有效负载的重新触发操作(如果服务器临时关闭或者如果我们收到500响应状态,这可能很有用用户松动的信号).

此外,拥有操作存储允许在用户注销或关闭窗口之前轻松询问它们是否为待处理操作.

注意:我正在使用针对Rest API的单应用程序页面Web应用程序,我不认为在服务器端呈现时使用它

这是一个可行的选择创建一个ActionStore或我打破一些Redux/Flux基础？这可能会结束使用React Hot Reloading和Time travel的可能性吗？

你应该毫不留情地回答,我可能做了一堆丑陋的事情,但我正在学习React/Redux.