我理解了React lift-state-up“https://reactjs.org/docs/lifting-state-up.html”。通过这种方法，开发人员需要将父级中的状态函数作为 Prop 传递给子级。之后我做了几次关于 redux 的 session 。但是，通过简单的比较，我无法理解提升状态与 Redux、通量状态管理的主要区别。
- 这是否意味着在大型 Web 应用程序中不应使用“提升状态”，并且 redux/flux 变得不可避免
- Redux 简化了状态管理的整个流程，但是除了抽象和简化之外还有什么优点吗？
- 与“提升状态”相比，通过使用 Redux，我们将拥有单一的事实来源，在“提升状态”中我们需要在多个组件中保留状态，从而增加了整体代码的复杂性。在 lift-state-up 中，您可以拥有单一的事实来源，该方法的唯一缺点是您的父组件会充斥着许多状态。
- redux 和提升状态之间是否存在性能角度
- 如果 React 被称为 View 库，那么它首先应该提供状态管理选项吗？
最佳答案
Does it mean inside a big web applications "lifting state up" should not be used and redux/flux becomes inevitable
绝对不是，只有当您的应用程序使用的数据在大量不共享足够近的父组件的组件之间共享并且数据不断变化且 View 不断变化时，您才需要使用 redux/flux需要刷新。
如果数据在应用程序的一小部分中共享，您也可以考虑使用 Context-API 来实现此目的。
Redux simplifies the whole process of state management, but is there any advantage other than abstraction and simplification.
是的，redux 提供了 wide range of advantages
将状态保留到本地存储，然后从中启动，开箱即用。
在服务器上预填充状态，以 HTML 形式将其发送到客户端，然后从中启动，开箱即用。
序列化用户操作并将其与状态快照一起附加到自动错误报告中，以便产品开发人员可以重播它们以重现错误。
通过网络传递操作对象以实现协作环境，而无需对代码的编写方式进行重大更改。
By using Redux we will have a single source of truth as compared to "Lifting state up" where we need to keep state in multiple components and thus adding complexity to overall code. In lifting-state-up you can have a single source of truth the only shortcoming of that approach would be your parent component would be cluttered with many states.
正如我之前所说，如果数据在没有非常直接的共同祖先的组件之间共享，您可能更喜欢 Redux。 Redux 还提供了一个优点，它将连接实现为 PureComponent，因此状态更新只会影响正在使用它们的组件，并且不会导致不使用这些特定组件的其他组件重新渲染状态作为 Prop 。
通过提升状态，您需要将值一路向下传递到每个组件，然后您需要确保中间组件是纯的。
Is there a performance angle between redux and lifting state up
当您向下传递状态并且不使用 PureComponents 时，性能问题就会出现，从而导致不必要的重新渲染。 Redux 在这里很有帮助
关于reactjs - 比较 "Lifting state up"与 Redux,Flux 状态管理，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50330954/