将虚构 Dom 转化为实在 Dom

题目形容:JSON 格局的虚构 Dom 怎么转换成实在 Dom

{  tag: 'DIV',  attrs:{  id:'app'  },  children: [    {      tag: 'SPAN',      children: [        { tag: 'A', children: [] }      ]    },    {      tag: 'SPAN',      children: [        { tag: 'A', children: [] },        { tag: 'A', children: [] }      ]    }  ]}把上诉虚构Dom转化成下方实在Dom<div id="app">  <span>    <a></a>  </span>  <span>    <a></a>    <a></a>  </span></div>

实现代码如下:

// 真正的渲染函数function _render(vnode) {  // 如果是数字类型转化为字符串  if (typeof vnode === "number") {    vnode = String(vnode);  }  // 字符串类型间接就是文本节点  if (typeof vnode === "string") {    return document.createTextNode(vnode);  }  // 一般DOM  const dom = document.createElement(vnode.tag);  if (vnode.attrs) {    // 遍历属性    Object.keys(vnode.attrs).forEach((key) => {      const value = vnode.attrs[key];      dom.setAttribute(key, value);    });  }  // 子数组进行递归操作  vnode.children.forEach((child) => dom.appendChild(_render(child)));  return dom;}

说说Vue2.0和Vue3.0有什么区别

  • 重构响应式零碎，应用Proxy替换Object.defineProperty，应用Proxy劣势：

    • 可间接监听数组类型的数据变动
    • 监听的指标为对象自身，不须要像Object.defineProperty一样遍历每个属性，有肯定的性能晋升
    • 可拦挡apply、ownKeys、has等13种办法，而Object.defineProperty不行
    • 间接实现对象属性的新增/删除
  • 新增Composition API，更好的逻辑复用和代码组织

  • 重构 Virtual DOM

    • 模板编译时的优化，将一些动态节点编译成常量
    • slot优化，将slot编译为lazy函数，将slot的渲染的决定权交给子组件
    • 模板中内联事件的提取并重用（本来每次渲染都从新生成内联函数）
  • 代码结构调整，更便于Tree shaking，使得体积更小
  • 应用Typescript替换Flow

9种前端常见的设计模式

1. 外观模式

外观模式是最常见的设计模式之一，它为子系统中的一组接口提供一个对立的高层接口，使子系统更容易应用。简而言之外观设计模式就是把多个子系统中简单逻辑进行形象，从而提供一个更对立、更简洁、更易用的API。很多咱们罕用的框架和库根本都遵循了外观设计模式，比方JQuery就把简单的原生DOM操作进行了形象和封装，并打消了浏览器之间的兼容问题，从而提供了一个更高级更易用的版本。其实在平时工作中咱们也会常常用到外观模式进行开发，只是咱们不自知而已

兼容浏览器事件绑定

let addMyEvent = function (el, ev, fn) {    if (el.addEventListener) {        el.addEventListener(ev, fn, false)    } else if (el.attachEvent) {        el.attachEvent('on' + ev, fn)    } else {        el['on' + ev] = fn    }};

封装接口

let myEvent = {    // ...    stop: e => {        e.stopPropagation();        e.preventDefault();    }};

场景

  • 设计初期，应该要无意识地将不同的两个层拆散，比方经典的三层构造，在数据拜访层和业务逻辑层、业务逻辑层和表示层之间建设外观Facade
  • 在开发阶段，子系统往往因为一直的重构演变而变得越来越简单，减少外观Facade能够提供一个简略的接口，缩小他们之间的依赖。
  • 在保护一个遗留的大型零碎时，可能这个零碎曾经很难保护了，这时候应用外观Facade也是十分适合的，为系零碎开发一个外观Facade类，为设计毛糙和高度简单的遗留代码提供比拟清晰的接口，让新零碎和Facade对象交互，Facade与遗留代码交互所有的简单工作。

长处

  • 缩小零碎相互依赖。
  • 进步灵活性。
  • 进步了安全性

毛病

不合乎开闭准则，如果要改货色很麻烦，继承重写都不适合。

2. 代理模式

是为一个对象提供一个代用品或占位符，以便管制对它的拜访

假如当A 在情绪好的时候收到花，小明表白胜利的几率有60%，而当A 在情绪差的时候收到花，小明表白的成功率有限趋近于0。小明跟A 刚刚意识两天，还无奈分别A 什么时候情绪好。如果不合时宜地把花送给A，花被间接扔掉的可能性很大，这束花可是小明吃了7 天泡面换来的。然而A 的敌人B 却很理解A，所以小明只管把花交给B，B 会监听A 的情绪变动，而后抉择A 情绪好的时候把花转交给A，代码如下：

let Flower = function() {}let xiaoming = {  sendFlower: function(target) {    let flower = new Flower()    target.receiveFlower(flower)  }}let B = {  receiveFlower: function(flower) {    A.listenGoodMood(function() {      A.receiveFlower(flower)    })  }}let A = {  receiveFlower: function(flower) {    console.log('收到花'+ flower)  },  listenGoodMood: function(fn) {    setTimeout(function() {      fn()    }, 1000)  }}xiaoming.sendFlower(B)

场景

HTML元 素事件代理

<ul id="ul">  <li>1</li>  <li>2</li>  <li>3</li></ul><script>  let ul = document.querySelector('#ul');  ul.addEventListener('click', event => {    console.log(event.target);  });</script>

长处

  • 代理模式能将代理对象与被调用对象拆散，升高了零碎的耦合度。代理模式在客户端和指标对象之间起到一个中介作用，这样能够起到爱护指标对象的作用
  • 代理对象能够扩大指标对象的性能；通过批改代理对象就能够了，合乎开闭准则；

毛病

解决申请速度可能有差异，非间接拜访存在开销

3. 工厂模式

工厂模式定义一个用于创建对象的接口，这个接口由子类决定实例化哪一个类。该模式使一个类的实例化提早到了子类。而子类能够重写接口办法以便创立的时候指定本人的对象类型。
class Product {    constructor(name) {        this.name = name    }    init() {        console.log('init')    }    fun() {        console.log('fun')    }}class Factory {    create(name) {        return new Product(name)    }}// uselet factory = new Factory()let p = factory.create('p1')p.init()p.fun()

场景

  • 如果你不想让某个子系统与较大的那个对象之间造成强耦合，而是想运行时从许多子系统中进行筛选的话，那么工厂模式是一个现实的抉择
  • 将new操作简略封装，遇到new的时候就应该思考是否用工厂模式；
  • 须要依赖具体环境创立不同实例，这些实例都有雷同的行为,这时候咱们能够应用工厂模式，简化实现的过程，同时也能够缩小每种对象所需的代码量，有利于打消对象间的耦合，提供更大的灵活性

长处

  • 创建对象的过程可能很简单，但咱们只须要关怀创立后果。
  • 构造函数和创建者拆散, 合乎“开闭准则”
  • 一个调用者想创立一个对象，只有晓得其名称就能够了。
  • 扩展性高，如果想减少一个产品，只有扩大一个工厂类就能够。

毛病

  • 增加新产品时，须要编写新的具体产品类,肯定水平上减少了零碎的复杂度
  • 思考到零碎的可扩展性，须要引入形象层，在客户端代码中均应用形象层进行定义，减少了零碎的抽象性和了解难度

什么时候不必

当被利用到谬误的问题类型上时,这一模式会给应用程序引入大量不必要的复杂性.除非为创建对象提供一个接口是咱们编写的库或者框架的一个设计上指标,否则我会倡议应用明确的结构器,以防止不必要的开销。

因为对象的创立过程被高效的形象在一个接口前面的事实,这也会给依赖于这个过程可能会有多简单的单元测试带来问题。

4. 单例模式

顾名思义，单例模式中Class的实例个数最多为1。当须要一个对象去贯通整个零碎执行某些工作时，单例模式就派上了用场。而除此之外的场景尽量避免单例模式的应用，因为单例模式会引入全局状态，而一个衰弱的零碎应该防止引入过多的全局状态。

实现单例模式须要解决以下几个问题：

  • 如何确定Class只有一个实例？
  • 如何简便的拜访Class的惟一实例？
  • Class如何管制实例化的过程？
  • 如何将Class的实例个数限度为1？
咱们个别通过实现以下两点来解决上述问题：
  • 暗藏Class的构造函数，防止屡次实例化
  • 通过裸露一个 getInstance() 办法来创立/获取惟一实例

Javascript中单例模式能够通过以下形式实现：

// 单例结构器const FooServiceSingleton = (function () {  // 暗藏的Class的构造函数  function FooService() {}  // 未初始化的单例对象  let fooService;  return {    // 创立/获取单例对象的函数    getInstance: function () {      if (!fooService) {        fooService = new FooService();      }      return fooService;    }  }})();

实现的关键点有：

  • 应用 IIFE创立部分作用域并即时执行；
  • getInstance() 为一个 闭包 ，应用闭包保留部分作用域中的单例对象并返回。

咱们能够验证下单例对象是否创立胜利：

const fooService1 = FooServiceSingleton.getInstance();const fooService2 = FooServiceSingleton.getInstance();console.log(fooService1 === fooService2); // true

场景例子

  • 定义命名空间和实现分支型办法
  • 登录框
  • vuex 和 redux中的store

长处

  • 划分命名空间，缩小全局变量
  • 加强模块性，把本人的代码组织在一个全局变量名下，放在繁多地位，便于保护
  • 且只会实例化一次。简化了代码的调试和保护

毛病

  • 因为单例模式提供的是一种单点拜访，所以它有可能导致模块间的强耦合
  • 从而不利于单元测试。无奈独自测试一个调用了来自单例的办法的类，而只能把它与那个单例作为一 个单元一起测试。

5. 策略模式

策略模式简略形容就是：对象有某个行为，然而在不同的场景中，该行为有不同的实现算法。把它们一个个封装起来，并且使它们能够相互替换
<html><head>    <title>策略模式-校验表单</title>    <meta content="text/html; charset=utf-8" http-equiv="Content-Type"></head><body>    <form id = "registerForm" method="post" action="http://xxxx.com/api/register">        用户名：<input type="text" name="userName">        明码：<input type="text" name="password">        手机号码：<input type="text" name="phoneNumber">        <button type="submit">提交</button>    </form>    <script type="text/javascript">        // 策略对象        const strategies = {          isNoEmpty: function (value, errorMsg) {            if (value === '') {              return errorMsg;            }          },          isNoSpace: function (value, errorMsg) {            if (value.trim() === '') {              return errorMsg;            }          },          minLength: function (value, length, errorMsg) {            if (value.trim().length < length) {              return errorMsg;            }          },          maxLength: function (value, length, errorMsg) {            if (value.length > length) {              return errorMsg;            }          },          isMobile: function (value, errorMsg) {            if (!/^(13[0-9]|14[5|7]|15[0|1|2|3|5|6|7|8|9]|17[7]|18[0|1|2|3|5|6|7|8|9])\d{8}$/.test(value)) {              return errorMsg;            }                          }        }        // 验证类        class Validator {          constructor() {            this.cache = []          }          add(dom, rules) {            for(let i = 0, rule; rule = rules[i++];) {              let strategyAry = rule.strategy.split(':')              let errorMsg = rule.errorMsg              this.cache.push(() => {                let strategy = strategyAry.shift()                strategyAry.unshift(dom.value)                strategyAry.push(errorMsg)                return strategies[strategy].apply(dom, strategyAry)              })            }          }          start() {            for(let i = 0, validatorFunc; validatorFunc = this.cache[i++];) {              let errorMsg = validatorFunc()              if (errorMsg) {                return errorMsg              }            }          }        }        // 调用代码        let registerForm = document.getElementById('registerForm')        let validataFunc = function() {          let validator = new Validator()          validator.add(registerForm.userName, [{            strategy: 'isNoEmpty',            errorMsg: '用户名不可为空'          }, {            strategy: 'isNoSpace',            errorMsg: '不容许以空白字符命名'          }, {            strategy: 'minLength:2',            errorMsg: '用户名长度不能小于2位'          }])          validator.add(registerForm.password, [ {            strategy: 'minLength:6',            errorMsg: '明码长度不能小于6位'          }])          validator.add(registerForm.phoneNumber, [{            strategy: 'isMobile',            errorMsg: '请输出正确的手机号码格局'          }])          return validator.start()        }        registerForm.onsubmit = function() {          let errorMsg = validataFunc()          if (errorMsg) {            alert(errorMsg)            return false          }        }    </script></body></html>

场景例子

  • 如果在一个零碎外面有许多类，它们之间的区别仅在于它们的'行为'，那么应用策略模式能够动静地让一个对象在许多行为中抉择一种行为。
  • 一个零碎须要动静地在几种算法中抉择一种。
  • 表单验证

长处

  • 利用组合、委托、多态等技术和思维，能够无效的防止多重条件抉择语句
  • 提供了对凋谢-关闭准则的完满反对，将算法封装在独立的strategy中，使得它们易于切换，了解，易于扩大
  • 利用组合和委托来让Context领有执行算法的能力，这也是继承的一种更轻便的代替计划

毛病

  • 会在程序中减少许多策略类或者策略对象
  • 要应用策略模式，必须理解所有的strategy，必须理解各个strategy之间的不同点，这样能力抉择一个适合的strategy

6. 迭代器模式

如果你看到这，ES6中的迭代器 Iterator 置信你还是有点印象的，下面第60条曾经做过简略的介绍。迭代器模式简略的说就是提供一种办法程序一个聚合对象中各个元素，而又不裸露该对象的外部示意。

迭代器模式解决了以下问题：

  • 提供统一的遍历各种数据结构的形式，而不必理解数据的内部结构
  • 提供遍历容器（汇合）的能力而无需扭转容器的接口

一个迭代器通常须要实现以下接口：

  • hasNext()：判断迭代是否完结，返回Boolean
  • next()：查找并返回下一个元素

为Javascript的数组实现一个迭代器能够这么写：

const item = [1, 'red', false, 3.14];function Iterator(items) {  this.items = items;  this.index = 0;}Iterator.prototype = {  hasNext: function () {    return this.index < this.items.length;  },  next: function () {    return this.items[this.index++];  }}

验证一下迭代器是否工作：

const iterator = new Iterator(item);while(iterator.hasNext()){  console.log(iterator.next());}//输入：1, red, false, 3.14
ES6提供了更简略的迭代循环语法 for...of，应用该语法的前提是操作对象须要实现 可迭代协定（The iterable protocol），简略说就是该对象有个Key为 Symbol.iterator 的办法，该办法返回一个iterator对象。

比方咱们实现一个 Range 类用于在某个数字区间进行迭代：

function Range(start, end) {  return {    [Symbol.iterator]: function () {      return {        next() {          if (start < end) {            return { value: start++, done: false };          }          return { done: true, value: end };        }      }    }  }}

验证一下：

for (num of Range(1, 5)) {  console.log(num);}// 输入：1, 2, 3, 4

7. 观察者模式

观察者模式又称公布-订阅模式（Publish/Subscribe Pattern），是咱们常常接触到的设计模式，日常生活中的利用也亘古未有，比方你订阅了某个博主的频道，当有内容更新时会收到推送；又比方JavaScript中的事件订阅响应机制。观察者模式的思维用一句话形容就是：被察看对象（subject）保护一组观察者（observer），当被察看对象状态扭转时，通过调用观察者的某个办法将这些变动告诉到观察者。

观察者模式中Subject对象个别须要实现以下API：

  • subscribe(): 接管一个观察者observer对象，使其订阅本人
  • unsubscribe(): 接管一个观察者observer对象，使其勾销订阅本人
  • fire(): 触发事件，告诉到所有观察者

用JavaScript手动实现观察者模式：

// 被观察者function Subject() {  this.observers = [];}Subject.prototype = {  // 订阅  subscribe: function (observer) {    this.observers.push(observer);  },  // 勾销订阅  unsubscribe: function (observerToRemove) {    this.observers = this.observers.filter(observer => {      return observer !== observerToRemove;    })  },  // 事件触发  fire: function () {    this.observers.forEach(observer => {      observer.call();    });  }}

验证一下订阅是否胜利：

const subject = new Subject();function observer1() {  console.log('Observer 1 Firing!');}function observer2() {  console.log('Observer 2 Firing!');}subject.subscribe(observer1);subject.subscribe(observer2);subject.fire();//输入：Observer 1 Firing! Observer 2 Firing!

验证一下勾销订阅是否胜利：

subject.unsubscribe(observer2);subject.fire();//输入：Observer 1 Firing!

场景

  • DOM事件
document.body.addEventListener('click', function() {    console.log('hello world!');});document.body.click()
  • vue 响应式

长处

  • 反对简略的播送通信，主动告诉所有曾经订阅过的对象
  • 指标对象与观察者之间的形象耦合关系能独自扩大以及重用
  • 减少了灵活性
  • 观察者模式所做的工作就是在解耦，让耦合的单方都依赖于形象，而不是依赖于具体。从而使得各自的变动都不会影响到另一边的变动。

毛病

适度应用会导致对象与对象之间的分割弱化，会导致程序难以跟踪保护和了解

8. 中介者模式

  • 在中介者模式中，中介者（Mediator）包装了一系列对象相互作用的形式，使得这些对象不用间接相互作用，而是由中介者协调它们之间的交互，从而使它们能够涣散偶合。当某些对象之间的作用产生扭转时，不会立刻影响其余的一些对象之间的作用，保障这些作用能够彼此独立的变动。
  • 中介者模式和观察者模式有肯定的相似性，都是一对多的关系，也都是集中式通信，不同的是中介者模式是解决同级对象之间的交互，而观察者模式是解决Observer和Subject之间的交互。中介者模式有些像婚恋中介，相亲对象刚开始并不能间接交换，而是要通过中介去筛选匹配再决定谁和谁见面。

场景

例如购物车需要，存在商品抉择表单、色彩抉择表单、购买数量表单等等，都会触发change事件，那么能够通过中介者来转发解决这些事件，实现各个事件间的解耦，仅仅保护中介者对象即可。
var goods = {   //手机库存    'red|32G': 3,    'red|64G': 1,    'blue|32G': 7,    'blue|32G': 6,};//中介者var mediator = (function() {    var colorSelect = document.getElementById('colorSelect');    var memorySelect = document.getElementById('memorySelect');    var numSelect = document.getElementById('numSelect');    return {        changed: function(obj) {            switch(obj){                case colorSelect:                    //TODO                    break;                case memorySelect:                    //TODO                    break;                case numSelect:                    //TODO                    break;            }        }    }})();colorSelect.onchange = function() {    mediator.changed(this);};memorySelect.onchange = function() {    mediator.changed(this);};numSelect.onchange = function() {    mediator.changed(this);};
  • 聊天室里

聊天室成员类：

function Member(name) {  this.name = name;  this.chatroom = null;}Member.prototype = {  // 发送音讯  send: function (message, toMember) {    this.chatroom.send(message, this, toMember);  },  // 接管音讯  receive: function (message, fromMember) {    console.log(`${fromMember.name} to ${this.name}: ${message}`);  }}

聊天室类：

function Chatroom() {  this.members = {};}Chatroom.prototype = {  // 减少成员  addMember: function (member) {    this.members[member.name] = member;    member.chatroom = this;  },  // 发送音讯  send: function (message, fromMember, toMember) {    toMember.receive(message, fromMember);  }}

测试一下：

const chatroom = new Chatroom();const bruce = new Member('bruce');const frank = new Member('frank');chatroom.addMember(bruce);chatroom.addMember(frank);bruce.send('Hey frank', frank);//输入：bruce to frank: hello frank

长处

  • 使各对象之间耦合涣散，而且能够独立地扭转它们之间的交互
  • 中介者和对象一对多的关系取代了对象之间的网状多对多的关系
  • 如果对象之间的简单耦合度导致保护很艰难，而且耦合度随我的项目变动增速很快，就须要中介者重构代码

毛病

零碎中会新增一个中介者对象，因为对象之间交互的复杂性，转移成了中介者对象的复杂性，使得中介者对象常常是微小的。中介 者对象本身往往就是一个难以保护的对象。

9. 访问者模式

访问者模式 是一种将算法与对象构造拆散的设计模式，艰深点讲就是：访问者模式让咱们可能在不扭转一个对象构造的前提下可能给该对象减少新的逻辑，新增的逻辑保留在一个独立的访问者对象中。访问者模式罕用于拓展一些第三方的库和工具。
// 访问者  class Visitor {    constructor() {}    visitConcreteElement(ConcreteElement) {        ConcreteElement.operation()    }}// 元素类  class ConcreteElement{    constructor() {    }    operation() {       console.log("ConcreteElement.operation invoked");      }    accept(visitor) {        visitor.visitConcreteElement(this)    }}// clientlet visitor = new Visitor()let element = new ConcreteElement()elementA.accept(visitor)

访问者模式的实现有以下几个因素：

  • Visitor Object：访问者对象，领有一个visit()办法
  • Receiving Object：接管对象，领有一个 accept() 办法
  • visit(receivingObj)：用于Visitor接管一个Receiving Object
  • accept(visitor)：用于Receving Object接管一个Visitor，并通过调用Visitor的 visit() 为其提供获取Receiving Object数据的能力

简略的代码实现如下：

Receiving Object：function Employee(name, salary) {  this.name = name;  this.salary = salary;}Employee.prototype = {  getSalary: function () {    return this.salary;  },  setSalary: function (salary) {    this.salary = salary;  },  accept: function (visitor) {    visitor.visit(this);  }}Visitor Object：function Visitor() { }Visitor.prototype = {  visit: function (employee) {    employee.setSalary(employee.getSalary() * 2);  }}

验证一下：

const employee = new Employee('bruce', 1000);const visitor = new Visitor();employee.accept(visitor);console.log(employee.getSalary());//输入：2000

场景

对象构造中对象对应的类很少扭转，但常常须要在此对象构造上定义新的操作

须要对一个对象构造中的对象进行很多不同的并且不相干的操作，而须要防止让这些操作"净化"这些对象的类，也不心愿在减少新操作时批改这些类。

长处

  • 合乎繁多职责准则
  • 优良的扩展性
  • 灵活性

毛病

  • 具体元素对访问者颁布细节，违反了迪米特准则
  • 违反了依赖倒置准则，依赖了具体类，没有依赖形象。
  • 具体元素变更比拟艰难

介绍一下Rollup

Rollup 是一款 ES Modules 打包器。它也能够将我的项目中散落的细小模块打包为整块代码，从而使得这些划分的模块能够更好地运行在浏览器环境或者 Node.js 环境。

Rollup劣势：

  • 输入后果更加扁平，执行效率更高；
  • 主动移除未援用代码；
  • 打包后果仍然齐全可读。

毛病

  • 加载非 ESM 的第三方模块比较复杂；
  • 因为模块最终都被打包到全局中，所以无奈实现 HMR；
  • 浏览器环境中，代码拆分性能必须应用 Require.js 这样的 AMD 库
  • 咱们发现如果咱们开发的是一个应用程序，须要大量援用第三方模块，同时还须要 HMR 晋升开发体验，而且利用过大就必须要分包。那这些需要 Rollup 都无奈满足。
  • 如果咱们是开发一个 JavaScript 框架或者库，那这些长处就特地有必要，而毛病呢简直也都能够疏忽，所以在很多像 React 或者 Vue 之类的框架中都是应用的 Rollup 作为模块打包器，而并非 Webpack

总结一下 ：Webpack 大而全，Rollup 小而美。

在对它们的抉择上，我的根本准则是：利用开发应用 Webpack，类库或者框架开发应用 Rollup。

不过这并不是相对的规范，只是教训法令。因为 Rollup 也可用于构建绝大多数应用程序，而 Webpack 同样也能够构建类库或者框架。

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

Webpack Proxy工作原理？为什么能解决跨域

1. 是什么

webpack proxy，即webpack提供的代理服务

根本行为就是接管客户端发送的申请后转发给其余服务器

其目标是为了便于开发者在开发模式下解决跨域问题（浏览器安全策略限度）

想要实现代理首先须要一个两头服务器，webpack中提供服务器的工具为webpack-dev-server

2. webpack-dev-server

webpack-dev-server是 webpack 官网推出的一款开发工具，将主动编译和主动刷新浏览器等一系列对开发敌对的性能全副集成在了一起

目标是为了进步开发者日常的开发效率，「只实用在开发阶段」

对于配置方面，在webpack配置对象属性中通过devServer属性提供，如下：

// ./webpack.config.jsconst path = require('path')module.exports = {    // ...    devServer: {        contentBase: path.join(__dirname, 'dist'),        compress: true,        port: 9000,        proxy: {            '/api': {                target: 'https://api.github.com'            }        }        // ...    }}

devServetr外面proxy则是对于代理的配置，该属性为对象的模式，对象中每一个属性就是一个代理的规定匹配

属性的名称是须要被代理的申请门路前缀，个别为了分别都会设置前缀为/api，值为对应的代理匹配规定，对应如下：

  • target：示意的是代理到的指标地址
  • pathRewrite：默认状况下，咱们的 /api-hy 也会被写入到URL中，如果心愿删除，能够应用pathRewrite
  • secure：默认状况下不接管转发到https的服务器上，如果心愿反对，能够设置为false
  • changeOrigin：它示意是否更新代理后申请的 headers 中host地址

2. 工作原理

proxy工作原理本质上是利用http-proxy-middleware 这个http代理中间件，实现申请转发给其余服务器

举个例子：

在开发阶段，本地地址为http://localhost:3000，该浏览器发送一个前缀带有/api标识的申请到服务端获取数据，但响应这个申请的服务器只是将申请转发到另一台服务器中

const express = require('express');const proxy = require('http-proxy-middleware');const app = express();app.use('/api', proxy({target: 'http://www.example.org', changeOrigin: true}));app.listen(3000);// http://localhost:3000/api/foo/bar -> http://www.example.org/api/foo/bar

3. 跨域

在开发阶段， webpack-dev-server 会启动一个本地开发服务器，所以咱们的利用在开发阶段是独立运行在 localhost的一个端口上，而后端服务又是运行在另外一个地址上

所以在开发阶段中，因为浏览器同源策略的起因，当本地拜访后端就会呈现跨域申请的问题

通过设置webpack proxy实现代理申请后，相当于浏览器与服务端中增加一个代理者

当本地发送申请的时候，代理服务器响应该申请，并将申请转发到指标服务器，指标服务器响应数据后再将数据返回给代理服务器，最终再由代理服务器将数据响应给本地

在代理服务器传递数据给本地浏览器的过程中，两者同源，并不存在跨域行为，这时候浏览器就能失常接收数据

留神：「服务器与服务器之间申请数据并不会存在跨域行为，跨域行为是浏览器安全策略限度」

HTTP前生今世

  • HTTP 协定始于三十年前蒂姆·伯纳斯 - 李的一篇论文
  • HTTP/0.9 是个简略的文本协定，只能获取文本资源；
  • HTTP/1.0 确立了大部分当初应用的技术，但它不是正式规范；
  • HTTP/1.1 是目前互联网上应用最宽泛的协定，性能也十分欠缺；
  • HTTP/2 基于 Google 的 SPDY 协定，重视性能改善，但还未遍及；
  • HTTP/3 基于 Google 的 QUIC 协定，是未来的倒退方向

谈一谈HTTP协定优缺点

超文本传输协定， HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和标准 。

  • HTTP 特点

    • 灵便可扩大 。一个是语法上只规定了根本格局，空格分隔单词，换行分隔字段等。另外一个就是传输模式上不仅能够传输文本，还能够传输图片，视频等任意数据。
    • 申请-应答模式 ，通常而言，就是一方发送音讯，另外一方要承受音讯，或者是做出相应等。
    • 牢靠传输 ，HTTP是基于TCP/IP，因而把这一个性继承了下来。
    • 无状态 ，这个分场景答复即可。

  • HTTP 毛病

    • 无状态 ，有时候，须要保存信息，比方像购物零碎，须要保留下顾客信息等等，另外一方面，有时候，无状态也会缩小网络开销，比方相似直播行业这样子等，这个还是分场景来说。
    • 明文传输 ，即协定里的报文(次要指的是头部)不应用二进制数据，而是文本模式。这让HTTP的报文信息裸露给了外界，给攻击者带来了便当。
    • 队头阻塞 ，当http开启长连贯时，共用一个TCP连贯，当某个申请工夫过长时，其余的申请只能处于阻塞状态，这就是队头阻塞问题。

http 无状态无连贯

  • http 协定对于事务处理没有记忆能力
  • 对同一个url申请没有上下文关系
  • 每次的申请都是独立的，它的执行状况和后果与后面的申请和之后的申请是无间接关系的，它不会受后面的申请应答状况间接影响，也不会间接影响前面的申请应答状况
  • 服务器中没有保留客户端的状态，客户端必须每次带上本人的状态去申请服务器
  • 人生若只如初见，申请过的资源下一次会持续进行申请

http协定无状态中的 状态 到底指的是什么？！

  • 【状态】的含意就是：客户端和服务器在某次会话中产生的数据
  • 那么对应的【无状态】就意味着：这些数据不会被保留
  • 通过减少cookie和session机制，当初的网络申请其实是有状态的
  • 在没有状态的http协定下，服务器也肯定会保留你每次网络申请对数据的批改，但这跟保留每次拜访的数据是不一样的，保留的只是会话产生的后果，而没有保留会话

说一说正向代理和反向代理

正向代理

咱们常说的代理也就是指正向代理，正向代理的过程，它暗藏了实在的申请客户端，服务端不晓得实在的客户端是谁，客户端申请的服务都被代理服务器代替来申请。

反向代理

这种代理模式下，它暗藏了实在的服务端，当咱们向一个网站发动申请的时候，背地可能有成千上万台服务器为咱们服务，具体是哪一台，咱们不分明，咱们只须要晓得反向代理服务器是谁就行，而且反向代理服务器会帮咱们把申请转发到实在的服务器那里去，一般而言反向代理服务器个别用来实现负载平衡。

负载平衡的两种实现形式？

  • 一种是应用反向代理的形式，用户的申请都发送到反向代理服务上，而后由反向代理服务器来转发申请到实在的服务器上，以此来实现集群的负载平衡。
  • 另一种是 DNS 的形式，DNS 能够用于在冗余的服务器上实现负载平衡。因为当初个别的大型网站应用多台服务器提供服务，因而一个域名可能会对应多个服务器地址。当用户向网站域名申请的时候，DNS 服务器返回这个域名所对应的服务器 IP 地址的汇合，但在每个答复中，会循环这些 IP 地址的程序，用户个别会抉择排在后面的地址发送申请。以此将用户的申请平衡的调配到各个不同的服务器上，这样来实现负载平衡。这种形式有一个毛病就是，因为 DNS 服务器中存在缓存，所以有可能一个服务器呈现故障后，域名解析依然返回的是那个 IP 地址，就会造成拜访的问题。

UDP和TCP有什么区别

  • TCP协定在传送数据段的时候要给段标号；UDP协定不
  • TCP协定牢靠；UDP协定不牢靠
  • TCP协定是面向连贯；UDP协定采纳无连贯
  • TCP协定负载较高，采纳虚电路；UDP采纳无连贯
  • TCP协定的发送方要确认接管方是否收到数据段（3次握手协定）
  • TCP协定采纳窗口技术和流控制

TCP为什么要三次握手

客户端和服务端都须要直到各自可收发，因而须要三次握手
  • 第一次握手胜利让服务端晓得了客户端具备发送能力
  • 第二次握手胜利让客户端晓得了服务端具备接管和发送能力，但此时服务端并不知道客户端是否接管到了本人发送的音讯
  • 所以第三次握手就起到了这个作用。`通过三次通信后，服务端

你能够能会问，2 次握手就足够了？。但其实不是，因为服务端还没有确定客户端是否筹备好了。比方步骤 3 之后，服务端马上给客户端发送数据，这个时候客户端可能还没有筹备好接收数据。因而还须要减少一个过程

TCP有6种标示:SYN(建设联机) ACK(确认) PSH(传送) FIN(完结) RST(重置) URG(紧急)

举例：已生效的连贯申请报文段

  • client发送了第一个连贯的申请报文，然而因为网络不好，这个申请没有立刻达到服务端，而是在某个网络节点中滞留了，直到某个工夫才达到server
  • 原本这曾经是一个生效的报文，然而server端接管到这个申请报文后，还是会想client收回确认的报文，表示同意连贯。
  • 如果不采纳三次握手，那么只有server收回确认，新的建设就连贯了，但其实这个申请是生效的申请，client是不会理会server的确认信息，也不会向服务端发送确认的申请
  • 然而server认为新的连贯曾经建设起来了，并始终期待client发来数据，这样，server的很多资源就没白白浪费掉了
  • 采纳三次握手就是为了避免这种状况的产生，server会因为收不到确认的报文，就晓得client并没有建设连贯。这就是三次握手的作用

三次握手过程中能够携带数据吗

  • 第一次、第二次握手不能够携带数据，因为一握二握时还没有建设连贯，会让服务器容易受到攻打
  • 而第三次握手，此时客户端曾经处于 ESTABLISHED (已建设连贯状态) ，对于客户端来说，曾经建设起连贯了，并且也曾经晓得服务器的接管、发送能力是失常的了，所以能携带数据也是没问题的。

为什么建设连贯只通信了三次，而断开连接却用了四次？

  • 客户端要求断开连接，发送一个断开的申请，这个叫作（FIN）。
  • 服务端收到申请，而后给客户端一个 ACK，作为 FIN 的响应。
  • 这里你须要思考一个问题，可不可以像握手那样马上传 FIN 回去？
  • 其实这个时候服务端不能马上传 FIN，因为断开连接要解决的问题比拟多，比如说服务端可能还有发送进来的音讯没有失去 ACK；也有可能服务端本人有资源要开释。因而断开连接不能像握手那样操作——将两条音讯合并。所以，服务端通过一个期待，确定能够敞开连贯了，再发一条 FIN 给客户端。
  • 客户端收到服务端的 FIN，同时客户端也可能有本人的事件须要解决完，比方客户端有发送给服务端没有收到 ACK 的申请，客户端本人解决实现后，再给服务端发送一个 ACK。

为了确保数据可能实现传输。因为当服务端收到客户端的 FIN 报文后，发送的 ACK 报文只是用来应答的，并不示意服务端也心愿立刻敞开连贯。

当只有服务端把所有的报文都发送完了，才会发送 FIN 报文，通知客户端能够断开连接了，因而在断开连接时须要四次挥手。

  • 敞开连贯时，当收到对方的FIN报文告诉时，它仅仅示意对方没有数据发送给你了；但未必你所有的数据都全副发送给对方了
  • 所以你未必会马上敞开SOCKET,也即你可能还须要发送一些数据给对方之后，再发送FIN报文给对方来示意你批准当初能够敞开连贯了，所以它这里的ACK报文和FIN报文少数状况下都是离开发送的。

diff算法是怎么运作

每一种节点类型有本人的属性，也就是prop，每次进行diff的时候，react会先比拟该节点类型，如果节点类型不一样，那么react会间接删除该节点，而后间接创立新的节点插入到其中，如果节点类型一样，那么会比拟prop是否有更新，如果有prop不一样，那么react会断定该节点有更新，那么重渲染该节点，而后在对其子节点进行比拟，一层一层往下，直到没有子节点
  • 把树形构造依照层级合成，只比拟同级元素。
  • 给列表构造的每个单元增加惟一的key属性，不便比拟。
  • React 只会匹配雷同 class 的 component（这外面的class指的是组件的名字）
  • 合并操作，调用 component 的 setState 办法的时候, React 将其标记为 - dirty.到每一个事件循环完结, React 查看所有标记 dirty的 component从新绘制.
  • 抉择性子树渲染。开发人员能够重写shouldComponentUpdate进步diff的性能

优化⬇️

为了升高算法复杂度，React的diff会预设三个限度：
  1. 只对同级元素进行Diff。如果一个DOM节点在前后两次更新中逾越了层级，那么React不会尝试复用他。
  2. 两个不同类型的元素会产生出不同的树。如果元素由div变为p，React会销毁div及其子孙节点，并新建p及其子孙节点。
  3. 开发者能够通过 key prop来暗示哪些子元素在不同的渲染下能保持稳定。思考如下例子：

Diff的思路

该如何设计算法呢？如果让我设计一个Diff算法，我首先想到的计划是：

  1. 判断以后节点的更新属于哪种状况
  2. 如果是新增，执行新增逻辑
  3. 如果是删除，执行删除逻辑
  4. 如果是更新，执行更新逻辑
  5. 按这个计划，其实有个隐含的前提——不同操作的优先级是雷同的
  6. 然而React团队发现，在日常开发中，相较于新增和删除，更新组件产生的频率更高。所以Diff会优先判断以后节点是否属于更新。

基于以上起因，Diff算法的整体逻辑会经验两轮遍历：

  • 第一轮遍历：解决更新的节点。
  • 第二轮遍历：解决剩下的不属于更新的节点。

diff算法的作用

计算出Virtual DOM中真正变动的局部，并只针对该局部进行原生DOM操作，而非从新渲染整个页面。

传统diff算法

通过循环递归对节点进行顺次比照，算法复杂度达到 O(n^3) ，n是树的节点数，这个有多可怕呢？——如果要展现1000个节点，得执行上亿次比拟。。即使是CPU快能执行30亿条命令，也很难在一秒内计算出差别。

React的diff算法

  1. 什么是和谐？
将Virtual DOM树转换成actual DOM树的起码操作的过程 称为 和谐 。
  1. 什么是React diff算法？
diff算法是和谐的具体实现。

diff策略

React用 三大策略 将O(n^3)复杂度 转化为 O(n)复杂度

策略一（tree diff）：

  • Web UI中DOM节点跨层级的挪动操作特地少，能够忽略不计。

策略二（component diff）：

  • 领有雷同类的两个组件 生成类似的树形构造，
  • 领有不同类的两个组件 生成不同的树形构造。

策略三（element diff）：

对于同一层级的一组子节点，通过惟一id辨别。

tree diff

  • React通过updateDepth对Virtual DOM树进行层级管制。
  • 对树分层比拟，两棵树 只对同一档次节点 进行比拟。如果该节点不存在时，则该节点及其子节点会被齐全删除，不会再进一步比拟。
  • 只需遍历一次，就能实现整棵DOM树的比拟。

那么问题来了，如果DOM节点呈现了跨层级操作,diff会咋办呢？

答：diff只简略思考同层级的节点地位变换，如果是跨层级的话，只有创立节点和删除节点的操作。

如上图所示，以A为根节点的整棵树会被从新创立，而不是挪动，因而 官网倡议不要进行DOM节点跨层级操作，能够通过CSS暗藏、显示节点，而不是真正地移除、增加DOM节点

component diff

React对不同的组件间的比拟，有三种策略
  1. 同一类型的两个组件，按原策略（层级比拟）持续比拟Virtual DOM树即可。
  2. 同一类型的两个组件，组件A变动为组件B时，可能Virtual DOM没有任何变动，如果晓得这点（变换的过程中，Virtual DOM没有扭转），可节俭大量计算工夫，所以 用户 能够通过 shouldComponentUpdate() 来判断是否须要 判断计算。
  3. 不同类型的组件，将一个（将被扭转的）组件判断为dirty component（脏组件），从而替换 整个组件的所有节点。
留神：如果组件D和组件G的构造类似，然而 React判断是 不同类型的组件，则不会比拟其构造，而是删除 组件D及其子节点，创立组件G及其子节点。

element diff

当节点处于同一层级时，diff提供三种节点操作：删除、插入、挪动。
  • 插入：组件 C 不在汇合（A,B）中，须要插入

  • 删除：

    • 组件 D 在汇合（A,B,D）中，但 D的节点曾经更改，不能复用和更新，所以须要删除 旧的 D ，再创立新的。
    • 组件 D 之前在 汇合（A,B,D）中，但汇合变成新的汇合（A,B）了，D 就须要被删除。
  • 挪动：组件D曾经在汇合（A,B,C,D）里了，且汇合更新时，D没有产生更新，只是地位扭转，如新汇合（A,D,B,C），D在第二个，毋庸像传统diff，让旧汇合的第二个B和新汇合的第二个D 比拟，并且删除第二个地位的B，再在第二个地位插入D，而是 （对同一层级的同组子节点） 增加惟一key进行辨别，挪动即��。

总结

  1. tree diff：只比照同一层的 dom 节点，疏忽 dom 节点的跨层级挪动

如下图，react 只会对雷同色彩方框内的 DOM 节点进行比拟，即同一个父节点下的所有子节点。当发现节点不存在时，则该节点及其子节点会被齐全删除掉，不会用于进一步的比拟。

这样只须要对树进行一次遍历，便能实现整个 DOM 树的比拟。

这就意味着，如果 dom 节点产生了跨层级挪动，react 会删除旧的节点，生成新的节点，而不会复用。

  1. component diff：如果不是同一类型的组件，会删除旧的组件，创立新的组件

  1. element diff：对于同一层级的一组子节点，须要通过惟一 id 进行来辨别
  2. 如果没有 id 来进行辨别，一旦有插入动作，会导致插入地位之后的列表全副从新渲染
  3. 这也是为什么渲染列表时为什么要应用惟一的 key。

diff的有余与待优化的中央

尽量减少相似将最初一个节点挪动到列表首部的操作，当节点数量过大或更新操作过于频繁时，会影响React的渲染性能

与其余框架相比，React 的 diff 算法有何不同？

diff 算法探讨的就是虚构 DOM 树发生变化后，生成 DOM 树更新补丁的形式。它通过比照新旧两株虚构 DOM 树的变更差别，将更新补丁作用于实在 DOM，以最小老本实现视图更新

具体的流程是这样的：

  • 实在 DOM 与虚构 DOM 之间存在一个映射关系。这个映射关系依附初始化时的 JSX 建设实现；
  • 当虚构 DOM 发生变化后，就会依据差距计算生成 patch，这个 patch 是一个结构化的数据，内容蕴含了减少、更新、移除等；
  • 最初再依据 patch 去更新实在的 DOM，反馈到用户的界面上。

在答复有何不同之前，首先须要阐明下什么是 diff 算法。

  • diff 算法是指生成更新补丁的形式，次要利用于虚构 DOM 树变动后，更新实在 DOM。所以 diff 算法肯定存在这样一个过程：触发更新 → 生成补丁 → 利用补丁

  • React 的 diff 算法，触发更新的机会次要在 state 变动与 hooks 调用之后。此时触发虚构 DOM 树变更遍历，采纳了深度优先遍历算法。但传统的遍历形式，效率较低。为了优化效率，应用了分治的形式。将繁多节点比对转化为了 3 种类型节点的比对，别离是树、组件及元素，以此晋升效率。

    • 树比对：因为网页视图中较少有跨层级节点挪动，两株虚构 DOM 树只对同一档次的节点进行比拟。
    • 组件比对：如果组件是同一类型，则进行树比对，如果不是，则间接放入到补丁中。
    • 元素比对：次要产生在同层级中，通过标记节点操作生成补丁，节点操作对应实在的 DOM 剪裁操作。同一层级的子节点，能够通过标记 key 的形式进行列表比照。
  • 以上是经典的 React diff 算法内容。自 React 16 起，引入了 Fiber 架构。为了使整个更新过程可随时暂停复原，节点与树别离采纳了 FiberNode 与 FiberTree 进行重构。fiberNode 应用了双链表的构造，能够间接找到兄弟节点与子节点

  • 而后拿 Vue 和 Preact 与 React 的 diff 算法进行比照

    • Preact 的 Diff 算法相较于 React，整体设计思路类似，但最底层的元素采纳了实在 DOM 比照操作，也没有采纳 Fiber 设计。Vue 的 Diff 算法整体也与 React 类似，同样未实现 Fiber 设计
  • 而后进行横向比拟，React 领有残缺的 Diff 算法策略，且领有随时中断更新的工夫切片能力，在大批量节点更新的极其状况下，领有更敌对的交互体验。
  • Preact 能够在一些对性能要求不高，仅须要渲染框架的简略场景下利用。
  • Vue 的整体 diff 策略与 React 对齐，尽管不足工夫切片能力，但这并不意味着 Vue 的性能更差，因为在 Vue 3 初期引入过，前期因为收益不高移除掉了。除了高帧率动画，在 Vue 中其余的场景简直都能够应用防抖和节流去进步响应性能。

学习原理的目标就是利用。那如何依据 React diff 算法原理优化代码呢？这个问题其实按优化形式逆向答复即可。

  • 依据 diff 算法的设计准则，应尽量避免跨层级节点挪动。
  • 通过设置惟一 key 进行优化，尽量减少组件层级深度。因为过深的层级会加深遍历深度，带来性能问题。
  • 设置 shouldComponentUpdate 或者 React.pureComponet 缩小 diff 次数。

Compositon api

Composition API也叫组合式API，是Vue3.x的新个性。

通过创立 Vue 组件，咱们能够将接口的可重复部分及其性能提取到可重用的代码段中。仅此一项就能够使咱们的应用程序在可维护性和灵活性方面走得更远。然而，咱们的教训曾经证实，光靠这一点可能是不够的，尤其是当你的应用程序变得十分大的时候——想想几百个组件。在解决如此大的应用程序时，共享和重用代码变得尤为重要
  • Vue2.0中，随着性能的减少，组件变得越来越简单，越来越难保护，而难以保护的根本原因是Vue的API设计迫使开发者应用watch，computed，methods选项组织代码，而不是理论的业务逻辑。
  • 另外Vue2.0短少一种较为简洁的低成本的机制来实现逻辑复用，尽管能够minxis实现逻辑复用，然而当mixin变多的时候，会使得难以找到对应的data、computed或者method来源于哪个mixin，使得类型推断难以进行。
  • 所以Composition API的呈现，次要是也是为了解决Option API带来的问题，第一个是代码组织问题，Compostion API能够让开发者依据业务逻辑组织本人的代码，让代码具备更好的可读性和可扩展性，也就是说当下一个开发者接触这一段不是他本人写的代码时，他能够更好的利用代码的组织反推出理论的业务逻辑，或者依据业务逻辑更好的了解代码。
  • 第二个是实现代码的逻辑提取与复用，当然mixin也能够实现逻辑提取与复用，然而像后面所说的，多个mixin作用在同一个组件时，很难看出property是来源于哪个mixin，起源不分明，另外，多个mixin的property存在变量命名抵触的危险。而Composition API刚好解决了这两个问题。

艰深的讲：

没有Composition API之前vue相干业务的代码须要配置到option的特定的区域，中小型我的项目是没有问题的，然而在大型项目中会导致前期的维护性比较复杂，同时代码可复用性不高。Vue3.x中的composition-api就是为了解决这个问题而生的

compositon api提供了以下几个函数：

  • setup
  • ref
  • reactive
  • watchEffect
  • watch
  • computed
  • toRefs
  • 生命周期的hooks

都说Composition API与React Hook很像，说说区别

从React Hook的实现角度看，React Hook是依据useState调用的程序来确定下一次重渲染时的state是来源于哪个useState，所以呈现了以下限度
  • 不能在循环、条件、嵌套函数中调用Hook
  • 必须确保总是在你的React函数的顶层调用Hook
  • useEffect、useMemo等函数必须手动确定依赖关系
而Composition API是基于Vue的响应式零碎实现的，与React Hook的相比
  • 申明在setup函数内，一次组件实例化只调用一次setup，而React Hook每次重渲染都须要调用Hook，使得React的GC比Vue更有压力，性能也绝对于Vue来说也较慢
  • Compositon API的调用不须要顾虑调用程序，也能够在循环、条件、嵌套函数中应用
  • 响应式零碎主动实现了依赖收集，进而组件的局部的性能优化由Vue外部本人实现，而React Hook须要手动传入依赖，而且必须必须保障依赖的程序，让useEffect、useMemo等函数正确的捕捉依赖变量，否则会因为依赖不正确使得组件性能降落。
尽管Compositon API看起来比React Hook好用，然而其设计思维也是借鉴React Hook的。

setState原理剖析

1. setState异步更新

  • 咱们都晓得，React通过this.state来拜访state，通过this.setState()办法来更新state。当this.setState()办法被调用的时候，React会从新调用render办法来从新渲染UI
  • 首先如果间接在setState前面获取state的值是获取不到的。在React外部机制能检测到的中央， setState就是异步的；在React检测不到的中央，例如setInterval,setTimeout，setState就是同步更新的

因为setState是能够承受两个参数的，一个state，一个回调函数。因而咱们能够在回调函数外面获取值

  • setState办法通过一个队列机制实现state更新，当执行setState的时候，会将须要更新的state合并之后放入状态队列，而不会立刻更新this.state
  • 如果咱们不应用setState而是应用this.state.key来批改，将不会触发组件的re-render。
  • 如果将this.state赋值给一个新的对象援用，那么其余不在对象上的state将不会被放入状态队列中，当下次调用setState并对状态队列进行合并时，间接造成了state失落

1.1 setState批量更新的过程

在react生命周期和合成事件执行前后都有相应的钩子，别离是pre钩子和post钩子，pre钩子会调用batchedUpdate办法将isBatchingUpdates变量置为true，开启批量更新，而post钩子会将isBatchingUpdates置为false
  • isBatchingUpdates变量置为true，则会走批量更新分支，setState的更新会被存入队列中，待同步代码执行完后，再执行队列中的state更新。 isBatchingUpdates为 true，则把以后组件（即调用了 setState的组件）放入 dirtyComponents 数组中；否则 batchUpdate 所有队列中的更新
  • 而在原生事件和异步操作中，不会执行pre钩子，或者生命周期的中的异步操作之前执行了pre钩子，然而pos钩子也在异步操作之前执行完了，isBatchingUpdates必然为false，也就不会进行批量更新

enqueueUpdate蕴含了React防止反复render的逻辑。mountComponent和updateComponent办法在执行的最开始，会调用到batchedUpdates进行批处理更新，此时会将isBatchingUpdates设置为true，也就是将状态标记为当初正处于更新阶段了。 isBatchingUpdates为 true，则把以后组件（即调用了 setState 的组件）放入dirtyComponents 数组中；否则 batchUpdate 所有队列中的更新

1.2 为什么间接批改this.state有效

  • 要晓得setState实质是通过一个队列机制实现state更新的。 执行setState时，会将须要更新的state合并后放入状态队列，而不会立即更新state，队列机制能够批量更新state。
  • 如果不通过setState而间接批改this.state，那么这个state不会放入状态队列中，下次调用setState时对状态队列进行合并时，会疏忽之前间接被批改的state，这样咱们就无奈合并了，而且理论也没有把你想要的state更新下来

1.3 什么是批量更新 Batch Update

在一些mv*框架中，，就是将一段时间内对model的批改批量更新到view的机制。比方那前端比拟火的React、vue（nextTick机制,视图的更新以及实现）

1.4 setState之后产生的事件

  • setState操作并不保障是同步的，也能够认为是异步的
  • React在setState之后，会经对state进行diff，判断是否有扭转，而后去diff dom决定是否要更新UI。如果这一系列过程立即产生在每一个setState之后，就可能会有性能问题
  • 在短时间内频繁setState。React会将state的扭转压入栈中，在适合的机会，批量更新state和视图，达到进步性能的成果

1.5 如何晓得state曾经被更新

传入回调函数
setState({    index: 1}}, function(){    console.log(this.state.index);})
在钩子函数中体现
componentDidUpdate(){    console.log(this.state.index);}

2. setState循环调用危险

  • 当调用setState时，实际上会执行enqueueSetState办法，并对partialState以及_pending-StateQueue更新队列进行合并操作，最终通过enqueueUpdate执行state更新
  • 而performUpdateIfNecessary办法会获取_pendingElement,_pendingStateQueue，_pending-ForceUpdate，并调用receiveComponent和updateComponent办法进行组件更新
  • 如果在shouldComponentUpdate或者componentWillUpdate办法中调用setState，此时this._pending-StateQueue != null，就会造成循环调用，使得浏览器内存占满后解体

3 事务

  • 事务就是将须要执行的办法应用wrapper封装起来，再通过事务提供的perform办法执行，先执行wrapper中的initialize办法，执行完perform之后，在执行所有的close办法，一组initialize及close办法称为一个wrapper。
  • 那么事务和setState办法的不同体现有什么关系，首先咱们把4次setState简略归类，前两次属于一类，因为它们在同一调用栈中执行，setTimeout中的两次setState属于另一类
  • 在setState调用之前，曾经处在batchedUpdates执行的事务中了。那么这次batchedUpdates办法是谁调用的呢，原来是ReactMount.js中的_renderNewRootComponent办法。也就是说，整个将React组件渲染到DOM中的过程就是处于一个大的事务中。而在componentDidMount中调用setState时，batchingStrategy的isBatchingUpdates曾经被设为了true，所以两次setState的后果没有立刻失效
  • 再反观setTimeout中的两次setState，因为没有前置的batchedUpdates调用，所以导致了新的state马上失效

4. 总结

  • 通过setState去更新this.state，不要间接操作this.state，请把它当成不可变的
  • 调用setState更新this.state不是马上失效的，它是异步的，所以不要天真认为执行完setState后this.state就是最新的值了
  • 多个程序执行的setState不是同步地一个一个执行滴，会一个一个退出队列，而后最初一起执行，即批处理

watch 的了解

watch没有缓存性，更多的是察看的作用，能够监听某些数据执行回调。当咱们须要深度监听对象中的属性时，能够关上deep：true选项，这样便会对对象中的每一项进行监听。这样会带来性能问题，优化的话能够应用字符串模式监听

留神：Watcher : 观察者对象 , 实例分为渲染 watcher (render watcher),计算属性 watcher (computed watcher),侦听器 watcher（user watcher）三种

Promise

这里你谈 promise的时候，除了将他解决的痛点以及罕用的 API 之外，最好进行拓展把 eventloop 带进来好好讲一下，microtask(微工作)、macrotask(工作) 的执行程序，如果看过 promise 源码，最好能够谈一谈 原生 Promise 是如何实现的。Promise 的关键点在于callback 的两个参数，一个是 resovle，一个是 reject。还有就是 Promise 的链式调用（Promise.then()，每一个 then 都是一个责任人）
  • Promise 是 ES6 新增的语法，解决了回调天堂的问题。
  • 能够把 Promise看成一个状态机。初始是 pending 状态，能够通过函数 resolve 和 reject，将状态转变为 resolved 或者 rejected 状态，状态一旦扭转就不能再次变动。
  • then 函数会返回一个 Promise 实例，并且该返回值是一个新的实例而不是之前的实例。因为 Promise 标准规定除了 pending 状态，其余状态是不能够扭转的，如果返回的是一个雷同实例的话，多个 then 调用就失去意义了。 对于 then 来说，实质上能够把它看成是 flatMap

1. Promise 的根本状况

简略来说它就是一个容器，外面保留着某个将来才会完结的事件（通常是异步操作）的后果。从语法上说，Promise 是一个对象，从它能够获取异步操作的音讯

个别 Promise 在执行过程中，必然会处于以下几种状态之一。

  • 待定（pending）：初始状态，既没有被实现，也没有被回绝。
  • 已实现（fulfilled）：操作胜利实现。
  • 已回绝（rejected）：操作失败。
待定状态的 Promise 对象执行的话，最初要么会通过一个值实现，要么会通过一个起因被回绝。当其中一种状况产生时，咱们用 Promise 的 then 办法排列起来的相干处理程序就会被调用。因为最初 Promise.prototype.then 和 Promise.prototype.catch 办法返回的是一个 Promise， 所以它们能够持续被链式调用

对于 Promise 的状态流转状况，有一点值得注意的是，外部状态扭转之后不可逆，你须要在编程过程中加以留神。文字描述比拟艰涩，咱们间接通过一张图就能很清晰地看出 Promise 外部状态流转的状况

从上图能够看出，咱们最开始创立一个新的 Promise 返回给 p1 ，而后开始执行，状态是 pending，当执行 resolve之后状态就切换为 fulfilled，执行 reject 之后就变为 rejected 的状态

2. Promise 的静态方法

  • all 办法

    • 语法： Promise.all（iterable）
    • 参数： 一个可迭代对象，如 Array。

    • 形容： 此办法对于汇总多个 promise 的后果很有用，在 ES6 中能够将多个 Promise.all 异步申请并行操作，返回后果个别有上面两种状况。

      • 当所有后果胜利返回时依照申请程序返回胜利后果。
      • 当其中有一个失败办法时，则进入失败办法
  • 咱们来看下业务的场景，对于上面这个业务场景页面的加载，将多个申请合并到一起，用 all 来实现可能成果会更好，请看代码片段
// 在一个页面中须要加载获取轮播列表、获取店铺列表、获取分类列表这三个操作，页面须要同时发出请求进行页面渲染，这样用 `Promise.all` 来实现，看起来更清晰、高深莫测。//1.获取轮播数据列表function getBannerList(){  return new Promise((resolve,reject)=>{      setTimeout(function(){        resolve('轮播数据')      },300)   })}//2.获取店铺列表function getStoreList(){  return new Promise((resolve,reject)=>{    setTimeout(function(){      resolve('店铺数据')    },500)  })}//3.获取分类列表function getCategoryList(){  return new Promise((resolve,reject)=>{    setTimeout(function(){      resolve('分类数据')    },700)  })}function initLoad(){   Promise.all([getBannerList(),getStoreList(),getCategoryList()])  .then(res=>{    console.log(res)   }).catch(err=>{    console.log(err)  })} initLoad()

  • allSettled 办法

    • Promise.allSettled 的语法及参数跟 Promise.all 相似，其参数承受一个 Promise 的数组，返回一个新的 Promise。惟一的不同在于，执行完之后不会失败，也就是说当 Promise.allSettled 全副解决实现后，咱们能够拿到每个 Promise 的状态，而不论其是否解决胜利
  • 咱们来看一下用 allSettled 实现的一段代码
const resolved = Promise.resolve(2);const rejected = Promise.reject(-1);const allSettledPromise = Promise.allSettled([resolved, rejected]);allSettledPromise.then(function (results) {  console.log(results);});// 返回后果：// [//    { status: 'fulfilled', value: 2 },//    { status: 'rejected', reason: -1 }// ]
从下面代码中能够看到，Promise.allSettled 最初返回的是一个数组，记录传进来的参数中每个 Promise 的返回值，这就是和 all 办法不太一样的中央。

  • any 办法

    • 语法： Promise.any（iterable）
    • 参数： iterable 可迭代的对象，例如 Array。
    • 形容： any 办法返回一个 Promise，只有参数 Promise 实例有一个变成 fulfilled状态，最初 any返回的实例就会变成 fulfilled 状态；如果所有参数 Promise 实例都变成 rejected 状态，包装实例就会变成 rejected 状态。
const resolved = Promise.resolve(2);const rejected = Promise.reject(-1);const anyPromise = Promise.any([resolved, rejected]);anyPromise.then(function (results) {  console.log(results);});// 返回后果：// 2
从革新后的代码中能够看出，只有其中一个 Promise 变成 fulfilled状态，那么 any 最初就返回这个p romise。因为下面 resolved 这个 Promise 曾经是 resolve 的了，故最初返回后果为 2

  • race 办法

    • 语法： Promise.race（iterable）
    • 参数： iterable 可迭代的对象，例如 Array。
    • 形容： race办法返回一个 Promise，只有参数的 Promise 之中有一个实例率先扭转状态，则 race 办法的返回状态就跟着扭转。那个率先扭转的 Promise 实例的返回值，就传递给 race 办法的回调函数
  • 咱们来看一下这个业务场景，对于图片的加载，特地适宜用 race 办法来解决，将图片申请和超时判断放到一起，用 race 来实现图片的超时判断。请看代码片段。
//申请某个图片资源function requestImg(){  var p = new Promise(function(resolve, reject){    var img = new Image();    img.onload = function(){ resolve(img); }    img.src = 'http://www.baidu.com/img/flexible/logo/pc/result.png';  });  return p;}//延时函数，用于给申请计时function timeout(){  var p = new Promise(function(resolve, reject){    setTimeout(function(){ reject('图片申请超时'); }, 5000);  });  return p;}Promise.race([requestImg(), timeout()]).then(function(results){  console.log(results);}).catch(function(reason){  console.log(reason);});// 从下面的代码中能够看出，采纳 Promise 的形式来判断图片是否加载胜利，也是针对 Promise.race 办法的一个比拟好的业务场景

promise手写实现，面试够用版：

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);    }}// 定义链式调用的then办法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:          }}

TCP 和 UDP的概念及特点

TCP 和 UDP都是传输层协定，他们都属于TCP/IP协定族：

（1）UDP

UDP的全称是用户数据报协定，在网络中它与TCP协定一样用于解决数据包，是一种无连贯的协定。在OSI模型中，在传输层，处于IP协定的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的毛病，也就是说，当报文发送之后，是无奈得悉其是否平安残缺达到的。

它的特点如下：

1）面向无连贯

首先 UDP 是不须要和 TCP一样在发送数据前进行三次握手建设连贯的，想发数据就能够开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。

具体来说就是：

  • 在发送端，应用层将数据传递给传输层的 UDP 协定，UDP 只会给数据减少一个 UDP 头标识下是 UDP 协定，而后就传递给网络层了
  • 在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作

2）有单播，多播，播送的性能

UDP 不止反对一对一的传输方式，同样反对一对多，多对多，多对一的形式，也就是说 UDP 提供了单播，多播，播送的性能。

3）面向报文

发送方的UDP对应用程序交下来的报文，在增加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因而，应用程序必须抉择适合大小的报文

4）不可靠性

首先不可靠性体现在无连贯上，通信都不须要建设连贯，想发就发，这样的状况必定不牢靠。

并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关怀对方是否曾经正确接管到数据了。

再者网络环境时好时坏，然而 UDP 因为没有拥塞管制，始终会以恒定的速度发送数据。即便网络条件不好，也不会对发送速率进行调整。这样实现的弊病就是在网络条件不好的状况下可能会导致丢包，然而长处也很显著，在某些实时性要求高的场景（比方电话会议）就须要应用 UDP 而不是 TCP。

5）头部开销小，传输数据报文时是很高效的。

UDP 头部蕴含了以下几个数据：

  • 两个十六位的端口号，别离为源端口（可选字段）和指标端口
  • 整个数据报文的长度
  • 整个数据报文的测验和（IPv4 可选字段），该字段用于发现头部信息和数据中的谬误

因而 UDP 的头部开销小，只有8字节，相比 TCP 的至多20字节要少得多，在传输数据报文时是很高效的。

（2）TCP TCP的全称是传输控制协议是一种面向连贯的、牢靠的、基于字节流的传输层通信协议。TCP 是面向连贯的、牢靠的流协定（流就是指不间断的数据结构）。

它有以下几个特点：

1）面向连贯

面向连贯，是指发送数据之前必须在两端建设连贯。建设连贯的办法是“三次握手”，这样能建设牢靠的连贯。建设连贯，是为数据的牢靠传输打下了根底。

2）仅反对单播传输

每条TCP传输连贯只能有两个端点，只能进行点对点的数据传输，不反对多播和播送传输方式。

3）面向字节流

TCP不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的状况下以字节流形式进行传输。

4）牢靠传输

对于牢靠传输，判断丢包、误码靠的是TCP的段编号以及确认号。TCP为了保障报文传输的牢靠，就给每个包一个序号，同时序号也保障了传送到接收端实体的包的按序接管。而后接收端实体对已胜利收到的字节发回一个相应的确认(ACK)；如果发送端实体在正当的往返时延(RTT)内未收到确认，那么对应的数据（假如失落了）将会被重传。

5）提供拥塞管制

当网络呈现拥塞的时候，TCP可能减小向网络注入数据的速率和数量，缓解拥塞。

6）提供全双工通信

TCP容许通信单方的应用程序在任何时候都能发送数据，因为TCP连贯的两端都设有缓存，用来长期寄存双向通信的数据。当然，TCP能够立刻发送一个数据段，也能够缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）

Chrome 关上一个页面须要启动多少过程？别离有哪些过程？

关上 1 个页面至多须要 1 个网络过程、1 个浏览器过程、1 个 GPU 过程以及 1 个渲染过程，共 4 个；最新的 Chrome 浏览器包含：1 个浏览器（Browser）主过程、1 个 GPU 过程、1 个网络（NetWork）过程、多个渲染过程和多个插件过程。

  • 浏览器过程：次要负责界面显示、用户交互、子过程治理，同时提供存储等性能。
  • 渲染过程：外围工作是将 HTML、CSS 和 JavaScript 转换为用户能够与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该过程中，默认状况下，Chrome 会为每个 Tab 标签创立一个渲染过程。出于平安思考，渲染过程都是运行在沙箱模式下。
  • GPU 过程：其实，Chrome 刚开始公布的时候是没有 GPU 过程的。而 GPU 的应用初衷是为了实现 3D CSS 的成果，只是随后网页、Chrome 的 UI 界面都抉择采纳 GPU 来绘制，这使得 GPU 成为浏览器广泛的需要。最初，Chrome 在其多过程架构上也引入了 GPU 过程。
  • 网络过程：次要负责页面的网络资源加载，之前是作为一个模块运行在浏览器过程外面的，直至最近才独立进去，成为一个独自的过程。
  • 插件过程：次要是负责插件的运行，因插件易解体，所以须要通过插件过程来隔离，以保障插件过程解体不会对浏览器和页面造成影响。

TCP和UDP的应用场景

  • TCP利用场景： 效率要求绝对低，但对准确性要求绝对高的场景。因为传输中须要对数据确认、重发、排序等操作，相比之下效率没有UDP高。例如：文件传输（精确高要求高、然而速度能够绝对慢）、承受邮件、近程登录。
  • UDP利用场景： 效率要求绝对高，对准确性要求绝对低的场景。例如：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，然而呈现偶然断续不是太大问题，并且此处齐全不能够应用重发机制）、播送通信（播送、多播）。

浏览器的垃圾回收机制

（1）垃圾回收的概念

垃圾回收：JavaScript代码运行时，须要分配内存空间来贮存变量和值。当变量不在参加运行时，就须要零碎发出被占用的内存空间，这就是垃圾回收。

回收机制：

  • Javascript 具备主动垃圾回收机制，会定期对那些不再应用的变量、对象所占用的内存进行开释，原理就是找到不再应用的变量，而后开释掉其占用的内存。
  • JavaScript中存在两种变量：局部变量和全局变量。全局变量的生命周期会继续要页面卸载；而局部变量申明在函数中，它的生命周期从函数执行开始，直到函数执行完结，在这个过程中，局部变量会在堆或栈中存储它们的值，当函数执行完结后，这些局部变量不再被应用，它们所占有的空间就会被开释。
  • 不过，当局部变量被内部函数应用时，其中一种状况就是闭包，在函数执行完结后，函数内部的变量仍然指向函数外部的局部变量，此时局部变量仍然在被应用，所以不会回收。

（2）垃圾回收的形式

浏览器通常应用的垃圾回收办法有两种：标记革除，援用计数。 1）标记革除

  • 标记革除是浏览器常见的垃圾回收形式，当变量进入执行环境时，就标记这个变量“进入环境”，被标记为“进入环境”的变量是不能被回收的，因为他们正在被应用。当变量来到环境时，就会被标记为“来到环境”，被标记为“来到环境”的变量会被内存开释。
  • 垃圾收集器在运行的时候会给存储在内存中的所有变量都加上标记。而后，它会去掉环境中的变量以及被环境中的变量援用的标记。而在此之后再被加上标记的变量将被视为筹备删除的变量，起因是环境中的变量曾经无法访问到这些变量了。最初。垃圾收集器实现内存革除工作，销毁那些带标记的值，并回收他们所占用的内存空间。

2）援用计数

  • 另外一种垃圾回收机制就是援用计数，这个用的绝对较少。援用计数就是跟踪记录每个值被援用的次数。当申明了一个变量并将一个援用类型赋值给该变量时，则这个值的援用次数就是1。相同，如果蕴含对这个值援用的变量又获得了另外一个值，则这个值的援用次数就减1。当这个援用次数变为0时，阐明这个变量曾经没有价值，因而，在在机回收期下次再运行时，这个变量所占有的内存空间就会被释放出来。
  • 这种办法会引起循环援用的问题：例如： obj1和obj2通过属性进行互相援用，两个对象的援用次数都是2。当应用循环计数时，因为函数执行完后，两个对象都来到作用域，函数执行完结，obj1和obj2还将会持续存在，因而它们的援用次数永远不会是0，就会引起循环援用。
function fun() {    let obj1 = {};    let obj2 = {};    obj1.a = obj2; // obj1 援用 obj2    obj2.a = obj1; // obj2 援用 obj1}

这种状况下，就要手动开释变量占用的内存：

obj1.a =  null obj2.a =  null

（3）缩小垃圾回收

尽管浏览器能够进行垃圾主动回收，然而当代码比较复杂时，垃圾回收所带来的代价比拟大，所以应该尽量减少垃圾回收。

  • 对数组进行优化： 在清空一个数组时，最简略的办法就是给其赋值为[ ]，然而与此同时会创立一个新的空对象，能够将数组的长度设置为0，以此来达到清空数组的目标。
  • 对object进行优化： 对象尽量复用，对于不再应用的对象，就将其设置为null，尽快被回收。
  • 对函数进行优化： 在循环中的函数表达式，如果能够复用，尽量放在函数的里面。

URL有哪些组成部分

一个残缺的URL包含以下几局部：

  • 协定局部：该URL的协定局部为“http：”，这代表网页应用的是HTTP协定。在Internet中能够应用多种协定，如HTTP，FTP等等本例中应用的是HTTP协定。在"HTTP"前面的“//”为分隔符；
  • 域名局部
  • 端口局部：跟在域名前面的是端口，域名和端口之间应用“:”作为分隔符。端口不是一个URL必须的局部，如果省略端口局部，将采纳默认端口（HTTP协定默认端口是80，HTTPS协定默认端口是443）；
  • 虚拟目录局部：从域名后的第一个“/”开始到最初一个“/”为止，是虚拟目录局部。虚拟目录也不是一个URL必须的局部。本例中的虚拟目录是“/news/”；
  • 文件名局部：从域名后的最初一个“/”开始到“？”为止，是文件名局部，如果没有“?”,则是从域名后的最初一个“/”开始到“#”为止，是文件局部，如果没有“？”和“#”，那么从域名后的最初一个“/”开始到完结，都是文件名局部。本例中的文件名是“index.asp”。文件名局部也不是一个URL必须的局部，如果省略该局部，则应用默认的文件名；
  • 锚局部：从“#”开始到最初，都是锚局部。本例中的锚局部是“name”。锚局部也不是一个URL必须的局部；
  • 参数局部：从“？”开始到“#”为止之间的局部为参数局部，又称搜寻局部、查问局部。本例中的参数局部为“boardID=5&ID=24618&page=1”。参数能够容许有多个参数，参数与参数之间用“&”作为分隔符。