【问题标题】:Fast changing states without Redux没有 Redux 的快速变化的状态
【发布时间】:2021-07-07 08:39:42
【问题描述】:

我正在开发一个具有快速变化的状态和许多广播的网站,并且我正在尝试使用钩子和上下文创建自己的全局状态管理。我发现避免无用渲染的唯一解决方案是为每个状态创建两个上下文,一个用于状态更新器方法,一个用于状态本身。我最终有几十个上下文。

它看起来不是一个好的设计,但我没有任何其他想法,我仍然认为可以创建一个复杂的 React 应用程序无需第三方库 处理状态管理。

你有什么建议吗?谢谢

【问题讨论】:

    标签: reactjs react-state-management


    【解决方案1】:

    首先注意,Context API is not a state management tool


    目前 (v17) 没有针对上下文消费者的救助。

    如果你不知道这是什么意思,check out this answer

    你是对的,你需要有多个上下文提供者来减少无用的渲染。

    至于你的其他问题:

    “是否可以在没有第三方库的情况下创建复杂的 React 应用来处理状态管理?”

    我在 Facebook 上做一个非常复杂的项目,我们只使用 Context API 来管理它(我们也有无用渲染的情况,这没关系),所以基本上答案是“是”。

    作为一般建议,在使用“仅上下文”方式或任何状态管理解决方案之前,您应该分析应用程序性能,主要是 premature optimization,而“无用”渲染是没有意义的。

    【讨论】:

    • 感谢您的回答和资源!这个话题让我思考:假设有依赖于父上下文的子上下文。对父上下文的更新是否会强制所有依赖于子上下文的组件重新呈现?
    • @MichaelHoobler 如果上下文提供者触发更新,每个消费者和他们的孩子都会重新渲染
    • 感谢您的回答,过早的优化有点意思。所以你建议继续创建多个上下文,但每个状态不需要两个上下文?例如,我可以将模态状态和弹出状态包装在同一个上下文中。
    • 我建议在你有流量之后进行优化,即继续工作,完成你的项目,然后进行一个分析阶段,看看你是否真的在某个地方遇到了瓶颈,如果没有,你就赢得了宝贵的时间致力于更有影响力的目标
    • 确实看起来合乎逻辑,感谢您的时间
    猜你喜欢
    • 1970-01-01
    • 2019-03-19
    • 2019-02-01
    • 2023-03-23
    • 2019-12-12
    • 1970-01-01
    • 2021-10-11
    • 1970-01-01
    • 2020-08-31
    相关资源
    最近更新 更多