比较＆＃34;提升状态＆＃34; vs Redux，Flux状态管理

Question

我理解React提升状态＆＃34; https://reactjs.org/docs/lifting-state-up.html＆＃34;。通过这种方法，开发人员需要将父项中的状态函数作为子项传递给子项。之后我在redux上做了几次会议。但是，我无法理解在简单比较中提升状态与Redux，通量状态管理的主要区别。

1. 这是否意味着在大型网络应用程序中提升状态＆＃34;不应该使用和redux / flux变得不可避免
2. Redux简化了状态管理的整个过程，但除了抽象和简化之外还有其他任何优势。
3. 通过使用Redux，与＃34;提升状态相比，我们将拥有单一的真实来源＆＃34;我们需要在多个组件中保持状态，从而增加整体代码的复杂性。在提升状态中你可以有一个单一的事实来源，这种方法的唯一缺点就是你的父组件会被许多州混乱。
4. 还原和提升状态之间是否存在性能角度
5. 如果React被认为是一个视图库，它应该首先给出一个状态管理选项吗？

Answer 1

  

这是否意味着在一个大型的Web应用程序中提升状态＆＃34;应该   不被使用，redux / flux变得不可避免

绝对不是，你需要使用redux / flux，只有当你的应用程序使用的数据在大量不共享足够父级的组件之间共享并且数据不断变化时才需要使用redux / flux需要刷新。

如果您的应用的一小部分共享数据，您可以考虑使用 Context-API 来实现此目的。

  

Redux简化了状态管理的整个过程，但是存在   除了抽象和简化之外的任何其他优点。

是的，redux提供 wide range of advantages

• 将状态保留到本地存储，然后从开箱即用启动。

• 服务器上的预填充状态，以HTML格式发送给客户端，并从中启动，开箱即用。

• 序列化用户操作并将其与状态快照一起附加到自动错误报告中，以便产品开发人员可以重播它们以重现错误。

• 通过网络传递操作对象以实现协作环境，而不会对代码的编写方式进行重大更改。

  

通过使用Redux，我们将拥有单一的事实来源   ＆＃34;提升状态＆＃34;我们需要在多个组件中保持状态   从而增加了整体代码的复杂性。在提升状态你   可以有一个单一的事实来源是唯一的缺点   方法将是你的父组件将与许多混杂   的状态。

正如我之前所说，如果数据如果在没有非常直接共同祖先的组件之间共享，那么您可能更喜欢Redux。 Redux还提供了一个优势，即它将连接实现为PureComponent，因此状态更新仅影响正在使用它们的组件，并且不会导致重新呈现其他不使用这些特定状态的组件作为道具。

在提升状态启动时，您需要将值一直向下传递给每个组件，然后您需要确保中间组件是纯的。

  

还原和提升状态之间是否存在性能角度

当您通过状态并且不使用PureComponents时会出现性能问题，从而导致不必要的重新渲染。 Redux在这里很有帮助

Answer 2

Redux只是一个抽象概念，它没有提供任何你自己无法实现的性能优化。

但是，要实现Redux提供的性能优化，您需要做很多工作，例如几乎每个组件都实现shouldComponentUpdate。

例如，如果某些组件需要共享一个公共状态，则必须将状态提升到组件中的公共父级。父级和不使用共享状态的组件之间的所有其他组件都需要通过shouldComponentUpdate忽略与该状态相关的支柱更改。

每个组件还需要实现shouldComponentUpdate / PureComponent来检查其道具是否已更改，否则当父级重新呈现时，所有子组件都将自动重新呈现。

Redux还提供了其他一些便利功能：

• 不必通过深层嵌套组件传递回调和道具
• Redux DevTools用于可视化状态更改，时间调试等
• 状态直截了当地持续到localStorage到redux-persist
• 使用动作创建者/ thunks，presentational/container pattern等可提高代码的可重用性，可测试性和可维护性。

Answer 3

回答你的一些问题：

  

  
1. 这是否意味着在大型网络应用程序中提升状态＆＃34;不应该使用，redux / flux变得不可避免。
  

没有。提升状态仍然是首先要做的首选。即使您已在项目中拥有它，也无需将所有内容都放入全局存储中。很多州仍然是一些组件的本地，这是应该保留的地方。另请阅读When should I use redux。

  

  
1. 通过使用Redux，与＃34;提升状态相比，我们将拥有单一的真实来源＆＃34;我们需要在多个组件中保持状态   从而增加了整体代码的复杂性。在提升状态你   可以有一个单一的事实来源是唯一的缺点   方法将是你的父组件将与许多混杂   的状态。
  

如果是这种情况，您没有正确应用提升状态的原则。具有该状态的组件仍应是单一的事实来源。如果没有，你就没有提起它。

  

  
1. 还原和提升状态之间是否存在性能角度。
  

是。特别是如果做错了。请记住，每次状态更改都会调用mapStateToProps。如果你不注意，你会做很多不必要的计算。您可以使用selectors来克服部分问题。

Answer 4

这里有一些很好的答案。我会采取更务实的方法：

Redux为您所有的州提供单一的事实来源，但是当您拆分减速器时，它可能会变得完全不同。

组件状态意味着应用程序状态自然更加不同，但是如上所述，部分将通过提升状态集中。

您在项目中管理状态的方式将随着时间的推移而发展。您管理状态的方式也应该由您正在编写的应用程序指导。

另请注意，Redux和提升状态根本不是相互排斥的技术 - 您可以适当地使用它们。

对于新项目，我权衡了在一个位置拥有所有状态（单一事实来源）的便利性与不得不编写动作和连接组件的不方便开销。

如果有疑问，我会建议从组件状态开始，将其提升一两层，除此之外，我会将其提升到redux存储并直接连接我的组件。这将以务实的方式向您展示这两种方法的好处。

集中式redux存储的工具和单例性质意味着免费获得各种功能（持久性，时间旅行，redux devtools等）。另一方面，我可以浪费相当多的时间在早期使用redux连接应用程序，并且更容易忘记我坐下来写的内容。

Answer 5

1. Redux的本地状态和使用都可以和平共存:)即它们不是互斥的。
2. 在大型应用程序的情况下，代码可维护性明智的提升状态可能非常混乱。 Redux提供了更简洁的解决方案。
3. 最后，直接来自马的嘴 - Redux的合着者的一篇文章 - 你可能不需要redux https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367

因此在我看来，你必须首先尝试开发一个没有Redux的反应应用程序（中等复杂度）。使用＆＃34;提升状态＆＃34;概念。在开发过程中的某些时候，您会直观地意识到拥有像Redux这样的状态管理库会让生活变得更轻松。有时候，通过艰难的方式学习它会更好。在绝对必要的时候搬到Redux会让你更加欣赏它。