Redux 常见问题：组织 State

目录

组织 State

必须将所有 state 都维护在 Redux 中吗？ 可以用 React 的 setState() 方法吗？

没有 “标准”。有些用户选择将所有数据都在 Redux 中维护，那么在任何时刻，应用都是完全有序及可控的。也有人将类似于“下拉菜单是否打开”的非关键或者 UI 状态，在组件内部维护。适合自己的才是最好的。

使用局部组件状态是更好的。作为一名开发者，应该决定使用何种 state 来组装你的应用，每个 state 的生存范围是什么。在两者之间做好平衡，然后就去做吧。

这里有一些将怎样的数据放入 Redux 的经验法则：

  • 应用的其他部分是否关心这个数据？
  • 是否需要根据需要在原始数据的基础上创建衍生数据？
  • 相同的数据是否被用作驱动多个组件？
  • 能否将状态恢复到特定时间点（在时光旅行调试的时候）？
  • 是否要缓存数据（比如：数据存在的情况下直接去使用它而不是重复去请求他）？

有许多开源组件实现了各式各样在 Redux store 存储独立组件状态的替代方法，比如 redux-ui、 redux-component、 redux-react-local等等。还可以将 Redux 的原则和 reducers 的概念应用到组件层面，按照 this.setState((previousState) => reducer(previousState, someAction)) 的情形。

补充资料

文章

讨论

库

可以将 store 的 state 设置为函数、promise或者其它非序列化值吗？

强烈推荐只在 store 中维护普通的可序列化对象、数组以及基本数据类型。虽然从 技术 层面上将非序列化项保存在 store 中是可行的，但这样会破坏 store 内容持久化和恢复能力，以及会干扰时间旅行。

如果你不关心数据持久化和时间旅行，那么完全欢迎把不可以持久化的数据放入 Redux 的 Store 中存储。最终，他是你的应用程序，如何实现完全取决于你自己。与其他很多 Redux 的事情一样，你需要明白权衡所需。

补充资料

讨论

如何在 state 中组织嵌套及重复数据？

当数据存在 ID、嵌套或者关联关系时，应当以 “范式化” 形式存储：对象只能存储一次，ID 作为键值，对象间通过 ID 相互引用。将 store 类比于数据库，每一项都是独立的 “表”。normalizr 、 redux-orm 此类的库能在管理规范化数据时提供参考和抽象。

补充资料

文档

文章

讨论

results matching ""

    No results matching ""