前言 jquery时代更新视图是直接对DOM进行操作，缺点是 频繁 操作真实 DOM，性能差。react和vue时代引入了虚拟DOM，更新视图是对新旧虚拟DOM树进行一层层的遍历比较，然后找出需要更新的DOM节点进行更新。这样做的缺点就是如果DOM树很复杂，在进行新旧DOM树比较的时候性能就比较差了。那么有没有一种方法是不需要去遍历新旧DOM树就可以知道哪些DOM需要更新呢？ 答案是：在编译时我们就能够知道哪些节点是静态的，哪些是动态的。在更新视图时只需要对这些动态的节点进行靶向更新，就可以省去对比新旧虚拟DOM带来的开销。vue3也是这样做的，甚至都可以抛弃虚拟DOM。但是考虑到渲染函数的灵活性和需要兼容vue2，vue3最终还是保留了虚拟DOM。 这篇文章我们来讲讲vue3是如何找出动态节点，以及响应式变量修改后如何靶向更新。 注：本文使用的vue版本为 3.4.19 靶向更新的流程 先来看看我画的整个靶向更新的流程，如下图：![图片](https://static.developers.pub/83c8149bf0db47febb449a6794...

1. provide/inject provide/inject 是 Vue.js 中用于跨组件传递数据的一种高级技术，它可以将数据注入到一个组件中，然后让它的所有子孙组件都可以访问到这个数据。通常情况下，我们在父组件中使用 provide 来提供数据，然后在子孙组件中使用 inject 来注入这个数据。 使用 provide/inject 的好处是可以让我们在父组件和子孙组件之间传递数据，而无需手动进行繁琐的 props 传递。它可以让代码更加简洁和易于维护。 但需要注意的是，provide/inject 的数据是非响应式的，这是因为provide/inject是一种更加底层的 API，它是基于依赖注入的方式来传递数据，而不是通过响应式系统来实现数据的更新和同步。 具体来说，provide方法提供的数据会被注入到子组件中的inject属性中，但是这些数据不会自动触发子组件的重新渲染，如果provide提供的数据发生了变化，子组件不会自动感知到这些变化并更新。 如果需要在子组件中使用provide/inject提供的数据，并且希望这些数据能够响应式地更新，可以考虑使用V...

背景 背景是这样的，我们使用 vue2 开发一个在线客服使用的IM应用，基本布局是左边是访客列表，右边是访客对话，为了让对话加载更友好，我们将对话的路由使用 <keep-alive 缓存起来。但是如果将所有对话都缓存，未必会造成缓存过多卡顿的问题。自然，就使用上了 <keep-alive 提供的 max 属性，设置一个缓存对话内容组件上限，按照 <a class="wx_search_keyword" LRU</a 算法，会销毁最旧访问的组件，保留最近使用的组件。本以为美好如期而至，直到上线后翻大车了，真实对话量大了，内存飙升卡顿。后来具体分析内存增长点，通过 vue 的 devtool 查看组件树，发现对话内容组件一直是递增，并非维持在 max 设置的数量上限！各位看官稍安勿躁，下面就具体分析造成这个「大坑」的原理，以及解决它的方案。 情景模拟 为了方便模拟背景案例，这里就用 vue2 简单的写一个demo。对话列表组件 APP.vue ，点击列表中的某个访客，加载与访客对话内容。 <template   <div id="ap

千呼万唤始出来干货满满的组件库打包分享！这次，终于要给大家带来关于组件库的工程化打包升级与细节的文章啦。回顾组件库的搭建，已经是很久以前了，目前组件库也发展到一个瓶颈期需要升级架构和打包了... 我认为，前端工程化更像是个命题作文，没有标准答案，能解决问题即可。所以，本文旨在以我解决问题的实战经过来分享一种组件库的打包方式，希望大家都会有所启发、有所收获！废话少说，直接开始吧。 现状&目标 很久之前我搞了个组件库，还写了文章——[从零开始搭建一个属于你自己的组件库！](http://mp.weixin.qq.com/s?__biz=MzAxODE2MjM1MA &mid=2651609159&idx=1&sn=3ebe3668bfc4ec1a402b417df913f4b0&chksm=80228f86b75506900ac8f728f01ea4ca2069412453a07bb60aeec9b1c1f49a365174bb42c2ce&scene=21 wechat_redirect)分享给大家。但其实组件库一直处于一个发展阶段，还有很多东西都不成熟，就好比今天的主

前言 本文将从渐进式、时间线、跨平台及企业级框架情况多个维度对两个库进行对比。 从概念开始 React官网说：React是用于构建用户界面的Javascript库。 Vue官网说：Vue是用于构建用户界面的Javascript渐进式框架。 一个说自己是库，一个说自己是框架，我们就先从这个细节说起。如下图Vue说自己是框架，是因为官方提供了从声明式渲染到构建工具一整套东西。 React说自己是库，是因为官方只提供了React.js这个核心库，路由、状态管理这些都是社区第三方提供了，最终整合成了一套方案。 两者最终达到的效果是相同的，也就是渐进式的解决方案，根据需求复杂度的不同，Vue和React都可以提供相匹配的、合适的解决方案。 何为声明式渲染 何为声明式渲染，为何这种方式能在前端界大行其道呢？ 声明式渲染指的是只需操作数据，不是操作视图（一般指DOM），数据就自然映射到视图上。当开发人员设定好数据和视图的映射...

提起 性能优化 很多人眼前浮现的面试经验是不是历历在目呢？反正，性能优化在我看来他永远是前端领域的 热度之王 。 最近维护的项目恰巧在这个方向下了很大功夫，一些经验之谈奉上，希望对大家有些许帮助！ 性能优化标准 既然说性能优化，那他总得有一个公认的标准，这就是我们很多次听到的 Lighthouse 在很多单位，都有着自己的性能监控平台，我们只需要引入相应的sdk，那么在平台上就能分析出你页面的存在的性能问题，大家是不是学的很神奇！ 其实除了苛刻的业务，需要 特殊的定制 ，大多数的情况下我们单位的性能优化平台本质上其实就是利用无头浏览器（Puppeteer）跑 Lighthouse 。 理解了我们单位的性能监控平台的原理之后，我们就能针对性的做性能优化，也就是面向 Lighthouse 编程 Lighthouse lighthouse^[1]^ 是 Google Chrome 推出的一款开源自动化工具...

Vue 正在不断发展，目前，在Vue 3 中有多种定义组件的方法。从选项到组合再到类 API，情况大不相同，如果您刚刚开始，可能会感到困惑。让我们定义一个简单的组件并使用所有可用的方法重构它。 1. Options API 这是在 Vue 中声明组件的最常见方式。从版本 1 开始可用，您很可能已经熟悉它。一切都在对象内声明，数据在幕后由 Vue 响应。它不是那么灵活，因为它使用 mixin 来共享行为。 <script import TheComponent from './components/TheComponent.vue' import componentMixin from './mixins/componentMixin.js' export default { name: 'OptionsAPI', components: { TheComponent, AsyncComponent: () = import('./components/AsyncComponent.vue'), }, mixins:

Vue 正在不断发展，目前，在Vue 3 中有多种定义组件的方法。从选项到组合再到类 API，情况大不相同，如果您刚刚开始，可能会感到困惑。让我们定义一个简单的组件并使用所有可用的方法重构它。 1. Options API 这是在 Vue 中声明组件的最常见方式。从版本 1 开始可用，您很可能已经熟悉它。一切都在对象内声明，数据在幕后由 Vue 响应。它不是那么灵活，因为它使用 mixin 来共享行为。 <script import TheComponent from './components/TheComponent.vue' import componentMixin from './mixins/componentMixin.js' export default { name: 'OptionsAPI', components: { TheComponent, AsyncComponent: () = import('./components/AsyncComponent.vue'), }, mixins:

undefined 的问题举几个demo 就可以说明 demo1 undefined 的全局修改问题     let undefined ="anlijun"; 输出结果: Uncaught SyntaxError: Identifier 'undefined' has already been declared 解释: 这步是在外层全局去声明一个变量undefined 值为anlijun,由于全局已经有这个变量了所以声明会报错            //众所周知var可以重复声明     var undefined ="anlijun";  输出结果: console.log(undefined)//这里打印依旧是值undefined 而不是 anlijun 解释: 这样的确可以(修改）而且不报错 但是由于 undefined 这个是 不可枚举不可写 不可配置的所以打印输出的值是undefined           demo1的总结 如果只看demo1 那么平常开发中直接使用undefined 没有任何问题,因为不可改嘛; 但是问题不是出在这,而

服务端组件在 Web 开发生态系统中变得越来越普遍。传统上，在单页面应用中，即使是服务端渲染的应用，服务端仅与第一次加载相关，之后将由客户端接管。这意味着 Web 应用的每个部分都必须能够在客户端和服务端上渲染。 相反，服务端组件允许在客户端应用程序中对单个组件进行服务端渲染。即使需要生成静态站点，也可以在 Nuxt 中使用服务端组件。这使得构建混合动态组件、服务端渲染的 HTML 甚至静态标记块的复杂站点成为可能。 事实上，Nuxt 在 React 之前就已经拥有了服务端组件功能。 1、主要优点 ⚡️ 服务端组件允许从客户端包中提取逻辑 通过将代码移至服务端组件中，这些组件（以及它们使用的组件）不再需要由 Vue 进行水合或“跟踪”。这对于可能不需要在客户端上“重新运行”的复杂或昂贵的操作特别有用，例如应用语法高亮显示或解析 markdown。 在大多数情况下，在 Nuxt 站点中使用服务端组件并不是一个万能的解决方案。相反，当在客户端上渲染组件所需的代码量过多时，这将是一个有用的选项。 🔐 服务端组件确保特权代码安全运行 当应用逻辑需要...

一、什么是设计模式？ 设计模式是一套被反复使用、多数人知晓、经过分类编目的、代码设计经验的总结。它是为了可重用代码，让代码更容易的被他人理解并保证代码的可靠性。 设计模式实际上是“拿来主义”在软件领域的贯彻实践，它是一套现成的工具，拿来即用。下面来看一下设计模式的设计原则。 二、设计几个原则 单一职责原则、开放封闭原则、里式替换原则、接口隔离原则 、依赖反转原则 、最少知识原则。 下面我们一起来看看几种在前端领域常见的设计模式： 单例模式、工厂模式、策略模式、代理模式、适配器模式、观察者模式/发布-订阅模式 三、常见的设计模式及实际案例 单例模式 1. 什么是单例模式？ 单例模式 （Singleton Pattern）又称为单体模式，保证一个类只有一个实例，并提供一个访问它的全局访问点。也就是说，第二次使用同一个类创建新对象的时候，应该得到与第一次创建的对象完全相同的对象。 Vue中的单例模式 （1）Element UI Element UI是使用Vue开发的一个前端UI框架。Elemen

本文的目的，是为了让已经有 Vue2 开发经验的 人 ，快速掌握 Vue3 的写法。 因此， 本篇假定你已经掌握 Vue 的核心内容 ，只为你介绍编写 Vue3 代码，需要了解的内容。 一、Vue3 里 script 的三种写法 首先，Vue3 新增了一个叫做组合式 api 的东西，英文名叫 Composition API。因此 Vue3 的 script 现在支持三种写法， 1、最基本的 Vue2 写法 <template   <div {{ count }}</div   <button @click="onClick"     增加 1   </button </template <script export default {   data() {     return {       count: 1,     };   },   methods: {     onClick() {       this.count += 1;     },   }, } </scr

大家好，我是沐华。最近部门招人，捞了一批简历至少都是5年以上的前端来面试，其中不乏360的，腾讯的，简历上写的基本都是熟练使用 Vue2 、 Vue3 、 React 并阅读源码对其实现原理有自己的理解，实际问起来却不免让人唏嘘 比如：既然两个框架都用过，那能说一下你觉得这俩有什么区别吗 毕竟是两个框架，不像两个 API ，要说细节上的区别就太多太多了，可能能聊几个小时都聊不完，所以你给自己的定位是什么呢 说说 Vue 和 React 的区别 青铜级 只要真正了解一些，或者用过两个框架开发，就一定能说上来的一些语法层面： Vue API 多， React API 少 Vue 双向绑定，修改数据自动更新视图，而 React 单向数据流，需要手动 setState Vue template 结构表现分离， React 用 jsx ...

引言 有这么一个需求：列表页进入详情页后，切换回列表页，需要对列表页进行缓存，如果从首页进入列表页，就要重新加载列表页。 对于这个需求，我的第一个想法就是使用keep-alive来缓存列表页，列表和详情页切换时，列表页会被缓存；从首页进入列表页时，就重置列表页数据并重新获取新数据来达到列表页重新加载的效果。 但是，这个方案有个很不好的地方就是：如果列表页足够复杂，有下拉刷新、下拉加载、有弹窗、有轮播等，在清除缓存时，就需要重置很多数据和状态，而且还可能要手动去销毁和重新加载某些组件，这样做既增加了复杂度，也容易出bug。 接下来说说我的想到的新实现方案（代码基于Vue3）。 keep-alive 缓存和清除 keep-alive 缓存原理：进入页面时，页面组件渲染完成，keep-alive 会缓存页面组件的实例；离开页面后，组件实例由于已经缓存就不会进行销毁；当再次进入页面时，就会将缓存的组件实例拿出来渲染，因为组件实例保存着原来页面的数据和Dom的状态，那么直接渲染组件实例就能得到原来的页面。 keep-alive 最大的难题就是缓存的清理，如果能有简...

5 月 16 日，Nuxt 3.5.0 正式发布，它带来了 Vue 3.3 版本、新的默认设置、交互式服务端组件、类型化页面、环境配置等。 Vue 3.3 [Vue 3.3 已经发布](https://www.developers.pub/article/1202228)，具有许多令人兴奋的特性，特别是在类型支持方面。包括： 宏中的导入和复杂类型支持 通用组件 更符合人体工程学的 defineEmits 使用 defineSlots 的类型插槽 响应式 Props 解构 defineModel defineOptions 使用 toRef 和 toValue 实现更好的 getter 支持 JSX 导入源支持 维护基础设施改进 Nitropack v2.4 Nuxt.js 团队一直致力于对 Nitro 进行大量改进，这些改进已经在 Nitro v2.4 中实现——其中包含许多错误修复、Cloudflare 模块工作格式的更新、Vercel KV 支持等。 注意： 如果需要部署到 Vercel 或 Netlify ...