比较“提升状态"vs Redux，Flux 状态管理 [英] comparing "Lifting state up" vs Redux,Flux state management
问题描述
我理解 React Lifting-state-up "https://reactjs.org/docs/lifting-state-up.html".通过这种方法，开发人员需要将父级中的状态函数作为道具传递给子级.之后我做了几个关于 redux 的会议.但是，我无法通过简单的比较来理解提升状态与 Redux、通量状态管理的主要区别.
I understood React lifting-state-up "https://reactjs.org/docs/lifting-state-up.html". By this method a developer needs to pass the state functions in parents as props to child. After which I did a couple of session on redux. But, I am unable to understand the main differences in lifting state up vs Redux, flux state management in simple comparisons.
- 这是否意味着在大型 Web 应用程序中不应使用提升状态"并且 redux/flux 变得不可避免
- Redux 简化了状态管理的整个过程，但除了抽象化和简化之外还有什么优势.
- 与提升状态"相比，通过使用 Redux，我们将拥有单一的事实来源，我们需要在多个组件中保持状态，从而增加整体代码的复杂性.在提升状态中，您可以拥有单一的事实来源，但这种方法的唯一缺点是您的父组件会被许多状态杂乱无章.
- redux 和提升状态之间是否存在性能角度
- 如果说 React 是一个视图库，它应该首先提供状态管理选项吗?
推荐答案
这是否意味着在大型 Web 应用程序中提升状态"应该不被使用，redux/flux 变得不可避免
Does it mean inside a big web applications "lifting state up" should not be used and redux/flux becomes inevitable
绝对不是，你需要使用 redux/flux，只有当你的应用程序使用的数据在大量没有共享足够接近父级的组件之间共享并且数据不断变化和视图时需要刷新.
Absolutely not, you need to be use redux/flux, only when the data being used by your app is shared between a large number of components who do not share a close enough parent and that the data keeps on changing and the view needs to be refreshed.
如果数据在您应用的一小部分共享，您也可以考虑使用 Context-API 用于此目的.
In case when the data is being shared in a small section of your App, you might consider using Context-API for this purpose too.
Redux 简化了状态管理的整个过程，但是有没有除了抽象和简化之外的任何优势.
Redux simplifies the whole process of state management, but is there any advantage other than abstraction and simplification.
是的，redux 提供了广泛的优势
Yes, redux offers a wide range of advantages
将状态保存到本地存储，然后从它启动，开箱即用.
Persist state to a local storage and then boot up from it, out of the box.
在服务器上预填充状态，以 HTML 格式将其发送到客户端，然后从它启动，开箱即用.
Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box.
序列化用户操作并将它们与状态快照一起附加到自动错误报告中，以便产品开发人员可以重放它们以重现错误.
Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors.
通过网络传递操作对象以实现协作环境，而无需对代码的编写方式进行重大更改.
Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.
与使用 Redux 相比，我们将拥有单一的事实来源提升状态"，我们需要在多个组件中保持状态从而增加了整体代码的复杂性.在提升状态你可以有一个单一的真相来源唯一的缺点方法将是您的父组件会被许多状态.
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，因此状态更新仅影响正在使用它们的组件，而不会导致其他不使用这些特定组件的组件重新渲染状态作为道具.
As I said earlier, if the data if shared between components that do not have very direct common ancestor, you might prefer Redux. Redux also offers an advantage that it implements a connect as a PureComponent and hence state updates only affect the components that are using them and will not cause a re-render for other components which don't use those particular states as props.
随着提升状态上升，您需要通过每个组件一直向下传递值，然后您需要确保中间组件是纯的.
With Lifting state up, you need to pass down the values all the way down though each and every component and then you need to make sure that the intermediate components are Pure.
redux 和提升状态之间有没有性能角度
Is there a performance angle between redux and lifting state up
当您向下传递状态并且不使用 PureComponents 时，性能问题就会出现，从而导致不必要的重新渲染.Redux 在这里很有帮助
The performance issue comes into picture when you are passing state down and don't use PureComponents, causing unnecessary re-renders. Redux is helpful here
这篇关于比较“提升状态"vs Redux，Flux 状态管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
