如何设计 Redux 存储和操作？ [关闭]

Question

就开发应用程序的前端而言，ReactJS 和 Redux 提供了一种新的范例。两者都有相对简单的 API，从技术角度来看，花一点时间后很容易掌握。但从设计的角度来看，我一直无法找到关于最佳实践或陷阱的建议。

我在哪里可以找到有关如何设计我的全球 Redux 商店的建议或建议？将应用程序的整个状态保存在全局存储中似乎很快就会变得笨拙。这样做时我应该确保避免什么？那么修改全局状态的动作呢？是根据动作数据做更少的动作来做不同的事情，还是做更多的具体动作更好？

Answer 1

这是一个很好的问题，但有点难以明确回答，因为其中大部分是一个“取决于”的问题。 但是，我强烈建议您深入了解redux.js.org 文档。那里有很多关于塑造 API 或减少重复或一般笨拙的建议的小智慧。

此外，我想添加一些一般提示：

• 您通常需要声明的频率并不像您想象的那么频繁。所以有些事情可以通过更多的 props 和更少的 store 驱动状态来完成
• 将事物分组为更大的“主题”通常有助于在商店级别组织数据；因此，您可以在商店中为给定用户、身份验证提供更高级别的属性，并且任何进一步的“主题”都将以相同的方式分组。
• 有时，您可能会创建稍微更详细的状态结构，但要权衡的是可预测性和更大的整体简单性。仍然胜过 MVC 或 2-way 疯狂
• 最后，作为一个小问题，“全局”状态实际上不必如此全局。从某种意义上说，单个状态树意味着所有状态都是“全局的”（或至少是统一的），但除非您将 store 暴露给每个单独的组件，否则它并不是真正的全局。良好解耦的组件将使 IMO 更容易考虑来自上层的数据流动，而且事情不必真的是“全球性的”，如果这有意义的话。

希望能有所帮助！

另见：

• http://redux.js.org/
• https://medium.com/@dan_abramov/the-evolution-of-flux-frameworks-6c16ad26bb31#.1pkpbhihd
• https://github.com/markerikson/react-redux-links/blob/master/tips-and-best-practices.md