Redux 常见问题:组织 State

目录

组织 State

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

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

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

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

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

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

补充资料

文章

讨论

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

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

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

补充资料

讨论

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

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

补充资料

文档

文章

讨论

results matching ""

    No results matching ""