关于前端:美团前端面试题整理

箭头函数的 this 指向哪⾥？

箭头函数不同于传统 JavaScript 中的函数，箭头函数并没有属于⾃⼰的 this，它所谓的 this 是捕捉其所在高低⽂的 this 值，作为⾃⼰的 this 值，并且因为没有属于⾃⼰的 this，所以是不会被 new 调⽤的，这个所谓的 this 也不会被扭转。

能够⽤ Babel 了解⼀下箭头函数:

// ES6 
const obj = {getArrow() {return () => {console.log(this === obj); 
    }; 
  } 
}

转化后：

// ES5，由 Babel 转译
var obj = {getArrow: function getArrow() { 
     var _this = this; 
     return function () {console.log(_this === obj); 
     }; 
   } 
};

代码输入后果

var myObject = {
    foo: "bar",
    func: function() {
        var self = this;
        console.log(this.foo);  
        console.log(self.foo);  
        (function() {console.log(this.foo);  
            console.log(self.foo);  
        }());
    }
};
myObject.func();

输入后果：bar bar undefined bar

解析：

1. 首先 func 是由 myObject 调用的，this 指向 myObject。又因为 var self = this; 所以 self 指向 myObject。
2. 这个立刻执行匿名函数表达式是由 window 调用的，this 指向 window。立刻执行匿名函数的作用域处于 myObject.func 的作用域中，在这个作用域找不到 self 变量，沿着作用域链向上查找 self 变量，找到了指向 myObject 对象的 self。

如何进攻 CSRF 攻打？

CSRF 攻打能够应用以下办法来防护：

• 进行同源检测，服务器依据 http 申请头中 origin 或者 referer 信息来判断申请是否为容许拜访的站点，从而对申请进行过滤。当 origin 或者 referer 信息都不存在的时候，间接阻止申请。这种形式的毛病是有些状况下 referer 能够被伪造，同时还会把搜索引擎的链接也给屏蔽了。所以个别网站会容许搜索引擎的页面申请，然而相应的页面申请这种申请形式也可能被攻击者给利用。（Referer 字段会通知服务器该网页是从哪个页面链接过去的）
• 应用 CSRF Token 进行验证，服务器向用户返回一个随机数 Token，当网站再次发动申请时，在申请参数中退出服务器端返回的 token，而后服务器对这个 token 进行验证。这种办法解决了应用 cookie 繁多验证形式时，可能会被冒用的问题，然而这种办法存在一个毛病就是，咱们须要给网站中的所有申请都增加上这个 token，操作比拟繁琐。还有一个问题是个别不会只有一台网站服务器，如果申请通过负载平衡转移到了其余的服务器，然而这个服务器的 session 中没有保留这个 token 的话，就没有方法验证了。这种状况能够通过扭转 token 的构建形式来解决。
• 对 Cookie 进行双重验证，服务器在用户拜访网站页面时，向申请域名注入一个 Cookie，内容为随机字符串，而后当用户再次向服务器发送申请的时候，从 cookie 中取出这个字符串，增加到 URL 参数中，而后服务器通过对 cookie 中的数据和参数中的数据进行比拟，来进行验证。应用这种形式是利用了攻击者只能利用 cookie，然而不能拜访获取 cookie 的特点。并且这种办法比 CSRF Token 的办法更加不便，并且不波及到分布式拜访的问题。这种办法的毛病是如果网站存在 XSS 破绽的，那么这种形式会生效。同时这种形式不能做到子域名的隔离。
• 在设置 cookie 属性的时候设置 Samesite，限度 cookie 不能作为被第三方应用，从而能够防止被攻击者利用。Samesite 一共有两种模式，一种是严格模式，在严格模式下 cookie 在任何状况下都不可能作为第三方 Cookie 应用，在宽松模式下，cookie 能够被申请是 GET 申请，且会产生页面跳转的申请所应用。

说一下 web worker

在 HTML 页面中，如果在执行脚本时，页面的状态是不可相应的，直到脚本执行实现后，页面才变成可相应。web worker 是运行在后盾的 js，独立于其余脚本，不会影响页面的性能。并且通过 postMessage 将后果回传到主线程。这样在进行简单操作的时候，就不会阻塞主线程了。

如何创立 web worker：

1. 检测浏览器对于 web worker 的支持性
2. 创立 web worker 文件（js，回传函数等）
3. 创立 web worker 对象

Set,Map 解构

ES6 提供了新的数据结构 Set。它相似于数组，然而成员的值都是惟一的，没有反复的值。Set 自身是一个构造函数，用来生成 Set 数据结构。ES6 提供了 Map 数据结构。它相似于对象，也是键值对的汇合，然而“键”的范畴不限于字符串，各种类型的值（包含对象）都能够当作键。

Nginx 的概念及其工作原理

Nginx 是一款轻量级的 Web 服务器，也能够用于反向代理、负载平衡和 HTTP 缓存等。Nginx 应用异步事件驱动的办法来解决申请，是一款面向性能设计的 HTTP 服务器。

传统的 Web 服务器如 Apache 是 process-based 模型的，而 Nginx 是基于 event-driven 模型的。正是这个次要的区别带给了 Nginx 在性能上的劣势。

Nginx 架构的最顶层是一个 master process，这个 master process 用于产生其余的 worker process，这一点和 Apache 十分像，然而 Nginx 的 worker process 能够同时解决大量的 HTTP 申请，而每个 Apache process 只能解决一个。

参考 前端进阶面试题具体解答

什么状况会阻塞渲染？

首先渲染的前提是生成渲染树，所以 HTML 和 CSS 必定会阻塞渲染。如果你想渲染的越快，你越应该升高一开始须要渲染的文件大小，并且扁平层级，优化选择器。而后当浏览器在解析到 script 标签时，会暂停构建 DOM，实现后才会从暂停的中央从新开始。也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 JS 文件，这也是都倡议将 script 标签放在 body 标签底部的起因。

当然在当下，并不是说 script 标签必须放在底部，因为你能够给 script 标签增加 defer 或者 async 属性。当 script 标签加上 defer 属性当前，示意该 JS 文件会并行下载，然而会放到 HTML 解析实现后程序执行，所以对于这种状况你能够把 script 标签放在任意地位。对于没有任何依赖的 JS 文件能够加上 async 属性，示意 JS 文件下载和解析不会阻塞渲染。

常见浏览器所用内核

（1）IE 浏览器内核：Trident 内核，也是俗称的 IE 内核；

（2）Chrome 浏览器内核：统称为 Chromium 内核或 Chrome 内核，以前是 Webkit 内核，当初是 Blink 内核；

（3）Firefox 浏览器内核：Gecko 内核，俗称 Firefox 内核；

（4）Safari 浏览器内核：Webkit 内核；

（5）Opera 浏览器内核：最后是本人的 Presto 内核，起初退出谷歌大军，从 Webkit 又到了 Blink 内核；

（6）360 浏览器、猎豹浏览器内核：IE + Chrome 双内核；

（7）搜狗、漫游、QQ 浏览器内核：Trident（兼容模式）+ Webkit（高速模式）；

（8）百度浏览器、世界之窗内核：IE 内核；

（9）2345 浏览器内核：如同以前是 IE 内核，当初也是 IE + Chrome 双内核了；

（10）UC 浏览器内核：这个众口不一，UC 说是他们本人研发的 U3 内核，但如同还是基于 Webkit 和 Trident，还有说是基于火狐内核。

HTTP 申请报文的是什么样的？

申请报⽂有 4 局部组成:

• 申请⾏
• 申请头部
• 空⾏

• 申请体

  其中：（1）申请⾏包含：申请⽅法字段、URL 字段、HTTP 协定版本字段。它们⽤空格分隔。例如，GET /index.html HTTP/1.1。
  （2）申请头部: 申请头部由关键字 / 值对组成，每⾏⼀对，关键字和值⽤英⽂冒号“:”分隔

• User-Agent：产⽣申请的浏览器类型。
• Accept：客户端可辨认的内容类型列表。
• Host：申请的主机名，容许多个域名同处⼀个 IP 地址，即虚拟主机。

（3）申请体: post put 等申请携带的数据

10 个 Ajax 同时发动申请，全副返回展现后果，并且至少容许三次失败，说出设计思路

这个问题置信很多人会第一工夫想到 Promise.all，然而这个函数有一个局限在于如果失败一次就返回了，间接这样实现会有点问题，须要变通下。以下是两种实现思路

// 以下是不残缺代码，着重于思路 非 Promise 写法
let successCount = 0
let errorCount = 0
let datas = []
ajax(url, (res) => {if (success) {
         success++
         if (success + errorCount === 10) {console.log(datas)
         } else {datas.push(res.data)
         }
     } else {
         errorCount++
         if (errorCount > 3) {
            // 失败次数大于 3 次就应该报错了
             throw Error('失败三次')
         }
     }
})
// Promise 写法
let errorCount = 0
let p = new Promise((resolve, reject) => {if (success) {resolve(res.data)
     } else {
         errorCount++
         if (errorCount > 3) {
            // 失败次数大于 3 次就应该报错了
            reject(error)
         } else {resolve(error)
         }
     }
})
Promise.all([p]).then(v => {console.log(v);
});

DNS 协定是什么

概念：DNS 是域名零碎 (Domain Name System) 的缩写，提供的是一种主机名到 IP 地址的转换服务，就是咱们常说的域名零碎。它是一个由分层的 DNS 服务器组成的分布式数据库，是定义了主机如何查问这个分布式数据库的形式的应用层协定。可能使人更不便的拜访互联网，而不必去记住可能被机器间接读取的 IP 数串。

作用：将域名解析为 IP 地址，客户端向 DNS 服务器（DNS 服务器有本人的 IP 地址）发送域名查问申请，DNS 服务器告知客户机 Web 服务器的 IP 地址。

手写题：数组去重

Array.from(new Set([1, 1, 2, 2]))

CSS 如何阻塞文档解析？

实践上，既然样式表不扭转 DOM 树，也就没有必要停下文档的解析期待它们。然而，存在一个问题，JavaScript 脚本执行时可能在文档的解析过程中申请款式信息，如果款式还没有加载和解析，脚本将失去谬误的值，显然这将会导致很多问题。所以如果浏览器尚未实现 CSSOM 的下载和构建，而咱们却想在此时运行脚本，那么浏览器将提早 JavaScript 脚本执行和文档的解析，直至其实现 CSSOM 的下载和构建。也就是说，在这种状况下，浏览器会先下载和构建 CSSOM，而后再执行 JavaScript，最初再持续文档的解析。

事件循环

• 默认代码从上到下执行，执行环境通过 script 来执行（宏工作）
• 在代码执行过程中，调用定时器 promise click事件 … 不会立刻执行，须要期待以后代码全副执行结束
• 给异步办法划分队列，别离寄存到微工作（立刻寄存）和宏工作（工夫到了或事件产生了才寄存）到队列中
• script执行结束后，会清空所有的微工作
• 微工作执行结束后，会渲染页面（不是每次都调用）
• 再去宏工作队列中看有没有达到工夫的，拿进去其中一个执行
• 执行结束后，依照上述步骤不停的循环

例子

主动执行的状况 会输入 listener1 listener2 task1 task2

如果手动点击 click 会一个宏工作取出来一个个执行，先执行 click 的宏工作，取出微工作去执行。会输入 listener1 task1 listener2 task2

console.log(1)

async function asyncFunc(){console.log(2)
  // await xx ==> promise.resolve(()=>{console.log(3)}).then()
  // console.log(3) 放到 promise.resolve 或立刻执行
  await console.log(3) 
  // 相当于把 console.log(4)放到了 then promise.resolve(()=>{console.log(3)}).then(()=>{//   console.log(4)
  // })
  // 微工作谁先注册谁先执行
  console.log(4)
}

setTimeout(()=>{console.log(5)})

const promise = new Promise((resolve,reject)=>{console.log(6)
  resolve(7)
})

promise.then(d=>{console.log(d)})

asyncFunc()

console.log(8)

// 输入 1 6 2 3 8 7 4 5

1. 浏览器事件循环

涉及面试题：异步代码执行程序？解释一下什么是 Event Loop？

JavaScript 的单线程，与它的用处无关。作为浏览器脚本语言，JavaScript 的主要用途是与用户互动，以及操作 DOM。这决定了它只能是单线程，否则会带来很简单的同步问题。比方，假设 JavaScript 同时有两个线程，一个线程在某个 DOM 节点上增加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？所以，为了防止复杂性，从一诞生，JavaScript 就是单线程，这曾经成了这门语言的外围特色，未来也不会扭转

js 代码执行过程中会有很多工作，这些工作总的分成两类：

• 同步工作
• 异步工作

当咱们关上网站时，网页的渲染过程就是一大堆同步工作，比方页面骨架和页面元素的渲染。而像加载图片音乐之类占用资源大耗时久的工作，就是异步工作。，咱们用导图来阐明：

咱们解释一下这张图：

• 同步和异步工作别离进入不同的执行 ” 场合 ”，同步的进入主线程，异步的进入 Event Table 并注册函数。
• 当指定的事件实现时，Event Table 会将这个函数移入 Event Queue。
• 主线程内的工作执行结束为空，会去 Event Queue 读取对应的函数，进入主线程执行。
• 上述过程会一直反复，也就是常说的 Event Loop(事件循环)。

那主线程执行栈何时为空呢？js 引擎存在 monitoring process 过程，会继续一直的查看主线程执行栈是否为空，一旦为空，就会去 Event Queue 那里查看是否有期待被调用的函数

以上就是 js 运行的整体流程

面试中该如何答复呢？上面是我集体举荐的答复：

• 首先 js 是单线程运行的，在代码执行的时候，通过将不同函数的执行上下文压入执行栈中来保障代码的有序执行
• 在执行同步代码的时候，如果遇到了异步事件，js 引擎并不会始终期待其返回后果，而是会将这个事件挂起，继续执行执行栈中的其余工作
• 当同步事件执行结束后，再将异步事件对应的回调退出到与以后执行栈中不同的另一个工作队列中期待执行
• 工作队列能够分为宏工作对列和微工作对列，当以后执行栈中的事件执行结束后，js 引擎首先会判断微工作对列中是否有工作能够执行，如果有就将微工作队首的事件压入栈中执行
• 当微工作对列中的工作都执行实现后再去判断宏工作对列中的工作。

setTimeout(function() {console.log(1)
}, 0);
new Promise(function(resolve, reject) {console.log(2);
  resolve()}).then(function() {console.log(3)
});
process.nextTick(function () {console.log(4)
})
console.log(5)

• 第一轮：主线程开始执行，遇到 setTimeout，将 setTimeout 的回调函数丢到宏工作队列中，在往下执行new Promise 立刻执行，输入 2，then 的回调函数丢到微工作队列中，再继续执行，遇到 process.nextTick，同样将回调函数扔到微工作队列，再继续执行，输入 5，当所有同步工作执行实现后看有没有能够执行的微工作，发现有 then 函数和nextTick 两个微工作，先执行哪个呢？process.nextTick指定的异步工作总是产生在所有异步工作之前，因而先执行 process.nextTick 输入 4 而后执行 then 函数输入 3，第一轮执行完结。
• 第二轮：从宏工作队列开始，发现 setTimeout 回调，输入 1 执行结束，因而后果是 25431

JS 在执行的过程中会产生执行环境，这些执行环境会被程序的退出到执行栈中。如果遇到异步的代码，会被挂起并退出到 Task（有多种 task）队列中。一旦执行栈为空，Event Loop 就会从 Task 队列中拿出须要执行的代码并放入执行栈中执行，所以实质上来说 JS 中的异步还是同步行为

console.log('script start');

setTimeout(function() {console.log('setTimeout');
}, 0);

console.log('script end');

不同的工作源会被调配到不同的 Task 队列中，工作源能够分为 微工作（microtask）和 宏工作（macrotask）。在 ES6 标准中，microtask 称为 jobs，macrotask 称为 task

console.log('script start');

setTimeout(function() {console.log('setTimeout');
}, 0);

new Promise((resolve) => {console.log('Promise')
    resolve()}).then(function() {console.log('promise1');
}).then(function() {console.log('promise2');
});

console.log('script end');
// script start => Promise => script end => promise1 => promise2 => setTimeout

以上代码尽管 setTimeout 写在 Promise 之前，然而因为 Promise 属于微工作而 setTimeout 属于宏工作

微工作

• process.nextTick
• promise
• Object.observe

• MutationObserver

宏工作

• script
• setTimeout
• setInterval
• setImmediate
• I/O 网络申请实现、文件读写实现事件
• UI rendering
• 用户交互事件（比方鼠标点击、滚动页面、放大放大等）

宏工作中包含了 script，浏览器会先执行一个宏工作，接下来有异步代码的话就先执行微工作

所以正确的一次 Event loop 程序是这样的

• 执行同步代码，这属于宏工作
• 执行栈为空，查问是否有微工作须要执行
• 执行所有微工作
• 必要的话渲染 UI
• 而后开始下一轮 Event loop，执行宏工作中的异步代码

通过上述的 Event loop 程序可知，如果宏工作中的异步代码有大量的计算并且须要操作 DOM 的话，为了更快的响应界面响应，咱们能够把操作 DOM 放入微工作中

• JavaScript 引擎首先从宏工作队列（macrotask queue）中取出第一个工作
• 执行结束后，再将微工作（microtask queue）中的所有工作取出，依照程序别离全副执行（这里包含不仅指开始执行时队列里的微工作），如果在这一步过程中产生新的微工作，也须要执行；
• 而后再从宏工作队列中取下一个，执行结束后，再次将 microtask queue 中的全副取出，周而复始，直到两个 queue 中的工作都取完。

总结起来就是：一次 Eventloop 循环会解决一个宏工作和所有这次循环中产生的微工作。

2. Node 中的 Event loop

当 Node.js 开始启动时，会初始化一个 Eventloop，解决输出的代码脚本，这些脚本会进行 API 异步调用，process.nextTick() 办法会开始处理事件循环。上面就是 Node.js 官网提供的 Eventloop 事件循环参考流程

• Node 中的 Event loop 和浏览器中的不雷同。
• Node 的 Event loop 分为 6 个阶段，它们会依照程序重复运行

• 每次执行执行一个宏工作后会清空微工作（执行程序和浏览器统一，在 node11 版本以上）
• process.nextTick node 中的微工作，以后执行栈的底部，优先级比 promise 要高

整个流程分为六个阶段，当这六个阶段执行完一次之后，才能够算得上执行了一次 Eventloop 的循环过程。咱们来别离看下这六个阶段都做了哪些事件。

• Timers 阶段 ：这个阶段执行 setTimeout 和 setInterval 的回调函数，简略了解就是由这两个函数启动的回调函数。
• I/O callbacks 阶段：这个阶段次要执行零碎级别的回调函数，比方 TCP 连贯失败的回调。
• idle，prepare 阶段：仅零碎外部应用，你只须要晓得有这 2 个阶段就能够。
• poll 阶段 ：poll 阶段是一个重要且简单的阶段，简直所有 I/O 相干的回调，都在这个阶段执行（除了setTimeout、setInterval、setImmediate 以及一些因为 exception 意外敞开产生的回调）。 检索新的 I/O 事件，执行与 I/O 相干的回调，其余状况 Node.js 将在适当的时候在此阻塞。这也是最简单的一个阶段，所有的事件循环以及回调解决都在这个阶段执行。这个阶段的次要流程如下图所示。

• check 阶段：setImmediate() 回调函数在这里执行，setImmediate 并不是立马执行，而是当事件循环 poll 中没有新的事件处理时就执行该局部，如下代码所示。

const fs = require('fs');
setTimeout(() => { // 新的事件循环的终点
    console.log('1'); 
}, 0);
setImmediate(() => {console.log('setImmediate 1');
});
/// fs.readFile 将会在 poll 阶段执行
fs.readFile('./test.conf', {encoding: 'utf-8'}, (err, data) => {if (err) throw err;
    console.log('read file success');
});
/// 该局部将会在首次事件循环中执行
Promise.resolve().then(()=>{console.log('poll callback');
});
// 首次事件循环执行
console.log('2');

在这一代码中有一个十分奇异的中央，就是 setImmediate 会在 setTimeout 之后输入。有以下几点起因：

• setTimeout 如果不设置工夫或者设置工夫为 0，则会默认为 1ms
• 主流程执行实现后，超过 1ms 时，会将 setTimeout 回调函数逻辑插入到待执行回调函数 poll 队列中；
• 因为以后 poll 队列中存在可执行回调函数，因而须要先执行完，待齐全执行实现后，才会执行check：setImmediate。

因而这也验证了这句话，先执行回调函数，再执行 setImmediate

• close callbacks 阶段：执行一些敞开的回调函数，如 socket.on('close', ...)

除了把 Eventloop 的宏工作细分到不同阶段外。node 还引入了一个新的工作队列 Process.nextTick()

能够认为，Process.nextTick() 会在上述各个阶段完结时，在 进入下一个阶段之前立刻执行（优先级甚至超过 microtask 队列）

事件循环的次要蕴含微工作和宏工作。具体是怎么进行循环的呢

• 微工作 ：在 Node.js 中微工作蕴含 2 种——process.nextTick 和 Promise。 微工作在事件循环中优先级是最高的 ，因而在同一个事件循环中有其余工作存在时，优先执行微工作队列。并且process.nextTick 和 Promise 也存在优先级，process.nextTick 高于 Promise
• 宏工作：在 Node.js 中宏工作蕴含 4 种——setTimeout、setInterval、setImmediate 和 I/O。宏工作在微工作执行之后执行，因而在同一个事件循环周期内，如果既存在微工作队列又存在宏工作队列，那么优先将微工作队列清空，再执行宏工作队列

咱们能够看到有一个外围的主线程，它的执行阶段次要解决三个外围逻辑。

• 同步代码。
• 将异步工作插入到微工作队列或者宏工作队列中。
• 执行微工作或者宏工作的回调函数。在主线程解决回调函数的同时，也须要判断是否插入微工作和宏工作。依据优先级，先判断微工作队列是否存在工作，存在则先执行微工作，不存在则判断在宏工作队列是否有工作，有则执行。

const fs = require('fs');
// 首次事件循环执行
console.log('start');
/// 将会在新的事件循环中的阶段执行
fs.readFile('./test.conf', {encoding: 'utf-8'}, (err, data) => {if (err) throw err;
    console.log('read file success');
});
setTimeout(() => { // 新的事件循环的终点
    console.log('setTimeout'); 
}, 0);
/// 该局部将会在首次事件循环中执行
Promise.resolve().then(()=>{console.log('Promise callback');
});
/// 执行 process.nextTick
process.nextTick(() => {console.log('nextTick callback');
});
// 首次事件循环执行
console.log('end');

剖析下下面代码的执行过程

• 第一个事件循环主线程发动，因而先执行同步代码，所以先输入 start，而后输入 end
• 第一个事件循环主线程发动，因而先执行同步代码，所以先输入 start，而后输入 end；
• 再从上往下剖析，遇到微工作，插入微工作队列，遇到宏工作，插入宏工作队列，剖析实现后，微工作队列蕴含：Promise.resolve 和 process.nextTick，宏工作队列蕴含：fs.readFile 和 setTimeout；
• 先执行微工作队列，然而依据优先级，先执行 process.nextTick 再执行 Promise.resolve，所以先输入 nextTick callback 再输入 Promise callback；
• 再执行宏工作队列，依据 宏工作插入先后顺序执行 setTimeout 再执行 fs.readFile，这里须要留神，先执行 setTimeout 因为其回调工夫较短，因而回调也先执行，并非是 setTimeout 先执行所以才先执行回调函数，然而它执行须要工夫必定大于 1ms，所以尽管 fs.readFile 先于setTimeout 执行，然而 setTimeout 执行更快，所以先输入 setTimeout，最初输入 read file success。

// 输入后果
start
end
nextTick callback
Promise callback
setTimeout
read file success

当微工作和宏工作又产生新的微工作和宏工作时，又应该如何解决呢？如下代码所示：

const fs = require('fs');
setTimeout(() => { // 新的事件循环的终点
    console.log('1'); 
    fs.readFile('./config/test.conf', {encoding: 'utf-8'}, (err, data) => {if (err) throw err;
        console.log('read file sync success');
    });
}, 0);
/// 回调将会在新的事件循环之前
fs.readFile('./config/test.conf', {encoding: 'utf-8'}, (err, data) => {if (err) throw err;
    console.log('read file success');
});
/// 该局部将会在首次事件循环中执行
Promise.resolve().then(()=>{console.log('poll callback');
});
// 首次事件循环执行
console.log('2');

在下面代码中，有 2 个宏工作和 1 个微工作，宏工作是 setTimeout 和 fs.readFile，微工作是 Promise.resolve。

• 整个过程优先执行主线程的第一个事件循环过程，所以先执行同步逻辑，先输入 2。
• 接下来执行微工作，输入 poll callback。
• 再执行宏工作中的 fs.readFile 和 setTimeout，因为 fs.readFile 优先级高，先执行 fs.readFile。然而解决工夫长于 1ms，因而会先执行 setTimeout 的回调函数，输入 1。这个阶段在执行过程中又会产生新的宏工作 fs.readFile，因而又将该 fs.readFile 插入宏工作队列
• 最初因为只剩下宏工作了 fs.readFile，因而执行该宏工作，并期待解决实现后的回调，输入 read file sync success。

// 后果
2
poll callback
1
read file success
read file sync success

Process.nextick() 和 Vue 的 nextick

Node.js 和浏览器端宏工作队列的另一个很重要的不同点是，浏览器端工作队列每轮事件循环仅出队一个回调函数接着去执行微工作队列；而 Node.js 端只有轮到执行某个宏工作队列，则会执行完队列中所有的当前任务，然而以后轮次新增加到队尾的工作则会等到下一轮次才会执行。

setTimeout(() => {console.log('setTimeout');
}, 0);
setImmediate(() => {console.log('setImmediate');
})
// 这里可能会输入 setTimeout，setImmediate
// 可能也会相同的输入，这取决于性能
// 因为可能进入 event loop 用了不到 1 毫秒，这时候会执行 setImmediate
// 否则会执行 setTimeout

下面介绍的都是 macrotask 的执行状况，microtask 会在以上每个阶段实现后立刻执行

setTimeout(()=>{console.log('timer1')

    Promise.resolve().then(function() {console.log('promise1')
    })
}, 0)

setTimeout(()=>{console.log('timer2')

    Promise.resolve().then(function() {console.log('promise2')
    })
}, 0)

// 以上代码在浏览器和 node 中打印状况是不同的
// 浏览器中肯定打印 timer1, promise1, timer2, promise2
// node 中可能打印 timer1, timer2, promise1, promise2
// 也可能打印 timer1, promise1, timer2, promise2

Node 中的 process.nextTick 会先于其余 microtask 执行

setTimeout(() => {console.log("timer1");

 Promise.resolve().then(function() {console.log("promise1");
 });
}, 0);

// poll 阶段执行
fs.readFile('./test',()=>{
  // 在 poll 阶段外面 如果有 setImmediate 优先执行，setTimeout 处于事件循环顶端 poll 上面就是 setImmediate
  setTimeout(()=>console.log('setTimeout'),0)
  setImmediate(()=>console.log('setImmediate'),0)
})

process.nextTick(() => {console.log("nextTick");
});
// nextTick, timer1, promise1,setImmediate,setTimeout

对于 microtask 来说，它会在以上每个阶段实现前清空 microtask 队列，下图中的 Tick 就代表了 microtask

谁来启动这个循环过程，循环条件是什么？

当 Node.js 启动后，会初始化事件循环，解决已提供的输出脚本，它可能会先调用一些异步的 API、调度定时器，或者 process.nextTick()，而后再开始处理事件循环。因而能够这样了解，Node.js 过程启动后，就发动了一个新的事件循环，也就是事件循环的终点。

总结来说，Node.js 事件循环的发动点有 4 个：

• Node.js 启动后；
• setTimeout 回调函数；
• setInterval 回调函数；
• 也可能是一次 I/O 后的回调函数。

有限循环有没有起点

当所有的微工作和宏工作都清空的时候，尽管以后没有工作可执行了，然而也并不能代表循环完结了。因为可能存在以后还未回调的异步 I/O，所以这个循环是没有起点的，只有过程在，并且有新的工作存在，就会去执行

Node.js 是单线程的还是多线程的？

主线程是单线程执行的 ，然而 Node.js 存在多线程执行 ，多线程包含 setTimeout 和异步 I/O 事件。其实 Node.js 还存在其余的线程，包含 垃圾回收、内存优化 等

EventLoop 对渲染的影响

• 想必你之前在业务开发中也遇到过 requestIdlecallback 和 requestAnimationFrame，这两个函数在咱们之前的内容中没有讲过，然而当你开始思考它们在 Eventloop 的生命周期的哪一步触发，或者这两个办法的回调会在微工作队列还是宏工作队列执行的时候，才发现如同没有设想中那么简略。这两个办法其实也并不属于 JS 的原生办法，而是浏览器宿主环境提供的办法，因为它们牵扯到另一个问题：渲染。
• 咱们晓得浏览器作为一个简单的利用是多线程工作的，除了运行 JS 的线程外，还有渲染线程、定时器触发线程、HTTP 申请线程，等等。JS 线程能够读取并且批改 DOM，而渲染线程也须要读取 DOM，这是一个典型的多线程竞争临界资源的问题。所以浏览器就把这两个线程设计成互斥的，即同时只能有一个线程在执行
• 渲染本来就不应该呈现在 Eventloop 相干的常识体系里，然而因为 Eventloop 显然是在探讨 JS 如何运行的问题，而渲染则是浏览器另外一个线程的工作。然而 requestAnimationFrame的呈现却把这两件事件给关联起来

• 通过调用 requestAnimationFrame 咱们能够在下次渲染之前执行回调函数。那下次渲染具体是哪个工夫点呢？渲染和 Eventloop 有什么关系呢？

  • 简略来说，就是在每一次 Eventloop 的开端，判断以后页面是否处于渲染机会，就是从新渲染
• 有屏幕的硬件限度，比方 60Hz 刷新率，简而言之就是 1 秒刷新了 60 次，16.6ms 刷新一次。这个时候浏览器的渲染间隔时间就没必要小于 16.6ms，因为就算渲染了屏幕上也看不到。当然浏览器也不能保障肯定会每 16.6ms 会渲染一次，因为还会受到处理器的性能、JavaScript 执行效率等其余因素影响。
• 回到 requestAnimationFrame，这个 API 保障在下次浏览器渲染之前肯定会被调用，实际上咱们齐全能够把它看成是一个高级版的 setInterval。它们都是在一段时间后执行回调，然而前者的间隔时间是由浏览器本人一直调整的，而后者只能由用户指定。这样的个性也决定了 requestAnimationFrame 更适宜用来做针对每一帧来批改的动画成果
• 当然 requestAnimationFrame 不是 Eventloop 里的宏工作，或者说它并不在 Eventloop 的生命周期里，只是浏览器又凋谢的一个在渲染之前产生的新的 hook。另外须要留神的是微工作的认知概念也须要更新，在执行 animation callback 时也有可能产生微工作（比方 promise 的 callback），会放到 animation queue 解决完后再执行。所以微工作并不是像之前说的那样在每一轮 Eventloop 后处理，而是在 JS 的函数调用栈清空后处理

然而 requestIdlecallback 却是一个更好了解的概念。当宏工作队列中没有工作能够解决时，浏览器可能存在“闲暇状态”。这段闲暇工夫能够被 requestIdlecallback 利用起来执行一些优先级不高、不用立刻执行的工作，如下图所示：

display 的 block、inline 和 inline-block 的区别

（1）block： 会独占一行，多个元素会另起一行，能够设置 width、height、margin 和 padding 属性；

（2）inline： 元素不会独占一行，设置 width、height 属性有效。但能够设置程度方向的 margin 和 padding 属性，不能设置垂直方向的 padding 和 margin；

（3）inline-block： 将对象设置为 inline 对象，但对象的内容作为 block 对象出现，之后的内联对象会被排列在同一行内。

对于行内元素和块级元素，其特点如下：

（1）行内元素

• 设置宽高有效；
• 能够设置程度方向的 margin 和 padding 属性，不能设置垂直方向的 padding 和 margin；
• 不会主动换行；

（2）块级元素

• 能够设置宽高；
• 设置 margin 和 padding 都无效；
• 能够主动换行；
• 多个块状，默认排列从上到下。

什么是同源策略

跨域问题其实就是浏览器的同源策略造成的。

同源策略限度了从同一个源加载的文档或脚本如何与另一个源的资源进行交互。这是浏览器的一个用于隔离潜在歹意文件的重要的平安机制。同源指的是：协定 、 端口号 、 域名 必须统一。

同源策略：protocol（协定）、domain（域名）、port（端口）三者必须统一。

同源政策次要限度了三个方面：

• 以后域下的 js 脚本不可能拜访其余域下的 cookie、localStorage 和 indexDB。
• 以后域下的 js 脚本不可能操作拜访操作其余域下的 DOM。
• 以后域下 ajax 无奈发送跨域申请。

同源政策的目标次要是为了保障用户的信息安全，它只是对 js 脚本的一种限度，并不是对浏览器的限度，对于个别的 img、或者 script 脚本申请都不会有跨域的限度，这是因为这些操作都不会通过响应后果来进行可能呈现平安问题的操作。

模块化

js 中当初比拟成熟的有四种模块加载计划：

• 第一种是 CommonJS 计划，它通过 require 来引入模块，通过 module.exports 定义模块的输入接口。这种模块加载计划是服务器端的解决方案，它是以同步的形式来引入模块的，因为在服务端文件都存储在本地磁盘，所以读取十分快，所以以同步的形式加载没有问题。但如果是在浏览器端，因为模块的加载是应用网络申请，因而应用异步加载的形式更加适合。
• 第二种是 AMD 计划，这种计划采纳异步加载的形式来加载模块，模块的加载不影响前面语句的执行，所有依赖这个模块的语句都定义在一个回调函数里，等到加载实现后再执行回调函数。require.js 实现了 AMD 标准
• 第三种是 CMD 计划，这种计划和 AMD 计划都是为了解决异步模块加载的问题，sea.js 实现了 CMD 标准。它和 require.js 的区别在于模块定义时对依赖的解决不同和对依赖模块的执行机会的解决不同。
• 第四种计划是 ES6 提出的计划，应用 import 和 export 的模式来导入导出模块

在有 Babel 的状况下，咱们能够间接应用 ES6的模块化

// file a.js
export function a() {}
export function b() {}
// file b.js
export default function() {}

import {a, b} from './a.js'
import XXX from './b.js'

CommonJS

CommonJs 是 Node 独有的标准，浏览器中应用就须要用到 Browserify解析了。

// a.js
module.exports = {a: 1}
// or
exports.a = 1

// b.js
var module = require('./a.js')
module.a // -> log 1

在上述代码中，module.exports 和 exports 很容易混同，让咱们来看看大抵外部实现

var module = require('./a.js')
module.a
// 这里其实就是包装了一层立刻执行函数，这样就不会净化全局变量了，// 重要的是 module 这里，module 是 Node 独有的一个变量
module.exports = {a: 1}
// 根本实现
var module = {exports: {} // exports 就是个空对象
}
// 这个是为什么 exports 和 module.exports 用法类似的起因
var exports = module.exports
var load = function (module) {
    // 导出的货色
    var a = 1
    module.exports = a
    return module.exports
};

再来说说 module.exports 和exports，用法其实是类似的，然而不能对 exports 间接赋值，不会有任何成果。

对于 CommonJS 和 ES6 中的模块化的两者区别是：

• 前者反对动静导入，也就是 require(${path}/xx.js)，后者目前不反对，然而已有提案, 前者是同步导入，因为用于服务端，文件都在本地，同步导入即便卡住主线程影响也不大。
• 而后者是异步导入，因为用于浏览器，须要下载文件，如果也采纳同步导入会对渲染有很大影响
• 前者在导出时都是值拷贝，就算导出的值变了，导入的值也不会扭转，所以如果想更新值，必须从新导入一次。
• 然而后者采纳实时绑定的形式，导入导出的值都指向同一个内存地址，所以导入值会追随导出值变动
• 后者会编译成 require/exports 来执行的

AMD

AMD 是由 RequireJS 提出的

AMD 和 CMD 标准的区别？

• 第一个方面是在模块定义时对依赖的解决不同。AMD 推崇依赖前置，在定义模块的时候就要申明其依赖的模块。而 CMD 推崇就近依赖，只有在用到某个模块的时候再去 require。
• 第二个方面是对依赖模块的执行机会解决不同。首先 AMD 和 CMD 对于模块的加载形式都是异步加载，不过它们的区别在于模块的执行机会，AMD 在依赖模块加载实现后就间接执行依赖模块，依赖模块的执行程序和咱们书写的程序不肯定统一。而 CMD 在依赖模块加载实现后并不执行，只是下载而已，等到所有的依赖模块都加载好后，进入回调函数逻辑，遇到 require 语句的时候才执行对应的模块，这样模块的执行程序就和咱们书写的程序保持一致了。

// CMD
define(function(require, exports, module) {var a = require("./a");
  a.doSomething();
  // 此处略去 100 行
  var b = require("./b"); // 依赖能够就近书写
  b.doSomething();
  // ...
});

// AMD 默认举荐
define(["./a", "./b"], function(a, b) {
  // 依赖必须一开始就写好
  a.doSomething();
  // 此处略去 100 行
  b.doSomething();
  // ...
})

• AMD：requirejs 在推广过程中对模块定义的规范化产出，提前执行，推崇依赖前置
• CMD：seajs 在推广过程中对模块定义的规范化产出，提早执行，推崇依赖就近
• CommonJs：模块输入的是一个值的 copy，运行时加载，加载的是一个对象（module.exports 属性），该对象只有在脚本运行完才会生成
• ES6 Module：模块输入的是一个值的援用，编译时输入接口，ES6模块不是对象，它对外接口只是一种动态定义，在代码动态解析阶段就会生成。

谈谈对模块化开发的了解

• 我对模块的了解是，一个模块是实现一个特定性能的一组办法。在最开始的时候，js 只实现一些简略的性能，所以并没有模块的概念，但随着程序越来越简单，代码的模块化开发变得越来越重要。
• 因为函数具备独立作用域的特点，最原始的写法是应用函数来作为模块，几个函数作为一个模块，然而这种形式容易造成全局变量的净化，并且模块间没有分割。
• 前面提出了对象写法，通过将函数作为一个对象的办法来实现，这样解决了间接应用函数作为模块的一些毛病，然而这种方法会裸露所有的所有的模块成员，内部代码能够批改外部属性的值。
• 当初最罕用的是立刻执行函数的写法，通过利用闭包来实现模块公有作用域的建设，同时不会对全局作用域造成净化。

介绍下 promise 的个性、优缺点，外部是如何实现的，入手实现 Promise

1）Promise 根本个性

• 1、Promise 有三种状态：pending(进行中)、fulfilled(已胜利)、rejected(已失败)
• 2、Promise 对象承受一个回调函数作为参数, 该回调函数承受两个参数，别离是胜利时的回调 resolve 和失败时的回调 reject；另外 resolve 的参数除了正常值以外，还可能是一个 Promise 对象的实例；reject 的参数通常是一个 Error 对象的实例。
• 3、then 办法返回一个新的 Promise 实例，并接管两个参数 onResolved(fulfilled 状态的回调)；onRejected(rejected 状态的回调，该参数可选)
• 4、catch 办法返回一个新的 Promise 实例
• 5、finally 办法不论 Promise 状态如何都会执行，该办法的回调函数不承受任何参数
• 6、Promise.all()办法将多个多个 Promise 实例，包装成一个新的 Promise 实例，该办法承受一个由 Promise 对象组成的数组作为参数 (Promise.all() 办法的参数能够不是数组，但必须具备 Iterator 接口，且返回的每个成员都是 Promise 实例)，留神参数中只有有一个实例触发 catch 办法，都会触发 Promise.all()办法返回的新的实例的 catch 办法，如果参数中的某个实例自身调用了 catch 办法，将不会触发 Promise.all()办法返回的新实例的 catch 办法
• 7、Promise.race()办法的参数与 Promise.all 办法一样，参数中的实例只有有一个率先扭转状态就会将该实例的状态传给 Promise.race()办法，并将返回值作为 Promise.race()办法产生的 Promise 实例的返回值
• 8、Promise.resolve()将现有对象转为 Promise 对象，如果该办法的参数为一个 Promise 对象，Promise.resolve()将不做任何解决；如果参数 thenable 对象 (即具备 then 办法)，Promise.resolve() 将该对象转为 Promise 对象并立刻执行 then 办法；如果参数是一个原始值，或者是一个不具备 then 办法的对象，则 Promise.resolve 办法返回一个新的 Promise 对象，状态为 fulfilled，其参数将会作为 then 办法中 onResolved 回调函数的参数，如果 Promise.resolve 办法不带参数，会间接返回一个 fulfilled 状态的 Promise 对象。须要留神的是，立刻 resolve()的 Promise 对象，是在本轮“事件循环”（event loop）的完结时执行，而不是在下一轮“事件循环”的开始时。
• 9、Promise.reject()同样返回一个新的 Promise 对象，状态为 rejected，无论传入任何参数都将作为 reject()的参数

2）Promise 长处

• ①对立异步 API

  • Promise 的一个重要长处是它将逐步被用作浏览器的异步 API，对立当初各种各样的 API，以及不兼容的模式和手法。

• ②Promise 与事件比照

  • 和事件相比拟，Promise 更适宜解决一次性的后果。在后果计算出来之前或之后注册回调函数都是能够的，都能够拿到正确的值。Promise 的这个长处很天然。然而，不能应用 Promise 解决屡次触发的事件。链式解决是 Promise 的又一长处，然而事件却不能这样链式解决。

• ③Promise 与回调比照

  • 解决了回调天堂的问题，将异步操作以同步操作的流程表达出来。
• ④Promise 带来的额定益处是蕴含了更好的错误处理形式（蕴含了异样解决），并且写起来很轻松（因为能够重用一些同步的工具，比方 Array.prototype.map()）。

3）Promise 毛病

• 1、无奈勾销 Promise，一旦新建它就会立刻执行，无奈中途勾销。
• 2、如果不设置回调函数，Promise 外部抛出的谬误，不会反馈到内部。
• 3、当处于 Pending 状态时，无奈得悉目前停顿到哪一个阶段（刚刚开始还是行将实现）。
• 4、Promise 真正执行回调的时候，定义 Promise 那局部实际上曾经走完了，所以 Promise 的报错堆栈上下文不太敌对。

4）简略代码实现
最简略的 Promise 实现有 7 个次要属性, state(状态), value(胜利返回值), reason(错误信息), resolve 办法, reject 办法, then 办法

class Promise{constructor(executor) {
    this.state = 'pending';
    this.value = undefined;
    this.reason = undefined;
    let resolve = value => {if (this.state === 'pending') {
        this.state = 'fulfilled';
        this.value = value;
      }
    };
    let reject = reason => {if (this.state === 'pending') {
        this.state = 'rejected';
        this.reason = reason;
      }
    };
    try {
      // 立刻执行函数
      executor(resolve, reject);
    } catch (err) {reject(err);
    }
  }
  then(onFulfilled, onRejected) {if (this.state === 'fulfilled') {let x = onFulfilled(this.value);
    };
    if (this.state === 'rejected') {let x = onRejected(this.reason);
    };
  }
}

5）面试够用版

function myPromise(constructor){ let self=this;
  self.status="pending" // 定义状态扭转前的初始状态 
  self.value=undefined;// 定义状态为 resolved 的时候的状态 
  self.reason=undefined;// 定义状态为 rejected 的时候的状态 
  function resolve(value){
    // 两个 ==="pending"，保障了了状态的扭转是不不可逆的 
    if(self.status==="pending"){
      self.value=value;
      self.status="resolved"; 
    }
  }
  function reject(reason){
     // 两个 ==="pending"，保障了了状态的扭转是不不可逆的
     if(self.status==="pending"){
        self.reason=reason;
        self.status="rejected"; 
      }
  }
  // 捕捉结构异样 
  try{constructor(resolve,reject);
  }catch(e){reject(e);
    } 
}
myPromise.prototype.then=function(onFullfilled,onRejected){ 
  let self=this;
  switch(self.status){case "resolved": onFullfilled(self.value); break;
    case "rejected": onRejected(self.reason); break;
    default: 
  }
}

// 测试
var p=new myPromise(function(resolve,reject){resolve(1)}); 
p.then(function(x){console.log(x)})
// 输入 1 

6）大厂专供版

const PENDING = "pending"; 
const FULFILLED = "fulfilled"; 
const REJECTED = "rejected";
const resolvePromise = (promise, x, resolve, reject) => {if (x === promise) {
    // If promise and x refer to the same object, reject promise with a TypeError as the reason.
    reject(new TypeError('循环援用'))
  }
  // if x is an object or function,
  if (x !== null && typeof x === 'object' || typeof x === 'function') {
    // If both resolvePromise and rejectPromise are called, or multiple calls to the same argument are made, the first call takes precedence, and any further calls are ignored.
    let called
    try { // If retrieving the property x.then results in a thrown exception e, reject promise with e as the reason.
      let then = x.then // Let then be x.then
      // If then is a function, call it with x as this
      if (typeof then === 'function') {// If/when resolvePromise is called with a value y, run [[Resolve]](promise, y)
        // If/when rejectPromise is called with a reason r, reject promise with r.
        then.call(x, y => {if (called) return
          called = true
          resolvePromise(promise, y, resolve, reject)
        }, r => {if (called) return
          called = true
          reject(r)
        })
      } else {
        // If then is not a function, fulfill promise with x.
        resolve(x)
      }
    } catch (e) {if (called) return
      called = true
      reject(e)
    }
  } else {
    // If x is not an object or function, fulfill promise with x
    resolve(x)
  }
}
function Promise(excutor) {
  let that = this; // 缓存以后 promise 实例例对象
  that.status = PENDING; // 初始状态
  that.value = undefined; // fulfilled 状态时 返回的信息
  that.reason = undefined; // rejected 状态时 回绝的起因 
  that.onFulfilledCallbacks = []; // 存储 fulfilled 状态对应的 onFulfilled 函数
  that.onRejectedCallbacks = []; // 存储 rejected 状态对应的 onRejected 函数
  function resolve(value) { // value 胜利态时接管的终值
    if(value instanceof Promise) {return value.then(resolve, reject);
    }
    // 实际中要确保 onFulfilled 和 onRejected ⽅办法异步执⾏行行，且应该在 then ⽅办法被调⽤用的那⼀一轮事件循环之后的新执⾏行行栈中执⾏行行。setTimeout(() => {
      // 调⽤用 resolve 回调对应 onFulfilled 函数
      if (that.status === PENDING) {// 只能由 pending 状态 => fulfilled 状态 (防止调⽤用屡次 resolve reject)
        that.status = FULFILLED;
        that.value = value;
        that.onFulfilledCallbacks.forEach(cb => cb(that.value));
      }
    });
  }
  function reject(reason) { // reason 失败态时接管的拒因
    setTimeout(() => {
      // 调⽤用 reject 回调对应 onRejected 函数
      if (that.status === PENDING) {// 只能由 pending 状态 => rejected 状态 (防止调⽤用屡次 resolve reject)
        that.status = REJECTED;
        that.reason = reason;
        that.onRejectedCallbacks.forEach(cb => cb(that.reason));
      }
    });
  }

  // 捕捉在 excutor 执⾏行行器器中抛出的异样
  // new Promise((resolve, reject) => {//     throw new Error('error in excutor')
  // })
  try {excutor(resolve, reject);
  } catch (e) {reject(e);
  }
}
Promise.prototype.then = function(onFulfilled, onRejected) {
  const that = this;
  let newPromise;
  // 解决理参数默认值 保障参数后续可能持续执⾏行行
  onFulfilled = typeof onFulfilled === "function" ? onFulfilled : value => value;
  onRejected = typeof onRejected === "function" ? onRejected : reason => {throw reason;};
  if (that.status === FULFILLED) { // 胜利态
    return newPromise = new Promise((resolve, reject) => {setTimeout(() => {
        try{let x = onFulfilled(that.value);
          resolvePromise(newPromise, x, resolve, reject); // 新的 promise resolve 上⼀一个 onFulfilled 的返回值
        } catch(e) {reject(e); // 捕捉前⾯面 onFulfilled 中抛出的异样 then(onFulfilled, onRejected);
        }
      });
    })
  }
  if (that.status === REJECTED) { // 失败态
    return newPromise = new Promise((resolve, reject) => {setTimeout(() => {
        try {let x = onRejected(that.reason);
          resolvePromise(newPromise, x, resolve, reject);
        } catch(e) {reject(e);
        }
      });
    });
  }
  if (that.status === PENDING) { // 期待态
// 当异步调⽤用 resolve/rejected 时 将 onFulfilled/onRejected 收集暂存到汇合中
    return newPromise = new Promise((resolve, reject) => {that.onFulfilledCallbacks.push((value) => {
        try {let x = onFulfilled(value);
          resolvePromise(newPromise, x, resolve, reject);
        } catch(e) {reject(e);
        }
      });
      that.onRejectedCallbacks.push((reason) => {
        try {let x = onRejected(reason);
          resolvePromise(newPromise, x, resolve, reject);
        } catch(e) {reject(e);
        }
      });
    });
  }
};

组件的协同及（不）可控组件

为什么要进行组件的协同

• 咱们在理论的开发我的项目的时候，不会只用几个组件，有时候遇到大型的我的项目，可能会有成千上百的组件，难免会遇到有性能反复的组件。要进行批改，就会批改大部分的文件。所以咱们须要进行组件的协同开发。

什么是组件的协同应用？

• 组件的协同实质上是对组件的一种组织、治理的形式。

• 目标：

  • 逻辑清晰：这是组件与组件之间的逻辑
  • 代码模块化
  • 封装细节：像面向对象一样将罕用的办法以及数据封装起来
  • 进步代码的复用性：因为是组件，相当于一个封装好的货色，用的时候间接调用

如何实现组件的协同应用

• 第一种：减少一个父组件，将其余的组件进行嵌套，更多的是实现代码的封装
• 第二种：通过一些操作从后盾获取数据，React中的Mixin，更多的是实现代码的复用

组件嵌套的含意

• 组件嵌套的实质是父子关系

组件嵌套的优缺点

• 长处：

  • 逻辑清晰：父子关系相似于人类中的父子关系
  • 模块化开发：每个模块对应一个性能，不同的模块能够同步开发
  • 封装细节：开发者必须要关注组件的性能，不须要理解细节

• 毛病：

  • 编写难度高：父子组件的关系须要通过三思而行，贸然编写可能导致关系凌乱，代码难以保护
  • 无奈把握所有细节：使用者只晓得组件的用法，不晓得实现细节，遇到问题难以修复

Mixin

Mixin 的含意

• Mixin= 一组办法。
• 他的目标是横向抽离出组件的类似代码，把组件的独特作用以及成果的代码提出来

Mixin 的优缺点

• 长处

  • 代码复用：抽离出通用的代码，缩小开发成本，进步开发效率
  • 即插即用：能够应用许多现有的 Mixin 来开发本人的代码
  • 适应性强：改变一次代码，影响多个组件

• 毛病

  • 编写难度高：Mixin可能被用在各种环境中，想要兼容多种环境就须要更多的 – 码与逻辑，通用的代价是进步复杂度
  • 升高代码的可读性：组件的劣势在于将逻辑与是界面间接联合在一起，Mixin实质上会扩散逻辑，了解起来难度大

不可控组件

• 上图：defaultValue的值是固定的，这就是一个不可控组件
• 如果要获取 input 的value值，只有应用 ref 获取节点来获取值

可控组件

• defaultValue的值是依据状态确定了，只须要拿到 this.state.value 的值就能够了
• 这里须要留神一下：应用 value 的值是不可批改的，defaultValue的值是能够批改的

可控组件的长处

• 合乎 React 的数据流
• 数据存储在 state 中，便于获取
• 便于解决数据

函数柯里化

什么叫函数柯里化？其实就是将应用多个参数的函数转换成一系列应用一个参数的函数的技术。还不懂？来举个例子。

function add(a, b, c) {return a + b + c}
add(1, 2, 3)
let addCurry = curry(add)
addCurry(1)(2)(3)

当初就是要实现 curry 这个函数，使函数从一次调用传入多个参数变成屡次调用每次传一个参数。

function curry(fn) {let judge = (...args) => {if (args.length == fn.length) return fn(...args)
        return (...arg) => judge(...args, ...arg)
    }
    return judge
}