为什么使用像Zustand组件这样的状态管理器仍然会重新渲染？ - 腾讯云开发者社区 - 腾讯云

开发者社区

文档建议反馈控制台

文章/答案/技术大牛

发布

2023再谈前端状态管理

当组件的更新机制触发后，他们只是使用新值进行重新渲染。父子组件通信可以直接使用 props 和回调方式；深层次、远距离组件则要通过“状态提升”和 props 层层传递。...渲染优化要手动通过 selectors 进行。 Zustand vs Redux zustand 和 redux 是非常像的，都基于不可变状态模型，都基于单向数据流。...通过状态使用跟踪，可以检测到状态的哪部分被使用，让组件实现按使用重新渲染。同时，开发者也可以编写更少的代码。...基于ES6 proxy ，使用观察者/可观察模式的，当你修改一个值时，任何使用该值的组件都会自动重新渲染。原子化管理状态，进行精确渲染。...通过状态使用跟踪，可以检测到状态的哪部分被使用，让组件实现按使用重新渲染。同时，开发者也可以编写更少的代码。 jotai 是一个小型全局状态管理库，它模仿了 useState、useReducer。

2.2K1 0

Redux没错，但开发者已经投票用脚了

为什么Zustand能这样简洁？...我们来看实际情况： Redux 的渲染流程： dispatch(action) ↓ reducer 运算 ↓ createSelector 计算新状态 ↓ React.memo 判断是否重新渲染...↓ 组件重新渲染中间有多个"关卡"，每个关卡都需要开发者手动优化。...Zustand 的渲染流程： set((state) => ({ ... })) ↓ WeakMap 查询订阅者 ↓ 订阅该状态的组件 hook 触发更新 ↓ 组件重新渲染更直接，更细粒度...Zustand 在 hook 层面就知道谁依赖了什么数据，所以不会有"我改了全局状态，半个应用都重新渲染"的情况。

2471 0

您找到你想要的搜索结果了吗？

是的

没有找到

Zustand：让React状态管理更简单、更高效

状态中存储数组假设我们需要在Zustand中存储一个数组，我们可以像下面这样定义它： const useStore = create((set) => ({ fruits: ['apple', '...例如，在处理主题更换等需要组件根据状态更新而重新渲染的场景时，可能会出现一些问题。下面通过一个例子来说明这个问题及其解决方案。...如果在组件渲染后主题发生了变化，组件并不会自动更新以反映新的主题。这是因为Zustand底层使用了React的useState钩子，而React的状态更新是异步的。...解决方案：使用useEffect钩子为了解决这个问题，我们应该使用useEffect钩子，以确保当主题改变时组件能够重新渲染： import React, { useEffect } from 'react...这样，我们的组件就能够与最新的状态保持同步。这个解决方案展示了如何在Zustand的状态管理中应对组件依赖于状态变化时的自动更新问题，确保应用界面与状态同步，提升用户体验。

3.7K1 1

原子化状态管理库 Jotai，它和 Zustand 有啥区别？

因为不管修改 aaa 还是 bbb，都是修改 context 的值，会导致所有用到这个 context 的组件重新渲染。这就是 Context 的问题。...这个叫做 selector：状态变了之后，zustand 会对比 selector 出的状态的新旧值，变了才会触发组件重新渲染。...可以看到，点击按钮 Aaa、Bbb 组件都重新渲染了。而其实 Bbb 组件不需要重新渲染。这时候可以改一下：换成 useSetAtom，也就是不需要读取状态值。...这样状态变了就不如触发这个组件的重新渲染了：上面 Aaa 组件里也可以简化成 useAtomValue： import { atom, useAtom, useAtomValue, useSetAtom...提到原子化状态管理，都会提到 context 的性能问题，也就是 context 里通过对象存储了多个值的时候，修改一个值，会导致依赖其他值的组件也跟着重新渲染。

1.3K2 1

React-全局状态管理的群魔乱舞

React中的「组件看作是一个使用state和props来计算UI表现的函数」，而这个函数是依靠「数据引用相等」和「不可变的更新操作」来判断是否触发重新渲染。...在这种情况下，一个弊端就是你必须写大量的模板，以满足那些早已习惯数据可随时变更的人进行数据更新。这就是为什么像Immer[5]这样的库很受欢迎，它允许开发者编写可变风格的代码。...手动优化的一个例子是「通过选择器函数订阅一块存储的状态」。通过选择器读取状态的组件只有在该特定状态更新时才会重新渲染。 ❞ ❝第二种是为开发者「自动处理」，这样他们就不必考虑手动优化。...Valtio 是另一个例子，它在JS引擎下使用Proxy来自动跟踪事物的更新，并自动管理一个组件何时应该重新渲染。...这样做的「好处」是，消费者可以「精细地控制」如何订阅和优化订阅该状态的组件将如何重新渲染。「缺点」是这是一个手动的过程，可能容易出错，而且人们可能会说这需要不必要的开销，不应该成为API的一部分。

4.5K2 0

聊一聊 2024 年 React 生态系统

如果频繁地使用 React 的 Context 进行全局状态管理，那么 Zustand 可能会是你需要的工具。...Zustand 允许管理全局应用状态，任何与 Zustand 存储连接的 React 组件都可以读取和修改这些状态。...对于大量的全局状态，考虑使用 Zustand 或其替代方案。数据获取在处理 UI 状态时，React 的内置 Hook 是非常适用的。...目前，实用类优先的 CSS（如Tailwind CSS）是主流趋势。如果希望在 React 中根据条件应用样式，可以考虑使用像 clsx 这样的实用库。...尽管这些UI库都自带组件，但它们无法像专注于单一UI组件的库那样强大。

3.9K1 0

React Memo不是你优化的第一选择

然后，在各种文章中，都提倡克制useMemo的使用，优先使用「组件组合」来处理组件冗余渲染的问题。但是，它们都没讲明白，遇到这些问题，为什么不首选使用React.memo呢？...它们将状态存储在React之外，并「有针对性地触发需要更改的组件树部分的重新渲染」。像React Query /zustand/Recoil都是这么做的。...因此，是的，我提出的替代解决方案是「引入一个有效的状态管理器」。下面我们使用zustand来演示。...问题的根源无论是使用「组件组合」的方式还是使用React.memo亦或者利用「状态管理器」都不是最佳选择。...进行记忆化会使我们的代码难以阅读，而且很容易出错（最差）使用外部状态管理器会稍微好一些，但是增加了我们项目的学习负担（稍好）组件组合似乎可以完美解决，但是有些组件的改造可不是像上面Demo一样，

1.2K3 0

2026前端突破指南:为什么理解系统比背API更重要?

我用最简单的代码证明给你看观察者模式的核心(20行搞定): // 手写一个超级简化的状态管理器 function createState(initialValue) { let value = initialValue...打个比方观察者模式 = 微信群通知你(状态管理器)在群里发消息(setState): "晚上聚餐地点改成海底捞了" 所有@你的人(观察者)都收到通知: - 界面组件A: 更新地图显示 - 界面组件...为了避免不必要的重新渲染 // 第3次: 为什么重新渲染是问题?为什么memo能解决?...Signal = Vue的ref = 观察者模式 // 2. 响应式基于Proxy? 不,基于getter/setter // 3. 比React更细粒度? 对,避免了组件重新渲染 // 4....为什么要这样设计? 3. 为什么这是最好的解决方案?

1951 0

2026年前端技术的真实处境：从追捧到失落

最直观的证据来自数据：状态管理工具使用率变化 Zustand: 2023年 8% → 2026年 35% Redux: 2023年 60% → 2026年 38% 为什么大家开始逃离 Redux...计算新状态 ↓ Store 更新 ↓ Selector 提取数据 ↓ Component 重新渲染七步才能完成一个状态更新。...而 Zustand 呢？ Zustand 更新流程： User Action ↓ 调用 state 更新函数 ↓ Component 重新渲染只需两步。...你知道为什么吗？因为微前端解决的问题，在大多数公司的场景里根本不存在。微前端在理想国里是这样的：不同的团队、不同的技术栈、完全独立的部署。听起来很诱人，对吧？但现实中会发生什么？...具体来说，每次组件重新渲染，Emotion 都要做以下工作：解析你写的 CSS 代码处理动态值（颜色、大小等）生成唯一的类名注入到 style 标签让浏览器重新计算样式这整个过程，都在主线程上

5781 0

React性能优化的真相：为什么你的优化可能是在自欺欺人？

今天咱们来扒一扒 React 渲染优化背后那些被忽视的真相。为什么这篇文章值得看？...DOM 节点）父组件频繁重新渲染，但这个子组件的 props 不变何时无效： // ❌ 这样做 React.memo 形同虚设 function Parent() { const config...因为 Form 组件本身的 state 变了，它总会重新渲染。handleChange 的引用稳定并改变不了这个事实。...，只要 Context value 变化，都会重新渲染 // 即使那个组件只用了 Context 的一部分为什么这是问题？...（级联重新渲染很致命）避免全局状态滥用：本地状态优先收益：最高（最简单的优化）优先级 3：组件优化（细节）在 Profiler 指导下使用 React.memo 收益：低（大多数时候不需要）

1191 0

2025年React状态管理的残酷真相

真相二：状态应该按"场景"分类而不是"位置" 让我们把应用的"状态"重新分类。关键不是问"这个状态放在哪里"，而是问"这个状态是什么性质的"。性质不同，处理方案完全不同。 1....本地状态（Local Component State）：99%的开发者过度使用Redux 一个modal的打开/关闭状态需要放在Redux里吗？一个表单的输入框值需要全局管理吗？...真正的共享状态（Shared Component State）：这才是Redux的战场现在我们来到了真正需要Redux的场景——多个无关的组件需要共享同一个状态。...评测维度2：性能（避免不必要的重渲染）共享状态库最常见的问题是：修改了一个小状态，结果所有使用该store的组件都重新渲染。...第四个真相：2025年的最佳实践组合如果你现在要启动一个新项目，完全摆脱遗留包袱，应该这样组织你的状态管理：你的项目状态树 ├── 远程数据（API来的数据） │ └── TanStack Query

3961 0

当 React 路由 “失忆”：我如何用 AI 揪出 Vite 环境下的隐形状态杀手

更气人的是，控制台连一条报错信息都没有，bug 像 “幽灵” 一样隐形。...更诡异的是，控制台没有任何报错，Zustand 的 devtools 里能看到状态 “突然被重置”，却找不到是谁在修改状态。...审视 useEffect 依赖：列表页的 useEffect 里有订阅筛选状态的逻辑，逐一检查依赖数组，没发现 “意外触发重渲染” 的漏洞。...怀疑组件 memo 失效：给列表组件套 React.memo，甚至给 Zustand 的 selector 用 createSelector 做缓存 —— 状态还是 “说没就没”。...React Router 的 hydration 过程（我项目是纯客户端渲染，这条后来排除）。

2451 0

React 多次重新渲染之谜：为什么你的组件总是在发疯？

简单到不能再简单：你的组件什么时候重新渲染？依赖变了的时候。为什么你的应用卡得不行？因为不必要的东西在变，导致不必要的重新渲染。为什么 bug 满天飞？因为你没搞清楚这些依赖关系。...一个健康的组件应该是这样的：组件代码 80 行 ├─ 状态管理: 10 行 ├─ 事件处理: 30 行 ├─ 渲染逻辑: 30 行 └─ useEffect: 2~3 个（最多）如果你的组件里有...甚至在你没改变任何用户数据的时候。为什么会这样？...创建新的对象 // 2. 触发组件重渲染 // 3. 所有依赖 formData 的派生值都要重新计算 // 4....React Hook Form 的核心优化：传统受控表单的流程：输入改变 → setState → 组件重渲染 → 所有验证重新计算 React Hook Form 的流程：输入改变 → 直接更新内部状态

1631 0

轻量级状态管理库 Zustand 的基本使用

Zustand 介绍特点 1. 安装 npm install zustand 2....Store 初始化创建的 store 是一个 hook，你可以放任何东西到里面：基础变量，对象、函数，状态必须不可改变地更新，set 函数合并状态以实现状态更新。 ...Store 绑定组件可以在任何地方使用钩子, 不需要提供 Provider 基于selector 获取您的目标状态, 组件将在状态更改的时候重新渲染 function a(){ const...绑定store 到组件 function Zustand() { const { count, increase } = useStore() return ( ...绑定store 到组件 function Zustand() { const { fetchChannel, channelsList } = useStore() return

7021 0

在 React 中如何优化状态的使用？

使用 useMemo 和 useCallback 减少计算和引用变化useMemo：缓存计算结果，避免每次渲染重新计算useCallback：缓存函数引用，避免子组件不必要的重渲染import { useMemo...状态提升与 Context 合理使用当多个组件需要共享状态时，可将状态提升到共同的父组件避免过度使用 Context，它会导致所有消费组件重渲染// 状态提升示例function Parent() {...使用状态管理库处理复杂状态当应用规模扩大，状态逻辑复杂时，可使用 Redux、Zustand 等库。...避免不必要的状态更新使用条件判断避免无意义的状态更新。...== count) { setCount(newValue); }};通过这些策略，可以有效减少不必要的重渲染，提高组件性能，并使状态管理更加清晰可维护。

2531 0

我在大型项目中发现的真相

↓ Service 更新全局状态 ↓ 整个 Redux store 重新渲染 ↓ 弹窗才关上本来 200ms 的事，整成了 1s 多。...跨越很多层级的数据共享比如某个数据需要从根组件传到第 7 层子组件。每一层都要透传，很烦。这时全局状态有意义。除了这些呢？坦白说，90% 的其他状态都不需要。...我们重构时做了这样的分层：第 1 层：UI 状态 → useState 表单输入、下拉菜单、弹窗、Tab 切换……用本地 state。这些数据不需要离开组件。...(state => state.addToCart) 为什么选 Zustand？...多个组件需要共享，但逻辑相同？ → 提取成自定义 Hook 3. 真的是 App 全局共享的状态，而且不会频繁变化？ → 用 Context + useState，或者 Zustand 4.

2071 0

为什么有人React代码能用5年不过时?高级工程师都在用的10个设计模式

为什么要改? 不是为了赶时髦,而是Hooks让逻辑复用变得无痛。你见过为了复用一个loading状态,写一个HOC包三层的屎山代码吗?...,不需要HOC或Render Props ✅ 逻辑和UI完全解耦模式2:状态就近原则——别什么都往Context里塞常见误区: 很多人一上来就Redux/Zustand全局状态,结果一个搜索框的输入都要...正确姿势: 状态放在最小使用范围内,只有真正需要跨组件共享的才提升。...模式3:复合组件模式——写出像Ant Design一样优雅的API 什么是复合组件? 让多个组件协同工作,但保持使用时的声明式和灵活性。...useEffect瀑布流传统问题: 组件渲染后才在useEffect里fetch,导致"组件显示→loading→数据到达→再渲染"的瀑布流。

2601 0

Zustand 用法记录

默认使用浅比较来判断状态是否改变，只有状态发生改变时，订阅该状态的组件才会重新渲染。...同时，你可以选择性地订阅状态的部分属性，避免不必要的重新渲染。import React from 'react';import { useUserBasicInfoStore } from '....immer 进行不可变更新处理复杂对象的嵌套更新时，使用 immer 库可以让代码更简洁，同时确保状态更新的不可变性。...，方便在不同组件中使用。...简单示例：selectTotalPrice 函数根据 items 数组计算购物车的总价格，组件只需要订阅这个派生状态即可。

4530 0

放弃Redux吧，转投Zustand吧

Zustand 的核心思想是将状态管理与组件分离，从而使得状态管理更加集中化，同时保持了 React 的响应性和组件的可重用性。...性能优化 Zustand 通过自动缓存状态值来减少不必要的组件渲染，从而提高性能。它还解决了 Redux 中的“死节点”问题，即在某些情况下，子组件可能无法正确更新的问题。...在组件中使用 store 在你的 React 组件中，使用 useStore 钩子来访问和更新 store 中的状态。 import { useStore } from '....其实可以使用状态管理来管理全局的主题样式，然后再配合zustand的持久化插件persist来实现一键换肤的功能，这样刷新之后也不会丢失状态了 persist持久化的用法 Zustand 的持久化插件是一个强大的功能...这个功能特别适用于那些需要跨会话或页面刷新保持状态的场景。总结以上就是zustand的全部用法了。已经简单阐述了一下为什么要选zustand而不是继续用redux。

1.8K1 0

Pinia、Redux、Zustand：前端状态管理库横向对比

大家好，我是腾讯云开发者社区的Front_Yue，本篇文章将带大家横向对比目前前端主流的几大状态管理方案：Pinia（Vue生态）、Redux（React生态）、Zustand（React轻量方案）。...本文不仅会剖析三者的核心理念，还会从开发体验、生态支持、性能表现、适用场景等角度展开分析，帮助大家在项目选型时做出更合理的判断。一、为什么需要状态管理库？...在现代前端应用中，组件间的状态共享和数据一致性是一个核心问题：当应用规模小，只依赖父子组件props传递和本地状态useState/ref就能满足需求。...二、核心理念对比特性Pinia（Vue）Redux（React）Zustand（React）定位Vue官方推荐的状态管理库React生态最经典、最完整的状态管理解决方案极简、轻量级React状态管理库数据存储...Redux：依赖浅比较+选择器（reselect）优化，性能较好，但需开发者注意避免不必要渲染。Zustand：使用订阅机制，只会触发实际使用该状态的组件更新，性能出色。

9520 0

点击加载更多

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭