8.1

docs/src/pages/FixedArticle/vue/index.md

@@ -335,9 +335,131 @@ diff整体策略为： 深度优先，同级比较
     - 旧节点和新节点自身不一样，当发现两个节点不一致时，直接创建新节点，然后删除旧节点
 - pathVnode的操作： 会进行如下几个判断
      - 新节点是否是文本节点，如果是文本节点，则直接更新dom的文本节点内容为新节点的文本内容
-     - 新节点和旧节点是否都有子节点，
+     - 新节点和旧节点是否都有子节点，则处理比较，更新子节点
+     - 只有新节点有子节点，旧节点没有子节点，那么不用比较，直接，那么将全部新建子节点。新建是指全部创建出所有新的dom，并添加进父节点
+     - 只有旧节点有子节点，新节点没有子节点，那么就会删除所有旧节点，创建新的节点
+- 子节点如果完全不一致，则调用updateChildren
+- while循环主要处理了以下五中情景：
+     - 当新老Vnode节点start 相同时，直接patchVnode，同时新老节点的开始索引都+1
+     - 当新老vnode节点end相同时，也直接patchVnode,同时新老节点的结束索引都-1
+     - 当老Vnode节点的satrt与新Vnode节点的end相同时，直接进行patchVnode，同时还需要将当前真实dom节点移动到oldEndVnode的后面，并且老Vnode节点索引+1 新Vnode节点索引-1
+     - 当老Vnode节点的end与新Vnode节点的start相同时，直接进行patchVnode，同时还需要将当前真实dom节点移动到oldStartVnode的前面，并且老Vnode节点索引-1 新Vnode节点索引+1
+     - 如果都不满足以上四种情形，那么就说明没有相同的节点可以复用，则会分为以下两种情况
+         - 从旧的Vnode为key值，对应index序列为value值的哈希表中找到newStartVnode一致key的旧Vnode的节点，再进行patchVnode，同时将这个真是dom的实力移动到oldStartVnode对应的真实dom的前面
+         - 调用createElem创建一个新的dom节点放到当前newStartIdx的位置
+# axios
+### 什么是axios
+- axios是一个轻量的http客户端，是基于XMLHttpRequest服务来执行http请求，支持丰富的配置，支持promise，支持浏览器端和nodeJS端，
+### 特性
+- 从浏览器创建XMLHttpRequest
+- 从nodeJS端创建http请求
+- 支持Promise API
+- 拦截请求和响应
+- 转换请求数据和相应数据
+- 取消请求
+- 自动转换json数据
+- 客户端支持防御XSRF
+### 为什么要封装axios？
+- 因为每个业务的差异比较大，并且大多数请求，都涉及请求头，超时时间，环境地址等因素，如果我们一个一个去设置，会过于麻烦，违背了高内聚弱耦合的的原则
 
+# SSR 
+### SSR是什么
+- server-side rendering 简称ssr （服务端渲染） 是指由服务侧完成页面的html结构拼接的页面处理技术，发送到浏览器，然后为其绑定状态和事件，成为完全可交互页面的过程
+### web页面渲染的发展史
+- 传统服务端渲染SSR：网页的所有内容在服务端完成渲染，然后一次性传输到浏览器，缺点：由于全在服务端渲染，那么对于服务器的压力比较大
+- 单页面应用SPA：页面完全交由浏览器进行页面渲染，缺点:因为一开始需要加载很多内容，所以很容易导致首屏页面渲染时间过长，
+- 服务端渲染SSR：页面首屏会交由服务器端进行渲染，浏览器拿到拿到的内容包括首屏以及完整的spa结构，应用激活后依旧按照spa的方式进行，缺点：需要单独学习ssr技术，比较考验技术水平
+### vue SSR
+- VUE SSR是一个在SPA上进行改良的服务端渲染
+- 通过VUE SSR渲染的页面，需要在客户端激活才能使用
+- VUE SSR会包含两部分，服务端渲染的首屏，包含交互的SPA
+### 为什么使用SSR
+- 利于SEO优化：搜索引擎优先爬取页面的HTML结构，使用SSR时，服务端已经生成了和业务相关联的HTML结构，有利于SEO的优化
+- 首屏呈现渲染：用户无需等待所有页面的js加载完成就可以看到整个页面的视图
+- 缺点：
+     - 复杂度增高：整个项目的复杂度会比单独使用spa要高一些
+     - 库的支持性，代码兼容
+     - 性能问题：
+         - 每一个请求都是n个实例的创建 ，不然会污染，消耗变得很大
+         - 降级: 监控cpu、内存占用过多，就spa，返回单个的壳
+     - 服务器负载变大，相对于前后端分离服务器只需要提供静态资源来说，服务器的负载会更大
+# 权限管理
+前端权限控制可以分为四个方面
+- 接口权限
+- 按钮权限
+- 菜单权限
+- 路由权限
+
+##### 接口权限
+ 接口权限目前一般主要采用jwt形式来验证 ，没有通过的话一般返回401，跳转到登陆页面重新进行登陆，登录完成拿到token，然后存储起来，在每次请求的时候将token携带到请求头内
+##### 路由权限控制
+- 方案一：初始化即挂载全部路由，并在路由上标记相对应的权限信息，每次路由跳转前做一次权限校验
+     - 缺点：
+          1. 加载所有的路由，加载的路由会很多，而用户并不是所有路由都有权限访问，那么就会对性能有一些影响
+          2. 全局路由守卫里，每次跳转都需要做一次权限判断 
+          3. 菜单信息写死在前端，如果需要更改显示文字或者路由信息，就需要重新进行编译
+          4. 菜单跟路由耦合在一起的话，定义路由的时候，还要添加菜单的标题，图标等等之类的信息，但是路由不一定作为菜单显示，那么就需要多加字段进行标识了
+- 方案二：初始化的时候不挂载全部路由，只挂在不要权限的路由，例如登陆，404页面等，如果用户通过修改url进行强制访问，那么会被引导到404页面，这相当于从源头上做了控制，登陆后，获取用户权限信息，然后匹配相对应的路由，通过addRoutes方法来进行路由添加
+     - 缺点：
+         1. 全局路由守卫里，每一次跳转都需要做判断
+         2. 菜单信息写死在前端，如果需要更改显示文字或路由信息，需要重新进行编译
+         3. 菜单跟路由耦合在一起的话，定义路由的时候，还要添加菜单的标题，图标等等之类的信息，但是路由不一定作为菜单显示，那么就需要多加字段进行标识了
+##### 菜单权限
+菜单权限可以理解成将页面和路由进行解偶
+- 方案一：菜单与路由分离，菜单由后端进行返回 前端来定义路由信息
+     - 缺点：
+          1. 菜单与路由需要一一对应，前端添加了新功能，需要通过菜单管理功能添加新的菜单，如果菜单配置的不正确，就会导致某些功能无法正常使用
+          2. 全局路由守卫，每次跳转都需要做一次判断
+- 方案二：菜单和路由都由后端进行返回，前端统一定义路由组件
+     - 缺点：
+         1. 对于前后端的配合要求更高了   
+         2. 全局路由守卫，每次跳转都需要做一次判断
+##### 按钮权限
+- 方案一： 通过v-if来进行判断，但是如果页面过多，每个页面都要获取用户权限role和路由表里的meta.btnPermissions,然后再做判断
+- 方案二：通过自定义指令进行按钮权限判断，在使用的按钮中只需要通v-has
+# 跨域
+### 什么是跨域
+- 跨域的先决条件是浏览器端才会出现的问题，如果是服务端对服务端，不会出现这个问题
+- 跨域的条件是必须违背同源策略：端口、域名、协议、三者只要有任意一项不符合，都属于跨域。
+### 如何解决
+- jsonp
+- Cors :后端设置响应头 Access-Control-Allow-Origin为host
+- proxy：服务器代理，三种方式：
+      1. 如果我们的项目是通过脚手架构建的，那么实际上我们可以通过webpack在本机起一个本地服务器作为请求的代理对象
+      2. 通过服务端进行请求代理转发
+      3. 通过配置nginx实现代理  
+
+# Vue3和vue2的区别
+- 速度更快
+- 体积更小
+- 更易维护
+- 更接近原生
+- 更易使用
+### 速度更快
+vue3相比较vue2：
+- 重写了虚拟dom的视线
+- 编译模板的优化
+- 更高效的组件初始化
+- undate性能提高1.3~2倍
+- SSR速度提高了2~3倍
+### 体积更小
+- 通过three-shaking，实现了按需加载，减少了打包的代码体积
+### 更易维护
+实现了compositon API
+- 可以与现有的options api一起使用
+- 灵活的逻辑组合和复用
+- vue3模块可以搭配其他框架使用
+- 更好地对ts的支持
+### 更接近原生
+- 可以自定义渲染API
+### 更易使用
+- 响应式api暴露出来
 
+# vue3 新特性
+- framents 多个根组件
+- Teleport Teleport 是一种能够将我们的模板移动到 DOM 中 Vue app 之外的其他位置的技术
+- createRender 能够构建自定义渲染器，我们能够将 vue 的开发模型扩展到其他平台  我们可以将其生成在canvas画布上
+- composition Api 更加容易维护我们的代码，将相同功能的变量进行一个集中式的管理