Redux和react。增加和减少购物车中的数量。它确实改变了数量，但没有重新渲染组件 - 腾讯云开发者社区

文章/答案/技术大牛

发布

Redux 真的被高估了吗？我在大型项目中发现的真相

↓ Service 更新全局状态 ↓ 整个 Redux store 重新渲染 ↓ 弹窗才关上本来 200ms 的事，整成了 1s 多。...这就是问题的所在。到底哪些状态该全局？我仔细想过，真正需要放在全局状态里的，其实就这几种： 1. 用户认证信息这个确实要全局。任何页面、任何组件都可能需要知道"当前用户是谁"、"有没有登录"。...复杂的业务数据依赖比如电商平台的购物车。商品价格、用户积分、优惠券、运费、税金……这些数据之间有复杂的计算关系，一个变了其他都要联动。这种情况确实需要一个统一的地方管理。 4....就是 JavaScript 对象和函数。简洁很多。那 Redux 现在还有人用吗？有。但用的场景越来越具体了。...场景 2：超大型团队的中后台系统一个团队 100+ 人，多个业务线共享一个平台。Redux 的规范性和可追溯性有价值。场景 3：需要时间旅行调试的应用比如实时协作编辑、画布应用。

2111 0

在线商城库存实时更新引发页面冻结：Redux Toolkit 异步困境与紧急修复

对state.items进行遍历和查找操作，在数据量大时可能耗时。每次更新都会修改state.items数组中的元素，可能导致依赖该数组的组件频繁重渲染。...数组发生变化，导致ProductList重新渲染，进而导致所有ProductItem组件重新渲染，即使它们的库存信息没有变化3.3.5 数据更新频率分析通过日志记录，我发现促销期间热门商品的库存更新非常频繁...4.3 优化组件渲染机制为了减少不必要的组件重渲染，我们可以使用 React 的memo、useMemo和useCallback等 API 进行优化。...使用memo包装ProductItem组件，并提供自定义比较函数。直接通过 ID 从库存对象中获取商品库存信息，替代原有的find方法设计思路：减少组件重渲染次数，只在必要时才更新。...组件渲染优化是关键：React 组件的重渲染机制需要谨慎处理，合理使用memo、useMemo和useCallback等 API 可以避免大量不必要的重渲染。

4732 0

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

是的

没有找到

react结合redux实现一个购物车功能

题图 From Bing By Clm 使用react开发有一段时间了，今天给大家带来一个案例，react结合redux实现购物车功能，页面如下： ?...根据UI页面我们将其拆分为组件： header组件，cart组件，footer组件，car组件，由于car组件中渲染的是列表，所以我们把购物车物品的每一项拆分为item组件，这样我们就得到了4个组件。...接着我们看一下功能，功能分析：第一个功能，购物车的中物品数量的增加和减少功能第二个功能，结算前需要勾选要结算的物品,实现单件物品的选中与未选中状态，并且和全选复选框关联。...(通常是渲染)的数据，对照本案例，数据就是购物车中的商品。...这里需要注意的是，item组件通过props接收到父组件传递的值后，直接将其绑定到了dom上，当点击选中复选框或者数量增减按钮时，我们并没有直接修改props，这是绝对不允许的，代码中是如何做的呢？

5.6K3 0

关于React组件之间如何优雅地传值的探讨

关于什么时候引入redux我觉得也要根据项目来，如果一个项目中大多数时候只是需要跟组件内部打交道，那么引入redux反而造成了一种资源浪费，更多地引来的是学习成本和维护成本，因此并不是说所有的项目我都一定要引入...代码请看这里：https://codepen.io/rynxiao/pen/vpyzBm 这样做貌似十分简单，但是你可能会遇到这样的问题：当改变了context中的属性，但是由于并没有影响父组件中上一层的中间组件的变化...，那么上一层的中间组件并不会渲染，这样即使改变了context中的数据，你期望改变的子组件中并不一定能够发生变化，例如我们在上面的例子中再来改变一下： // Parent render() {...，我就给子组件发送消息，强制调用子组件中的forceUpdate进行渲染。...代码在这里：https://codepen.io/rynxiao/pen/QaGVgo 但在开发中，一般是不会推荐使用forceUpdate这个方法的，因为你改变的有时候并不是仅仅一个状态，但状态改变的数量只有一个

1.8K4 0

你的 React 应用真的需要依赖注入吗？深度对标 3 种架构方案

你的团队刚刚遇到一个经典的 React 问题：组件树里层层传递数据，父组件一改，十多个中间组件跟着改，太累了。...这就是 prop drilling 的本质：为了给深层组件传值，浅层组件被迫充当通道。维护这样的代码，每次改一个 prop 的名字或结构，你得改 5 个无关的组件。...❌ 你不应该用 Context 的场景频繁变化的状态（表单输入每个字都是新值） → 用 useState + 表单库（react-hook-form、Formik）全局状态但很复杂（购物车、用户偏好设置等...function Button() { const { theme } = useContext(ThemeContext); // 只用 theme // 但因为 value 对象变了，这个组件也会重新渲染...强制执行编码规范（ESLint）总结：没有银弹 Context API、依赖注入、Service Locator——它们都是好工具，但没有一个是 prop drilling 的完美解药。

1581 0

Redux真的该换了吗？2025年React状态管理的残酷真相

评测维度2：性能（避免不必要的重渲染）共享状态库最常见的问题是：修改了一个小状态，结果所有使用该store的组件都重新渲染。...Redux代码，但处理了： ✅ API数据加载和缓存 ✅ 错误处理和加载态 ✅ URL同步（compare参数可以复制链接分享） ✅ 组件内部UI切换状态 ✅ 全局用户数据 ✅ 购物车和收藏逻辑常见问题解答...如果你在一个大型企业应用中，需要高度结构化和一致的代码规范（比如金融系统），Redux Toolkit的"意见强硬"反而是优势。它的Redux DevTools调试体验也无与伦比。...但对于95%的应用来说，确实过度工程化了。 Q: Zustand能替代Redux吗？对于共享状态的需求，是的。但Zustand是"随意型"的，这对小团队很好，对大团队可能造成代码风格混乱。...在中文开发者社区中，这个转变来得稍晚一些（因为很多教程还在教Redux），但趋势是确定的。现在是抓住这个机会的好时机。

4431 0

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

Zustand是由React Spring和Jotai的作者设计的极简状态管理库。它抛弃了Redux的"仪式感"，回归到最本质的状态管理——一个简单的JS对象 + 订阅系统。...我们来看实际情况： Redux 的渲染流程： dispatch(action) ↓ reducer 运算 ↓ createSelector 计算新状态 ↓ React.memo 判断是否重新渲染...↓ 组件重新渲染中间有多个"关卡"，每个关卡都需要开发者手动优化。...Zustand 的渲染流程： set((state) => ({ ... })) ↓ WeakMap 查询订阅者 ↓ 订阅该状态的组件 hook 触发更新 ↓ 组件重新渲染更直接，更细粒度...）第六部分：深度思考——为什么会发生这个转变原因1：React 本身的进化 Redux 设计于 Class Component 时代那时候状态提升是个大问题，需要集中管理但 Hooks 的出现改变了游戏规则

2601 0

React 19真的快了吗？我同事改出来的性能真相

顶层的CustomerPage组件检测到状态变了，触发重新渲染。然后它下面的所有子组件都跟着重新渲染。包括一个从不改变的"客户统计面板"。包括"一个筛选器"。包括"底部分页器"。...关键问题是：这整个过程中，客户统计面板其实没有变，筛选器也没有变。他们本不应该重新渲染。这不是React的锅。这是他们把所有状态都放在了最顶层。...memo检查props的时候发现变了，就重新渲染。你已经在做最坏的事情（触发重新渲染），memo只是试图补救。这就像房子地基裂了，你还在重新粉刷墙皮。...然后20多个组件都收到通知，都重新渲染。但其中有15个组件其实不关心filters的变化。结果就是80多次无效重新渲染。错误3：TypeScript就是个类型检查工具这个我见得最多。...用户改搜索框，输入"张三"：之前重新渲染整个20多个组件，现在只重新渲染FilterPanel这一个。改变排序：之前重新渲染20+个组件，现在只重新渲染Table这一个。

1371 0

React 全局状态管理的 3 种底层机制

组件都支持传递一些参数来定制，也可以在内部保存一些交互状态，并且会在参数和状态变化以后自动的重新渲染对应部分的 dom。... ); } 不知道大家有没有想过，props、state 改变了，重新渲染组件很正常，context 改变了，又是怎么触发渲染的呢？...其实 react 内部做了处理，如果改变了 context 的值，那么会遍历所有的子组件，找到用到 context 值的组件，触发它的更新。...组件可以通过 props 来定制，通过 state 来保存交互状态，这些变了都会自动的重新渲染。除此之外，context 变了也会找到用到 contxt 数据的子组件来触发重新渲染。...context 和 redux 都支持通过 props 来注入数据到组件中，这样对组件是透明的、无侵入的。

2.1K0 0

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

但这真的是问题吗？答案是：通常不是。为什么？因为元素本身没有改变，所以即使 onClick 引用变了，DOM 也不会更新。...DOM 节点）父组件频繁重新渲染，但这个子组件的 props 不变何时无效： // ❌ 这样做 React.memo 形同虚设 function Parent() { const config...因为 Form 组件本身的 state 变了，它总会重新渲染。handleChange 的引用稳定并改变不了这个事实。...因为它从根本上减少了 DOM 节点数量，而 DOM 操作是最昂贵的。没有 memo 或 useCallback 能比得上减少 99% 的 DOM 节点。...当 user 变化时： UserContext.Provider 的 value 对象变了 → 所有消费这个 Context 的组件都重新渲染 → 包括那些只需要 notifications

1351 0

大多数React开发者都理解错了！虚拟DOM和Fiber究竟在干什么？

第一层真相：React在"欺骗"你的DOM 很多人理解的React是这样的：state变了→组件重新渲染→DOM更新。简单粗暴，但完全错了。真实的React做了什么？...浏览器要重新计算整个渲染树、重新计算几何信息、重新绘制视图。一个简单的改动，在幕后燃烧了几百倍的计算量。主线程角度：JavaScript执行和DOM渲染共享主线程。...虽然你平时写React代码几乎看不到Fiber的影子，但理解它的数据结构能帮你理解渲染的本质： // Fiber节点的简化结构 type Fiber = { type: Function | string...useMemo只在以下场景真正有价值：计算复杂度确实很高（比如排序一个10000项的数组）这个值被多个下游组件依赖，会触发多次render 陷阱3：在选择器中创建新对象 // Redux或其他状态管理中的常见错误...能并发渲染的真正基础，可打断、可恢复的设计让主线程真正"活"了起来你写的代码中到处都是性能陷阱，但不是因为API设计不好，而是因为你没有真正理解背后的机制未来的React开发，不是追求"全速渲染"，

2311 0

为什么说 90% 的情况下，immer 能完胜 immutable？

你发现它重新渲染了，因为普通的 class 组件只要 setState 就会渲染。...但很多情况下我们需要做性能优化，只有 props 和 state 变了才需要渲染，这时候会继承 PureComponent：但这时候你就会发现组件不再重新渲染了。...和 state，如果变了才会渲染。...在 PureComponent 的 class 组件里，按照我们的分析应该不会再渲染，只会打印一次 render：确实是这样，虽然 state 对象变了，但是 key 的值没变，不会重新渲染。...时，会对比 state 本身变没变，变了就会重新渲染为什么 function 组件里只对比了 state 没有对比每个 key 的值也很容易理解，因为本来每个 state就是用 useState 单独声明的了

6462 0

我曾用 Angular 重写了 jQuery 应用，如今却被 React 逼疯了

但即便如此，这次经历不仅证实了我的低预期没问题，而且还大大拉低了我的预期。React 让人抓狂，不知道为什么没有人谈论它。架构、组件、状态首先，让我们从 React 为你选定的架构开始。...这个问题通过使用 React 钩子将状态“侧载（sideloading）”到组件中得到了解决。对此，我还没有听到有人抱怨过，但你们是认真的吗？你们是在说任何组件都可以使用任何部分的应用状态吗？...我不够聪明，也没有深入研究，真的解决不了这个问题，但我可以提出一些想法。如果我们采用这种输入 / 输出的心理模型，将网页视为一个实际的东西，那么我们也许可以从减少它的输入和输出数量入手。...增加三个按钮会比增加两个多 5% 的 Bug，并且，未来在那个屏幕上开展的设计和实现工作复杂度会增加 30%。没有人度量这些事情，但我相信那可能是真的。...但我确实相信，我们如今有足够的带宽来加载一个小型 React 应用，它只渲染一个位于传统服务器端渲染页面里的交互岛。

2750 0

多端开发实战 | 基于 Taro 的智能商品推荐系统多端实战指南

1.2 技术栈选型依据跨端能力：Taro 3.x 支持 React 语法统一编译到 H5/小程序，减少重复代码。状态管理：Redux Toolkit 优化推荐数据的异步加载和缓存。...异步加载：使用 Redux Toolkit 的 createAsyncThunk 处理请求状态。性能优化：虚拟滚动技术解决长列表渲染问题（Taro VirtualList）。...2.2 购物车关联商品推荐算法原理：基于项目协同过滤（Item-CF）的实时计算代码实现：/** * 购物车商品推荐组件 * * 该组件根据当前购物车中的商品，通过协同过滤算法获取相关推荐商品， *...并过滤掉购物车中已存在的商品，展示最多6个推荐商品。..., setRelatedProducts] = useState([]); // 当购物车商品变化时重新计算推荐商品 useEffect(() => { // 仅当购物车非空时执行推荐逻辑

7212 0

美团前端react面试题汇总

真实DOM中间加了一个缓存，利用DOM Diff 算法避免了没有必要的DOM操作，从而提高性能React-Router 4怎样在路由变化时重新渲染同一个组件？...React 中最常见的问题之一是组件不必要地重新渲染。...props的浅比较，如果 props 没有改变，那么组件将不会重新渲染。...，提高编码效率redux的缺点：当数据更新是有时候组件不需要，也要重新绘制，影响效率refs 是什么refs是react中引用的简写，有主语存储特定 React 元素或组件的引用的属性，它将由组件渲染配置函数返回当我们需要输入框的内容...（5）都可以放在单独的HTML文件中，或者放在 Webpack设置的一个更复杂的模块中。（6）都有独立但常用的路由器和状态管理库。

6.2K3 0

react16常见api以及原理剖析

两者都是用于创建 UI 的 JavaScript 库；两者都快速轻便；都有基于组件的架构；都是用虚拟 DOM；都可放入单个 HTML 文件中，或者成为更复杂 webpack 设置中的模块；都有独立但常用的路由器和状态管理库...`：（非生产环境）指定调试代码来自的文件(fileName)和代码行数(lineNumber) 当组件状态 state 有更改的时候，react 会自动调用组件的 render 方法重新渲染整个组件的...JSON 中不能存储 Symbol 类型的变量，而 react 渲染时会把没有 \$\$typeof 标识的组件过滤掉。...key 的策略，对 element diff 进行算法优化；建议，在开发组件时，保持稳定的 DOM 结构会有助于性能的提升；建议，在开发过程中，尽量减少类似将最后一个节点移动到列表首部的操作，当节点数量过大或更新操作过于频繁时...即使 React 只更新改变了的 DOM 节点，重新渲染仍然花费了一些时间。

1.3K1 0

【小狮子前端】「Redux」概念理解+实战上手（内含大量实例）

四、react-redux 可以看到上面我们并没有使用到react-redux，虽然能实现功能，但细心会发现我是直接拿的store，组件多的话个个拿store，这样不好。...connect、provider应用实例看了上面的介绍，应该能比较清楚的了解connect是干什么的了，然后也基本能明白怎么做了，但还是没有写哥实例更清楚直白的了：简单的点击增加count的实例，应该还有许多需要优化的地方...和connect来维护单独的container组件和UI组件，而是在组件中直接使用redux提供的hooks,读取redux中的state。...，每次重新渲染获得新的引用，如果作为props传递给子组件，那么子组件每次都要重新渲染。...但是还是用的connect的实例，来重新用react-redux的useSelector和useDispatch实现。

1.9K0 0

React移动web极致优化

是的，Facebook说的没错，但只说了一半，它说漏的一半是：“除非你能正确的采用一系列优化手段”。 3. 组件化另一个被大家所推崇的React优势在于，它能令到你的代码组织更清晰，维护起来更容易。...React在减少重复渲染方面确实是有一套独特的处理办法，那就是vd，但显示在首次渲染的时候React绝无可能超越原生的速度，或者一定能将其它的框架比下去。...但vd是通过看数据的前后差异去判断是否要重复渲染的，但React并没有帮助我们去做这层比较。因此我们需要使用一整套数据管理工具及对应的优化方法去达成。在这方法，我们选择了Redux。...但放到移动端上，我们在列表页重构的时候就马上遇到卡顿的问题了。什么原因呢？是重复渲染导致的！！！！！！说好的React vd可以减少重复渲染呢？！！！请别忘记前提条件！！！！...Immutable能减少无谓的重新渲染，但可能没想过会导致页面不能正确地重新渲染。

1.8K8 0

React 同构直出优化总结

而最近一段时间，我们将手Q的家校群重构成 React，除了原有框架上存在明显问题的原因外，选择React也是因为它确实有足够的吸引力以及优势，加之在PC家校群上的实践经验，斟酌下便开始了，到现在已有页面在线上正常跑起...以上便是 React 在同构/服务端渲染的提供的基础条件。在实际项目应用中，还需要考虑其他边角问题，例如服务器端没有 window 对象，需要做不同处理等。...保持数据的确定性这里指影响组件 render 结果的数据，举个例子，下面的组件由于在服务端与客户端渲染上会因为组件上产生不同随机数的原因而导致客户端将重新渲染。...优化成果服务端上的耗时增加了，但整体上的首屏渲染完成时间大大减少。...服务端上增加的耗时服务端渲染方案将数据的拉取和模板的渲染从客户端移到了服务端，由于服务端的环境以及数据拉取存在优势(详见 Node直出理论与实践总结)，所以在相比下，这块耗时大大减少，但确实存在，这两块耗时是服务端渲染相比于客户端渲染在服务端上多出来

2.5K1 0

重谈react优势——react技术栈回顾

virtual dom虚拟DOM概念它并不直接对DOM进行操作，引入了一个叫做virtual dom的概念，安插在javascript逻辑和实际的DOM之间，好处是减少DOM操作，减少DOM操作的目的是提高浏览器的渲染性能...但高阶组件本身并不是React API。它只是一种模式，这种模式是由react自身的组合性质必然产生的。...但如果此时有若干细节需要处理，比如你的组件需要渲染子组件，而且子组件取决于父组件的某个属性，那么在子组件的componentDidMount中进行处理会有问题：因为此时父组件中对应的属性可能还没有完整获取...在 React Diff 算法中 React 会借助元素的 Key 值来判断该元素是新近创建的还是被移动而来的元素，从而减少不必要的元素重渲染。...结构会有助于性能的提升；建议，在开发过程中，尽量减少类似将最后一个节点移动到列表首部的操作，当节点数量过大或更新操作过于频繁时，在一定程度上会影响 React 的渲染性能。

1.6K3 0

点击加载更多

Redux 真的被高估了吗？我在大型项目中发现的真相

在线商城库存实时更新引发页面冻结：Redux Toolkit 异步困境与紧急修复

react结合redux实现一个购物车功能

关于React组件之间如何优雅地传值的探讨

你的 React 应用真的需要依赖注入吗？深度对标 3 种架构方案

Redux真的该换了吗？2025年React状态管理的残酷真相

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

React 19真的快了吗？我同事改出来的性能真相

React 全局状态管理的 3 种底层机制

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

大多数React开发者都理解错了！虚拟DOM和Fiber究竟在干什么？

为什么说 90% 的情况下，immer 能完胜 immutable？

我曾用 Angular 重写了 jQuery 应用，如今却被 React 逼疯了

多端开发实战 | 基于 Taro 的智能商品推荐系统多端实战指南

美团前端react面试题汇总

react16常见api以及原理剖析

【小狮子前端】「Redux」概念理解+实战上手（内含大量实例）

React移动web极致优化

React 同构直出优化总结

重谈react优势——react技术栈回顾

相关资讯

热门标签

活动推荐

运营活动

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐