云南技术网站建设销售,上海建设网站是国家级吗,wordpress上传出错,网页设计网站维护大家好#xff0c;我是若川。持续组织了8个月源码共读活动#xff0c;感兴趣的可以点此加我微信 ruochuan12 参与#xff0c;每周大家一起学习200行左右的源码#xff0c;共同进步。同时极力推荐订阅我写的《学习源码整体架构系列》 包含20余篇源码文章。历史面试系列前言在… 大家好我是若川。持续组织了8个月源码共读活动感兴趣的可以点此加我微信 ruochuan12 参与每周大家一起学习200行左右的源码共同进步。同时极力推荐订阅我写的《学习源码整体架构系列》 包含20余篇源码文章。历史面试系列前言在 Vue 中computed 是一个非常好用的 API用于处理派生状态又叫“计算属性”。网上将其用于性能优化的场景比比皆是。但它也有严重影响性能的一面本文主要是聊聊这种场景。聊之前我们先看看它为什么能够做到性能优化。computed 的两个特点缓存结果只有依赖项变化的时候才会重新计算否则复用上一次计算的结果。惰性求值只有在真正读取它的 value 时才会进行计算求值。缓存结果const todos reactive([{ title: 点赞, done: true},{ title: 关注, done: false }
])const openTodos computed(() todos.filter(todo !todo.done)
)在上图的例子中只要 todos 不变多次使用 openTodos 将返回相同的值不会重新计算。当 todos 变化时openTodos 会被标记为 dirty下次取值时才会进行重新计算。这点对计算量开销较大的场景非常有用确保了只有在必要时才会重新计算。惰性求值只有在使用 computed 时它才会进行计算。如果一个计算属性计算开销非常非常大但它没有被任何地方使用也不会进行求值。computed 提升性能的场景如上所说computed 的延迟计算通常是一件好事它确保了必要时才会进行计算。下面是一个简单的 Todo 例子简单说明一下有一个 todos 列表showList 用于控制是否展示列表openTodos 是计算未完成 todos 列表的计算属性依赖 todoshasOpenTodos 是计算是否有未完成 todos 的计算属性依赖 openTodostemplatebutton clickshowList !showList点击展示/隐藏/buttontemplate v-ifshowListtemplate v-ifhasOpenTodosh2{{ openTodos.length }} Todos:/h2 ulli v-fortodo in openTodos{{ todo.title }}/li/ul/templatespan v-else没有任何 Todo/spaninput typetext v-modelnewTodobutton typebutton v-on:clickaddTodo添加 Todo/button/template
/templatescript setup
const showList ref(false)const todos reactive([{ title: 点赞, done: true},{ title: 关注, done: false }
])
const openTodos computed(() todos.filter(todo !todo.done)
)
const hasOpenTodos computed(() !!openTodos.value.length
)const newTodo ref()
function addTodo() {todos.push({title: newTodo.valuedone: false,})
}
/script因为 showList 最初是 false所以模板中不会读取 openTodos不会产生计算。并且无论是一开始还是添加了新的 todo。只有在 showList 设置为 true 之后模板中才会读取 openTodos这才会触发相应的计算。这对于开销大的计算属性来说是有很大好处的。computed 影响性能的场景惰性求值也会带来一个缺点计算属性的返回结果只有在对它进行计算后才会知道。听起来可能比较难以理解同样用一个例子来说明有一个 list 列表一个增加 count 的按钮一旦 count 超过 100isOver100就反向展示 list当然这里反向展示 list计算量并不大。我们将它想象成一次开销很大的计算templatebutton clickincrease添加计数/buttonh3列表/h3ulli v-foritem in sortedList{{ item }}/li/ul
/templatescript setup
import { ref, reactive, computed, onUpdated } from vueconst list reactive([1,2,3,4,5])const count ref(0)
function increase() {count.value
}const isOver100 computed(() count.value 100)const sortedList computed(() {// 这里比较简单可以将它想象成开销大的计算return isOver100.value ? [...list].reverse() : [...list]
})onUpdated(() {// 组件重新渲染时触发console.log(count is, count.value)console.log(component re-rendered!)
})
/script预期情况当我们点击 1-100 次时因为 count 小于 100list 不会反向展示组件不会重新渲染当点击第 101 次时 list 才会反向展示组件这时候才重新渲染因此预期总计重新渲染 1 次。但运行结果告诉我们组件会重新渲染 101 次让我们一步一步来看发生了什么。依赖关系如图点击按钮计数增加。由于模板中没有使用 count理论上不会重新渲染。但 count 改变后依赖 count 的计算属性 isOver100 被标记为 dirty在下次使用时需要重新计算并告知了它的订阅者。因为 sortedList 依赖 isOver100收到 isOver100 的通知后它也被标记为 dirty在下次使用时需要重新计算并告知了它的订阅者。最终模板中使用了 sortedList所以收到 sortedList 的更新通知后组件重新渲染了。重新渲染时计算 sortedList接着计算 isOver100但现在由于 count 不到 100isOver100 仍然返回 false。最终 sortedList 计算结果与原来一致重新渲染后 DOM 无任何改变但是我们却运行了多次大开销的 sortedList 计算简单来说因为 count 变了所以 isOver100 “觉得”自己变了需要重新算但其实没有就让依赖它的 sortedList 重新计算了。根本原因就是 isOver100它是一个频繁计算且计算非常简单的 computed多次计算返回值也与之前相同都为 false。它只发挥了 computed 状态派生的作用。但在计算开销大的 sortedList 中依赖了廉价的 isOver100因为 computed 是惰性求值的isOver100 的计算结果只能在渲染时重新计算才会知道所以 sortedList 也只能在渲染时等待它的计算结果再重新计算哪怕最终结果一致。导致触发了不必要的重新渲染用的不好会严重影响性能。所以影响性能的 computed通常都有这样的特征一个计算简单的 computed频繁触发计算并且返回值通常变化不大比如上面的 boolean 类型另一个计算开销大的 computed依赖这个廉价的 computed如何解决我们发现根因是由于 computed 的惰性求值让 isOver100 觉得自己变了需要重新计算导致了这一系列的连锁反应。但因为它的计算是廉价的频繁计算也不会影响性能。有没有办法不要 computed 的延迟计算呢在 isOver100 觉得自己变了的时候马上就能知道是不是真的变了。在发现自己其实没变后不再通知订阅者也就没有了后续的重新渲染。我们可以将它的计算提前在依赖变化时就立刻计算得到结果。设计一种立刻求值的 eagerComputedVue 的响应式系统为我们提供了构建自定义 computed 所必要的工具。手动点赞 如果项目已经引入了 vueuse可直接使用import { watchEffect, shallowRef, readonly } from vueexport function eagerComputed(fn) {const result shallowRef()watchEffect(() {result.value fn()}, {flush: sync // 使用同步观察器依赖变化时立刻求值})return readonly(result)
}eagerComputed 与 computed 用法一致只是行为上不同在依赖变化时它会立刻进行求值。什么时候使用 computed 和 eagerComputed复杂的计算使用 computed可以受益于缓存结果和惰性求值。简单的计算使用 eagerComputed因为每次依赖项变化时它都会重新计算。回到上面的例子中我们将 isOver100 改为 eagerComputedconst isOver100 eagerComputed(() count.value 100);现在当点击按钮 101 次时组件才会重新渲染。我们打个接地气的比方比方代码大家吃饭后都会“觉得”自己体重涨了isOver100 觉得自己变了为了验证涨没涨需要下楼去称体重因为家里没有要让 sortedList 重新计算而下楼是个麻烦的事情sortedList 的计算开销很大称完发现并没涨白跑一趟isOver100 其实没变为了不每次都白跑一趟我们可以在家里买个秤使用 eagerComputed变没变马上就知道结语我们深入了解了 computed 的工作原理与两大特性缓存结果和惰性求值。掌握了什么场景会优化性能什么场景会影响性能对于影响性能的场景可以使用 eagerComputed 避免不必要的响应式更新来解决性能问题。参考https://dev.to/linusborg/vue-when-a-computed-property-can-be-the-wrong-tool-195j················· 若川简介 ·················你好我是若川毕业于江西高校。现在是一名前端开发“工程师”。写有《学习源码整体架构系列》20余篇在知乎、掘金收获超百万阅读。从2014年起每年都会写一篇年度总结已经坚持写了8年点击查看年度总结。同时最近组织了源码共读活动帮助3000前端人学会看源码。公众号愿景帮助5年内前端人走向前列。扫码加我微信 ruochuan02、拉你进源码共读群今日话题略。分享、收藏、点赞、在看我的文章就是对我最大的支持~
