前端学习笔记（十三）

1.Vue 经常使用的指令：

v-model
v-if
v-else
v-show
v-for
v-bind----简写: :class="qq"、:type="text"
v-on----简写: @click="qq"

2.v-model的原理

text 和 textarea 元素使用 value 属性和 input 事件；
checkbox 和 radio 使用 checked 属性和 change 事件；
select 字段将 value 做为 prop 并将 change 做为事件。
修饰符：
.lazy .number .trim

3.修改页面上绑定的变量值，好比一段文章的title，下一行代码是否能当即获取到title的变化

不能。须要nextTick。 Vue 异步执行 DOM 更新。只要观察到数据变化，Vue 将开启一个队列，并缓冲在同一事件循环中发生的全部数据改变。若是同一个 watcher 被屡次触发，只会被推入到队列中一次。这种在缓冲时去除重复数据对于避免没必要要的计算和 DOM 操做上很是重要。而后，在下一个的事件循环“tick”中，Vue 刷新队列并执行实际 (已去重的) 工做。Vue 在内部尝试对异步队列使用原生的 Promise.then 和MessageChannel，若是执行环境不支持，会采用 setTimeout(fn, 0)代替。

4.Vue怎么进行依赖收集的

Observer 的构造函数使用 defineReactive 方法给对象的键响应式化，给对象的属性递归添加 getter/setter ，当data被取值的时候触发 getter 并搜集依赖，当被修改值的时候先触发 getter 再触发 setter 并派发更新

每一个组件实例都有相应的 Watcher 实例对象，它会在组件渲染的过程当中把属性记录为依赖，以后当依赖项的 setter 被调用时，会通知 watcher 从新计算，从而导致它关联的组件得以更新。

5.为何须要Vuex

1、多个视图依赖于同一状态。
2、来自不一样视图的行为须要变动同一状态。
对于问题一，传参的方法对于多层嵌套的组件将会很是繁琐，而且对于兄弟组件间的状态传递无能为力。对于问题二，咱们常常会采用父子组件直接引用或者经过事件来变动和同步状态的多份拷贝。以上的这些模式很是脆弱，一般会致使没法维护的代码。

所以，咱们为何不把组件的共享状态抽取出来，以一个全局单例模式管理呢？在这种模式下，咱们的组件树构成了一个巨大的“视图”，无论在树的哪一个位置，任何组件都能获取状态或者触发行为！
另外，经过定义和隔离状态管理中的各类概念并强制遵照必定的规则，咱们的代码将会变得更结构化且易维护。

6.介绍一下Vue中的computed

咱们能够将同一函数定义为一个方法而不是一个计算属性。两种方式的最终结果确实是彻底相同的。然而，不一样的是计算属性是基于它们的响应式依赖进行缓存的。只在相关响应式依赖发生改变时它们才会从新求值。

计算属性的 setter VS watch
A.当组件初始化的时候，computed 和 data 会分别创建各自的响应系统，Observer遍历 data 中每一个属性设置 get/set数据拦截
B.初始化 computed 会调用 initComputed 函数
a.注册一个 watcher 实例，并在内实例化一个 Dep 消息订阅器用做后续收集依赖（好比渲染函数的 watcher 或者其余观察该计算属性变化的 watcher ）
b.调用计算属性时会触发其Object.defineProperty的get访问器函数
c.调用 watcher.depend() 方法向自身的消息订阅器 dep 的 subs 中添加其余属性的 watcher
d.调用 watcher 的 evaluate 方法（进而调用 watcher 的 get 方法）让自身成为其余 watcher 的消息订阅器的订阅者，首先将 watcher 赋给 Dep.target，而后执行 getter 求值函数，当访问求值函数里面的属性（好比来自 data、props 或其余 computed）时，会一样触发它们的 get 访问器函数从而将该计算属性的 watcher 添加到求值函数中属性的 watcher 的消息订阅器 dep 中，当这些操做完成，最后关闭 Dep.target 赋为 null 并返回求值函数结果。
C.当某个属性发生变化，触发 set 拦截函数，而后调用自身消息订阅器 dep 的 notify 方法，遍历当前 dep 中保存着全部订阅者 wathcer 的 subs 数组，并逐个调用 watcher 的 update 方法，完成响应更新。

7.Webpack的流程

• 初始化参数：从配置文件和 Shell 语句中读取与合并参数，得出最终的参数；
• 开始编译：用上一步获得的参数初始化 Compiler 对象，加载全部配置的插件，执行对象的 run 方法开始执行编译；
• 肯定入口：根据配置中的 entry 找出全部的入口文件
• 编译模块：从入口文件出发，调用全部配置的 Loader对模块进行翻译，再找出该模块依赖的模块，再递归本步骤直到全部入口依赖的文件都通过了本步骤的处理；
• 完成模块编译：在通过第4步使用 Loader 翻译完全部模块后，获得了每一个模块被翻译后的最终内容以及它们之间的依赖关系；
• 输出资源：根据入口和模块之间的依赖关系，组装成一个个包含多个模块的 Chunk，再把每一个 Chunk 转换成一个单独的文件加入到输出列表，这步是能够修改输出内容的最后机会；
• 输出完成：在肯定好输出内容后，根据配置肯定输出的路径和文件名，把文件内容写入到文件系统。 在以上过程当中，webpack 会在特定的时间点广播出特定的事件，插件在监听到感兴趣的事件后会执行特定的逻辑，而且插件能够调用 webpack 提供的 API 改变 webpack 的运行结果。

8.Class的Constructor调用Super

A.看成函数使用
在 constructor 中必须调用 super 方法，由于子类没有本身的 this 对象，而是继承父类的 this 对象，而后对其进行加工,而 super 就表明了父类的构造函数。
B.看成对象使用
在普通方法中，指向父类的原型对象；在静态方法中，指向父类。

9.Node里面两个文件互相require怎样

为了防止模块载入的死循环，Node.js 在模块第一次载入后会把它的结果进行缓存，下一次再对它进行载入的时候会直接从缓存中取出结果。因此在这种循环依赖情形下，不会有死循环，可是却会由于缓存形成模块没有按照咱们预想的那样被导出。
详细点击连接🔗

10.移动端响应式、自适应适配

响应式设计与自适应设计的区别：响应式开发一套界面，经过检测视口分辨率，针对不一样客户端在客户端作代码处理，来展示不一样的布局和内容；自适应须要开发多套界面，经过检测视口分辨率，来判断当前访问的设备是pc端、平板、手机，从而请求服务层，返回不一样的页面。
响应式布局的实现方案：
A.媒体查询
B.百分比布局
C.rem布局
D.视口单位vh、vw、vmax、vmin

11.bootstrapt实现响应式的原理是什么

Bootstrap采起12列的栅格体系，根据主流设备的尺寸进行分段，每段宽度固定，经过百分比和媒体查询实现响应式布局。

12.304缓存

强缓存经过Expires和Cache-Control两种响应头实现
Expires是http1.0提出的一个表示资源过时时间的header，它描述的是一个绝对时间，由服务器返回。
Expires 受限于本地时间，若是修改了本地时间，可能会形成缓存失效
Cache-Control 出现于 HTTP / 1.1，优先级高于 Expires ,表示的是相对时间
Cache-Control: no-cache 是能够缓存到本地缓存区中的，只是在与原始服务器进行新鲜度再验证以前，缓存不能将其提供给客户端使用；
Cache-Control: no-store才是真正的不缓存数据到本地；
Cache-Control: public能够被全部用户缓存（多用户共享），包括终端和CDN等中间代理服务器；
Cache-Control: private只能被终端浏览器缓存（并且是私有缓存），不容许中继缓存服务器进行缓存；
协商缓存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】这两对Header来管理的

13.react的生命周期函数

React生命周期主要包括三个阶段：初始化阶段、运行中阶段和销毁阶段，在React不一样的生命周期里，会依次触发不一样的钩子函数
A.初始化阶段

• 设置组件的默认属性
• 设置组件的初始化状态
• componentWillMount()
• render()
• componentDidMount()

B.运行中阶段

• componentWillReceiveProps()
• shouldComponentUpdate()
• componentWillUpdate()
• componentDidUpdate()

C.销毁阶段

• componentWillUnmount()

14.react组件之间的传递数据

• Props
• context
• redux

15.HTTP2.0

• 二进制传输
• 多路复用
• Header压缩
• 服务器推送
• 更安全

16.position的属性

• static
• relative
• absolute
• fixed
• stacky

17.HTTPS（securely transferring web pages）服务器

默认端口号为443/tcp  443/udp

18.21.v-if、v-show

官方解释：
v-if 是“真正”的条件渲染，由于它会确保在切换过程当中条件块内的事件监听器和子组件适当地被销毁和重建。
v-if 也是惰性的：若是在初始渲染时条件为假，则什么也不作——直到条件第一次变为真时，才会开始渲染条件块。
相比之下，v-show 就简单得多——无论初始条件是什么，元素老是会被渲染，而且只是简单地基于 CSS 进行切换。
通常来讲，v-if 有更高的切换开销，而 v-show 有更高的初始渲染开销。
所以，若是须要很是频繁地切换，则使用 v-show 较好；若是在运行时条件不多改变，则使用 v-if 较好。
理解：

• 手段：v-if是动态的向DOM树内添加或者删除DOM元素；v-show是经过设置DOM元素的display样式属性控制显隐；
• 编译过程：v-if切换有一个局部编译/卸载的过程，切换过程当中合适地销毁和重建内部的事件监听和子组件；v-show只是简单的基于css切换；
• 编译条件：v-if是惰性的，若是初始条件为假，则什么也不作；只有在条件第一次变为真时才开始局部编译（编译被缓存后，而后再切换的时候进行局部卸载); v-show是在任何条件下（首次条件是否为真）都被编译，而后被缓存，并且DOM元素保留；
• 性能消耗：v-if有更高的切换消耗；v-show有更高的初始渲染消耗