在React中使用不可变状态有哪些缺点？
我已经以“正常”方式用状态存储构建了我的第一个React应用程序，现在我正在研究使用像Este入门套件中所使用的不可变全局状态。
- 所有存储的状态都保存在一个不变的数据结构中
- 组件没有状态，但是根据商店的getter函数访问其render（）中的数据
- 存储也是无状态的，但是会使用游标更改其域的全局应用程序状态。
- 顶层应用程序组件侦听状态更改，然后重新呈现整个组件树。
- 组件被实现为“纯”的，这意味着它们使用shouldComponentUpdate来有效地找出它们，可以在重新渲染中跳过它们。
它通过几种方式简化了应用程序结构：
- 组件不监听存储，也不会将存储数据复制到其本地状态。他们只需在每个渲染器上获取其存储状态。
- 全局状态始终是整个应用程序的快照，从而使调试和添加诸如undo trivial之类的功能变得更加容易。
- 全局状态似乎简化了同构渲染。
我只读过关于在React中使用不可变数据的积极知识，建议您避免组件中的状态，因此我想知道是否存在任何不利之处。我想一定有，因为否则我不明白为什么它不推荐
的 方式来结构作出反应的应用程序。
不变性对我来说是新的，因此，如果我开始在复杂的现实世界应用中使用这种方法，是否应该注意一些警告？
我唯一能想到的小事就是Este在使用forceUpdate（），因为我读到它是一个同步函数。例如，Morearty似乎将更新推迟到下一个动画帧以进行批处理，但是我认为这是实现细节/优化，而不是继承不可变单状态方法的缺点。
回答：
- 文档。SO中一些投票最多的问题/原因与琐事有关，例如更新嵌套列表项，这都是因为文档更加面向熟悉函数式编程的读者，这使得它对其余函数的访问变得不那么容易。
- 将模型层次结构知识与组件分开并不是一件容易的事。我不喜欢
this.state.getIn("[parent, child, index]")在组件中进行操作，因为它增加了更改模型破坏组件代码的可能性。这可以通过可扩展性（在下面进行更多介绍）或通过辅助方法来避免，但是您肯定会失去普通JS成员的简单性。 - 我面临的一个重大挑战是能够对状态进行序列化和反序列化。fromJS方法支持自定义恢复器，但它们是皮塔饼，需要仔细的测试和维护。
- 记录类型严重受制于称为嵌套的崩溃。这很可悲，因为它允许更容易（相对而言）可扩展性，但仅鼓励单级层次结构。您无法轻松地从JSON创建嵌套记录。除非您使用上述的皮塔饼齐发器，否则很难将它们与常规的fromJS不可变用法混合使用。我是否提到了令人遗憾的是，给定Records将模型属性公开为一等成员，确保模型完整性和默认值。
- 然后是可扩展性。尝试在不可变数据模型周围添加辅助对象，以抽象化组件中模型层次结构的依赖性，您将面临明显的障碍。反序列化成为一场痛苦的离婚战。如果唱片混在一起，它们将哭泣，以此类推，那么您就需要弄乱Reviver。一种更容易的扩展机制将大大有助于使我的组件代码更简洁。
- 没有记录的最佳做法。尽管这与＃1相符，但我仍要指出，缺乏好的文档会阻止人们选择最佳的做事方式。我不确定是否应该使用更新程序，forEach或setIn（等等）来更新不可变结构。这些方法相互之间的交叉引用不足以让您知道周围有哪些替代方法。
以上是 在React中使用不可变状态有哪些缺点？ 的全部内容， 来源链接： utcz.com/qa/408964.html
