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
和MessageChanne
l,如果执行环境不支持,会采用 setTimeout(fn, 0)
代替。
4.Vue怎么进行依赖收集的
Observer
的构造函数使用defineReactive
方法给对象的键响应式化,给对象的属性递归添加 getter/setter
,当data
被取值的时候触发 getter
并搜集依赖,当被修改值的时候先触发getter
再触发setter
并派发更新
每个组件实例都有相应的 Watcher
实例对象,它会在组件渲染的过程中把属性记录为依赖,之后当依赖项的setter
被调用时,会通知watcher
重新计算,从而致使它关联的组件得以更新。
5.为什么需要Vuex
一、多个视图依赖于同一状态。
二、来自不同视图的行为需要变更同一状态。
对于问题一,传参的方法对于多层嵌套的组件将会非常繁琐,并且对于兄弟组件间的状态传递无能为力。对于问题二,我们经常会采用父子组件直接引用或者通过事件来变更和同步状态的多份拷贝。以上的这些模式非常脆弱,通常会导致无法维护的代码。
因此,我们为什么不把组件的共享状态抽取出来,以一个全局单例模式管理呢?在这种模式下,我们的组件树构成了一个巨大的“视图”,不管在树的哪个位置,任何组件都能获取状态或者触发行为!
另外,通过定义和隔离状态管理中的各种概念并强制遵守一定的规则,我们的代码将会变得更结构化且易维护。
6.介绍一下Vue中的computed
我们可以将同一函数定义为一个方法而不是一个计算属性。两种方式的最终结果确实是完全相同的。然而,不同的是计算属性是基于它们的响应式依赖进行缓存的。只在相关响应式依赖发生改变时它们才会重新求值。
计算属性的setter
VSwatch
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
有更高的初始渲染消耗