关于react.js:年前端react面试打怪升级之路

react 和 vue 的区别

相同点：

1. 数据驱动页面，提供响应式的试图组件
2. 都有 virtual DOM, 组件化的开发，通过 props 参数进行父子之间组件传递数据，都实现了 webComponents 标准
3. 数据流动单向，都反对服务器的渲染 SSR
4. 都有反对 native 的办法，react 有 React native，vue 有 wexx

不同点：

1. 数据绑定：Vue 实现了双向的数据绑定，react 数据流动是单向的
2. 数据渲染：大规模的数据渲染，react 更快
3. 应用场景：React 配合 Redux 架构适宜大规模多人合作简单我的项目，Vue 适宜小快的我的项目
4. 开发格调：react 举荐做法 jsx + inline style 把 html 和 css 都写在 js 了

vue 是采纳 webpack +vue-loader 单文件组件格局，html, js, css 同一个文件

对有状态组件和无状态组件的了解及应用场景

（1）有状态组件

特点：

• 是类组件
• 有继承
• 能够应用 this
• 能够应用 react 的生命周期
• 应用较多，容易频繁触发生命周期钩子函数，影响性能
• 外部应用 state，保护本身状态的变动，有状态组件依据内部组件传入的 props 和本身的 state 进行渲染。

应用场景：

• 须要应用到状态的。
• 须要应用状态操作组件的（无状态组件的也能够实现新版本 react hooks 也可实现）

总结： 类组件能够保护本身的状态变量，即组件的 state，类组件还有不同的生命周期办法，能够让开发者可能在组件的不同阶段（挂载、更新、卸载），对组件做更多的管制。类组件则既能够充当无状态组件，也能够充当有状态组件。当一个类组件不须要治理本身状态时，也可称为无状态组件。

（2）无状态组件 特点：

• 不依赖本身的状态 state
• 能够是类组件或者函数组件。
• 能够完全避免应用 this 关键字。（因为应用的是箭头函数事件无需绑定）
• 有更高的性能。当不须要应用生命周期钩子时，应该首先应用无状态函数组件
• 组件外部不保护 state，只依据内部组件传入的 props 进行渲染的组件，当 props 扭转时，组件从新渲染。

应用场景：

• 组件不须要治理 state，纯展现

长处：

• 简化代码、专一于 render
• 组件不须要被实例化，无生命周期，晋升性能。输入（渲染）只取决于输出（属性），无副作用
• 视图和数据的解耦拆散

毛病：

• 无奈应用 ref
• 无生命周期办法
• 无法控制组件的重渲染，因为无奈应用 shouldComponentUpdate 办法，当组件承受到新的属性时则会重渲染

总结： 组件外部状态且与内部无关的组件，能够思考用状态组件，这样状态树就不会过于简单，易于了解和治理。当一个组件不须要治理本身状态时，也就是无状态组件，应该优先设计为函数组件。比方自定义的 <Button/>、<Input /> 等组件。

对 Redux 的了解，次要解决什么问题

React 是视图层框架。Redux 是一个用来治理数据状态和 UI 状态的 JavaScript 利用工具。随着 JavaScript 单页利用（SPA）开发日趋简单，JavaScript 须要治理比任何时候都要多的 state（状态），Redux 就是升高治理难度的。（Redux 反对 React、Angular、jQuery 甚至纯 JavaScript）。

在 React 中，UI 以组件的模式来搭建，组件之间能够嵌套组合。但 React 中组件间通信的数据流是单向的，顶层组件能够通过 props 属性向上层组件传递数据，而上层组件不能向下层组件传递数据，兄弟组件之间同样不能。这样简略的单向数据流撑持起了 React 中的数据可控性。

当我的项目越来越大的时候，治理数据的事件或回调函数将越来越多，也将越来越不好治理。治理一直变动的 state 十分艰难。如果一个 model 的变动会引起另一个 model 变动，那么当 view 变动时，就可能引起对应 model 以及另一个 model 的变动，顺次地，可能会引起另一个 view 的变动。直至你搞不清楚到底产生了什么。state 在什么时候，因为什么起因，如何变动未然不受管制。当零碎变得盘根错节的时候，想重现问题或者增加新性能就会变得举步维艰。如果这还不够蹩脚，思考一些来自前端开发畛域的新需要，如更新调优、服务端渲染、路由跳转前申请数据等。state 的治理在大我的项目中相当简单。

Redux 提供了一个叫 store 的对立仓储库，组件通过 dispatch 将 state 间接传入 store，不必通过其余的组件。并且组件通过 subscribe 从 store 获取到 state 的扭转。应用了 Redux，所有的组件都能够从 store 中获取到所需的 state，他们也能从 store 获取到 state 的扭转。这比组件之间相互传递数据清晰清朗的多。

次要解决的问题： 单纯的 Redux 只是一个状态机，是没有 UI 出现的，react- redux 作用是将 Redux 的状态机和 React 的 UI 出现绑定在一起，当你 dispatch action 扭转 state 的时候，会自动更新页面。

如何解决 props 层级过深的问题

• 应用 Context API：提供一种组件之间的状态共享，而不用通过显式组件树逐层传递 props；
• 应用 Redux 等状态库。

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

React 中什么是受控组件和非控组件？

（1）受控组件 在应用表单来收集用户输出时，例如<input><select><textearea> 等元素都要绑定一个 change 事件，当表单的状态发生变化，就会触发 onChange 事件，更新组件的 state。这种组件在 React 中被称为 受控组件，在受控组件中，组件渲染出的状态与它的 value 或 checked 属性绝对应，react 通过这种形式打消了组件的部分状态，使整个状态可控。react 官网举荐应用受控表单组件。

受控组件更新 state 的流程：

• 能够通过初始 state 中设置表单的默认值
• 每当表单的值发生变化时，调用 onChange 事件处理器
• 事件处理器通过事件对象 e 拿到扭转后的状态，并更新组件的 state
• 一旦通过 setState 办法更新 state，就会触发视图的从新渲染，实现表单组件的更新

受控组件缺点： 表单元素的值都是由 React 组件进行治理，当有多个输入框，或者多个这种组件时，如果想同时获取到全副的值就必须每个都要编写事件处理函数，这会让代码看着很臃肿，所以为了解决这种状况，呈现了非受控组件。

（2）非受控组件 如果一个表单组件没有 value props（单选和复选按钮对应的是 checked props）时，就能够称为非受控组件。在非受控组件中，能够应用一个 ref 来从 DOM 取得表单值。而不是为每个状态更新编写一个事件处理程序。

React 官网的解释：

要编写一个非受控组件，而不是为每个状态更新都编写数据处理函数，你能够应用 ref 来从 DOM 节点中获取表单数据。
因为非受控组件将实在数据贮存在 DOM 节点中，所以在应用非受控组件时，有时候反而更容易同时集成 React 和非 React 代码。如果你不介意代码好看性，并且心愿疾速编写代码，应用非受控组件往往能够缩小你的代码量。否则，你应该应用受控组件。

例如，上面的代码在非受控组件中接管单个属性：

class NameForm extends React.Component {constructor(props) {super(props);
    this.handleSubmit = this.handleSubmit.bind(this);
  }
  handleSubmit(event) {alert('A name was submitted:' + this.input.value);
    event.preventDefault();}
  render() {
    return (<form onSubmit={this.handleSubmit}>
        <label>
          Name:          <input type="text" ref={(input) => this.input = input} />        </label>
        <input type="submit" value="Submit" />
      </form>
    );
  }
}

总结： 页面中所有输出类的 DOM 如果是现用现取的称为非受控组件，而通过 setState 将输出的值保护到了 state 中，须要时再从 state 中取出，这里的数据就受到了 state 的管制，称为受控组件。

React 中有应用过 getDefaultProps 吗？它有什么作用？

通过实现组件的 getDefaultProps，对属性设置默认值（ES5 的写法）：

var ShowTitle = React.createClass({getDefaultProps:function(){
    return{title : "React"}
  },
  render : function(){return <h1>{this.props.title}</h1>
  }
});

React 如何获取组件对应的 DOM 元素？

能够用 ref 来获取某个子节点的实例，而后通过以后 class 组件实例的一些特定属性来间接获取子节点实例。ref 有三种实现办法:

• 字符串格局：字符串格局，这是 React16 版本之前用得最多的，例如：<p ref="info">span</p>
• 函数格局：ref 对应一个办法，该办法有一个参数，也就是对应的节点实例，例如：<p ref={ele => this.info = ele}></p>
• createRef 办法 ：React 16 提供的一个 API，应用 React.createRef() 来实现

React Hook 的应用限度有哪些？

React Hooks 的限度次要有两条：

• 不要在循环、条件或嵌套函数中调用 Hook；
• 在 React 的函数组件中调用 Hook。

那为什么会有这样的限度呢？Hooks 的设计初衷是为了改良 React 组件的开发模式。在旧有的开发模式下遇到了三个问题。

• 组件之间难以复用状态逻辑。过来常见的解决方案是高阶组件、render props 及状态治理框架。
• 简单的组件变得难以了解。生命周期函数与业务逻辑耦合太深，导致关联局部难以拆分。
• 人和机器都很容易混同类。常见的有 this 的问题，但在 React 团队中还有类难以优化的问题，心愿在编译优化层面做出一些改良。

这三个问题在肯定水平上妨碍了 React 的后续倒退，所以为了解决这三个问题，Hooks 基于函数组件 开始设计。然而第三个问题决定了 Hooks 只反对函数组件。

那为什么不要在循环、条件或嵌套函数中调用 Hook 呢？因为 Hooks 的设计是基于数组实现。在调用时按程序退出数组中，如果应用循环、条件或嵌套函数很有可能导致数组取值错位，执行谬误的 Hook。当然，本质上 React 的源码里不是数组，是链表。

这些限度会在编码上造成肯定水平的心智累赘，老手可能会写错，为了防止这样的状况，能够引入 ESLint 的 Hooks 查看插件进行预防。

React 中的 setState 和 replaceState 的区别是什么？

（1）setState() setState()用于设置状态对象，其语法如下：

setState(object nextState[, function callback])

• nextState，将要设置的新状态，该状态会和以后的 state 合并
• callback，可选参数，回调函数。该函数会在 setState 设置胜利，且组件从新渲染后调用。

合并 nextState 和以后 state，并从新渲染组件。setState 是 React 事件处理函数中和申请回调函数中触发 UI 更新的次要办法。

（2）replaceState() replaceState()办法与 setState()相似，然而办法只会保留 nextState 中状态，原 state 不在 nextState 中的状态都会被删除。其语法如下：

replaceState(object nextState[, function callback])

• nextState，将要设置的新状态，该状态会替换以后的 state。
• callback，可选参数，回调函数。该函数会在 replaceState 设置胜利，且组件从新渲染后调用。

总结： setState 是批改其中的局部状态，相当于 Object.assign，只是笼罩，不会缩小原来的状态。而 replaceState 是齐全替换原来的状态，相当于赋值，将原来的 state 替换为另一个对象，如果新状态属性缩小，那么 state 中就没有这个状态了。

React 废除了哪些生命周期？为什么？

被废除的三个函数都是在 render 之前，因为 fber 的呈现，很可能因为高优先级工作的呈现而打断现有工作导致它们会被执行屡次。另外的一个起因则是，React 想束缚使用者，好的框架可能让人不得已写出容易保护和扩大的代码，这一点又是从何谈起，能够从新减少以及行将废除的生命周期剖析动手

1) componentWillMount

首先这个函数的性能齐全能够应用 componentDidMount 和 constructor 来代替，异步获取的数据的状况下面曾经阐明了，而如果抛去异步获取数据，其余的即是初始化而已，这些性能都能够在 constructor 中执行，除此之外，如果在 willMount 中订阅事件，但在服务端这并不会执行 willUnMount 事件，也就是说服务端会导致内存透露所以 componentWilIMount 齐全能够不应用，但使用者有时候不免因为各 种各样的状况在 componentWilMount 中做一些操作，那么 React 为了束缚开发者，罗唆就抛掉了这个 API

2) componentWillReceiveProps

在老版本的 React 中，如果组件本身的某个 state 跟其 props 密切相关的话，始终都没有一种很优雅的解决形式去更新 state，而是须要在 componentWilReceiveProps 中判断前后两个 props 是否雷同，如果不同再将新的 props 更新到相应的 state 下来。这样做一来会毁坏 state 数据的繁多数据源，导致组件状态变得不可预测，另一方面也会减少组件的重绘次数。相似的业务需要也有很多，如一个能够横向滑动的列表，以后高亮的 Tab 显然隶属于列表本身的时，依据传入的某个值，间接定位到某个 Tab。为了解决这些问题，React 引入了第一个新的生命周期：getDerivedStateFromProps。它有以下的长处∶

• getDSFP 是静态方法，在这里不能应用 this，也就是一个纯函数，开发者不能写出副作用的代码
• 开发者只能通过 prevState 而不是 prevProps 来做比照，保障了 state 和 props 之间的简略关系以及不须要解决第一次渲染时 prevProps 为空的状况
• 基于第一点，将状态变动（setState）和低廉操作（tabChange）辨别开，更加便于 render 和 commit 阶段操作或者说优化。

3) componentWillUpdate

与 componentWillReceiveProps 相似，许多开发者也会在 componentWillUpdate 中依据 props 的变动去触发一些回调。但不论是 componentWilReceiveProps 还 是 componentWilUpdate，都有可能在一次更新中被调用屡次，也就是说写在这里的回调函数也有可能会被调用屡次，这显然是不可取的。与 componentDidMount 类 似，componentDidUpdate 也不存在这样的问题，一次更新中 componentDidUpdate 只会被调用一次，所以将原先写在 componentWillUpdate 中 的 回 调 迁 移 至 componentDidUpdate 就能够解决这个问题。

另外一种状况则是须要获取 DOM 元素状态，然而因为在 fber 中，render 可打断，可能在 wilMount 中获取到的元素状态很可能与理论须要的不同，这个通常能够应用第二个新增的生命函数的解决 getSnapshotBeforeUpdate(prevProps, prevState)

4) getSnapshotBeforeUpdate(prevProps, prevState)

返回的值作为 componentDidUpdate 的第三个参数。与 willMount 不同的是，getSnapshotBeforeUpdate 会在最终确定的 render 执行之前执行，也就是能保障其获取到的元素状态与 didUpdate 中获取到的元素状态雷同。官网参考代码：

class ScrollingList extends React.Component {constructor(props) {super(props);
    this.listRef = React.createRef();}

  getSnapshotBeforeUpdate(prevProps, prevState) {
    // 咱们是否在 list 中增加新的 items？// 捕捉滚动​​地位以便咱们稍后调整滚动地位。if (prevProps.list.length < this.props.list.length) {
      const list = this.listRef.current;
      return list.scrollHeight - list.scrollTop;
    }
    return null;
  }

  componentDidUpdate(prevProps, prevState, snapshot) {
    // 如果咱们 snapshot 有值，阐明咱们刚刚增加了新的 items，// 调整滚动地位使得这些新 items 不会将旧的 items 推出视图。//（这里的 snapshot 是 getSnapshotBeforeUpdate 的返回值）if (snapshot !== null) {
      const list = this.listRef.current;
      list.scrollTop = list.scrollHeight - snapshot;
    }
  }

  render() {
    return (<div ref={this.listRef}>{/* ...contents... */}</div>
    );
  }
}

Redux 中的 connect 有什么作用

connect 负责连贯 React 和 Redux

（1）获取 state

connect 通过 context 获取 Provider 中的 store，通过 store.getState() 获取整个 store tree 上所有 state

（2）包装原组件

将 state 和 action 通过 props 的形式传入到原组件外部 wrapWithConnect 返回—个 ReactComponent 对 象 Connect，Connect 重 新 render 内部传入的原组件 WrappedComponent，并把 connect 中传入的 mapStateToProps，mapDispatchToProps 与组件上原有的 props 合并后，通过属性的形式传给 WrappedComponent

（3）监听 store tree 变动

connect 缓存了 store tree 中 state 的状态，通过以后 state 状态 和变更前 state 状态进行比拟，从而确定是否调用 this.setState()办法触发 Connect 及其子组件的从新渲染

React 组件的构造函数有什么作用？它是必须的吗？

构造函数次要用于两个目标：

• 通过将对象调配给 this.state 来初始化本地状态
• 将事件处理程序办法绑定到实例上

所以，当在 React class 中须要设置 state 的初始值或者绑定事件时，须要加上构造函数，官网 Demo：

class LikeButton extends React.Component {constructor() {super();
    this.state = {liked: false};
    this.handleClick = this.handleClick.bind(this);
  }
  handleClick() {this.setState({liked: !this.state.liked});
  }
  render() {
    const text = this.state.liked ? 'liked' : 'haven\'t liked';
    return (<div onClick={this.handleClick}>
        You {text} this. Click to toggle.      </div>
    );
  }
}
ReactDOM.render(
  <LikeButton />,
  document.getElementById('example')
);

构造函数用来新建父类的 this 对象；子类必须在 constructor 办法中调用 super 办法；否则新建实例时会报错；因为子类没有本人的 this 对象，而是继承父类的 this 对象，而后对其进行加工。如果不调用 super 办法；子类就得不到 this 对象。

留神：

• constructor () 必须配上 super(), 如果要在 constructor 外部应用 this.props 就要 传入 props , 否则不必
• JavaScript 中的 bind 每次都会返回一个新的函数, 为了性能等思考, 尽量在 constructor 中绑定事件

对 React Hook 的了解，它的实现原理是什么

React-Hooks 是 React 团队在 React 组件开发实际中，逐步认知到的一个改良点，这背地其实波及对 类组件 和函数组件 两种组件模式的思考和偏重。

（1）类组件： 所谓类组件，就是基于 ES6 Class 这种写法，通过继承 React.Component 得来的 React 组件。以下是一个类组件：

class DemoClass extends React.Component {
  state = {text: ""};
  componentDidMount() {//...}
  changeText = (newText) => {
    this.setState({text: newText});
  };

  render() {
    return (
      <div className="demoClass">
        <p>{this.state.text}</p>
        <button onClick={this.changeText}> 批改 </button>
      </div>
    );
  }
}

能够看出，React 类组件外部预置了相当多的“现成的货色”等着咱们去调度 / 定制，state 和生命周期就是这些“现成货色”中的典型。要想得到这些货色，难度也不大，只须要继承一个 React.Component 即可。

当然，这也是类组件的一个不便，它太繁冗了，对于解决许多问题来说，编写一个类组件切实是一个过于简单的姿态。简单的姿态必然带来昂扬的了解老本，这也是咱们所不想看到的。除此之外，因为开发者编写的逻辑在封装后是和组件粘在一起的，这就使得 类组件外部的逻辑难以实现拆分和复用。

（2）函数组件：函数组件就是以函数的状态存在的 React 组件。晚期并没有 React-Hooks，函数组件外部无奈定义和保护 state，因而它还有一个别名叫“无状态组件”。以下是一个函数组件：

function DemoFunction(props) {const { text} = props
  return (
    <div className="demoFunction">
      <p>{` 函数组件接管的内容：[${text}]`}</p>
    </div>
  );
}

相比于类组件，函数组件肉眼可见的特质天然包含轻量、灵便、易于组织和保护、较低的学习老本等。

通过比照，从状态上能够对两种组件做辨别，它们之间的区别如下：

• 类组件须要继承 class，函数组件不须要；
• 类组件能够拜访生命周期办法，函数组件不能；
• 类组件中能够获取到实例化后的 this，并基于这个 this 做各种各样的事件，而函数组件不能够；
• 类组件中能够定义并保护 state（状态），而函数组件不能够；

除此之外，还有一些其余的不同。通过下面的区别，咱们不能说谁好谁坏，它们各有本人的劣势。在 React-Hooks 呈现之前，类组件的能力边界显著强于函数组件。

实际上，类组件和函数组件之间，是面向对象和函数式编程这两套不同的设计思维之间的差别。而函数组件更加符合 React 框架的设计理念：React 组件自身的定位就是函数，一个输出数据、输入 UI 的函数。作为开发者，咱们编写的是申明式的代码，而 React 框架的次要工作，就是及时地把申明式的代码转换为命令式的 DOM 操作，把数据层面的形容映射到用户可见的 UI 变动中去。这就意味着从原则上来讲，React 的数据应该总是紧紧地和渲染绑定在一起的，而类组件做不到这一点。函数组件就真正地将数据和渲染绑定到了一起。函数组件是一个更加匹配其设计理念、也更有利于逻辑拆分与重用的组件表达形式。

为了能让开发者更好的的去编写函数式组件。于是，React-Hooks 便应运而生。

React-Hooks 是一套可能使函数组件更弱小、更灵便的“钩子”。

函数组件比起类组件少了很多货色，比方生命周期、对 state 的治理等。这就给函数组件的应用带来了十分多的局限性，导致咱们并不能应用函数这种模式，写出一个真正的全功能的组件。而 React-Hooks 的呈现，就是为了帮忙函数组件补齐这些（绝对于类组件来说）缺失的能力。

如果说函数组件是一台笨重的快艇，那么 React-Hooks 就是一个内容丰盛的零部件箱。“重装战舰”所预置的那些设施，这个箱子里根本全都有，同时它还不强制你全都要，而是容许你自在地抉择和应用你须要的那些能力，而后将这些能力以 Hook（钩子）的模式“钩”进你的组件里，从而定制出一个最适宜你的“专属战舰”。

diff 算法如何比拟?

• 只对同级比拟，跨层级的 dom 不会进行复用
• 不同类型节点生成的 dom 树不同，此时会间接销毁老节点及子孙节点，并新建节点
• 能够通过 key 来对元素 diff 的过程提供复用的线索
• 单节点 diff
• 单点 diff 有如下几种状况：
• key 和 type 雷同示意能够复用节点
• key 不同间接标记删除节点，而后新建节点
• key 雷同 type 不同，标记删除该节点和兄弟节点，而后新创建节点

类组件 (Class component) 和函数式组件 (Functional component) 之间有何不同

• 类组件不仅容许你应用更多额定的性能，如组件本身的状态和生命周期钩子，也能使组件间接拜访 store 并维持状态
• 当组件仅是接管 props，并将组件本身渲染到页面时，该组件就是一个 ‘ 无状态组件 (stateless component)’，能够应用一个纯函数来创立这样的组件。这种组件也被称为哑组件(dumb components) 或展现组件

React 的严格模式如何应用，有什么用途？

StrictMode 是一个用来突出显示应用程序中潜在问题的工具。与 Fragment 一样，StrictMode 不会渲染任何可见的 UI。它为其后辈元素触发额定的检查和正告。
能够为应用程序的任何局部启用严格模式。例如：

import React from 'react';
function ExampleApplication() {
  return (
    <div>
      <Header />
      <React.StrictMode>        
        <div>
          <ComponentOne />
          <ComponentTwo />
        </div>
      </React.StrictMode>      
      <Footer />
    </div>
  );
}

在上述的示例中，不会对 Header 和 Footer 组件运行严格模式查看。然而，ComponentOne 和 ComponentTwo 以及它们的所有后辈元素都将进行查看。

StrictMode 目前有助于：

• 辨认不平安的生命周期
• 对于应用过期字符串 ref API 的正告
• 对于应用废除的 findDOMNode 办法的正告
• 检测意外的副作用
• 检测过期的 context API

何为 Children

在 JSX 表达式中，一个开始标签 (比方<a>) 和一个敞开标签 (比方</a>) 之间的内容会作为一个非凡的属性 props.children 被主动传递给蕴含着它的组件。

这个属性有许多可用的办法，包含 React.Children.map，React.Children.forEach，React.Children.count，React.Children.only，React.Children.toArray。

setState 是同步异步？为什么？实现原理？

1. setState 是同步执行的

setState 是同步执行的，然而 state 并不一定会同步更新

2. setState 在 React 生命周期和合成事件中批量笼罩执行

在 React 的生命周期钩子和合成事件中，屡次执行 setState，会批量执行

具体表现为，屡次同步执行的 setState，会进行合并，相似于 Object.assign，雷同的 key，前面的会笼罩后面的

当遇到多个 setState 调用时候，会提取单次传递 setState 的对象，把他们合并在一起造成一个新的
繁多对象，并用这个繁多的对象去做 setState 的事件，就像 Object.assign 的对象合并，后一个
key 值会笼罩后面的 key 值

通过 React 解决的事件是不会同步更新 this.state 的. 通过 addEventListener || setTimeout/setInterval 的形式解决的则会同步更新。
为了合并 setState，咱们须要一个队列来保留每次 setState 的数据，而后在一段时间后执行合并操作和更新 state，并清空这个队列，而后渲染组件。

Redux 中间件是怎么拿到 store 和 action? 而后怎么解决?

redux 中间件实质就是一个函数柯里化。redux applyMiddleware Api 源码中每个 middleware 承受 2 个参数，Store 的 getState 函数和 dispatch 函数，别离取得 store 和 action，最终返回一个函数。该函数会被传入 next 的下一个 middleware 的 dispatch 办法，并返回一个接管 action 的新函数，这个函数能够间接调用 next（action），或者在其余须要的时刻调用，甚至基本不去调用它。调用链中最初一个 middleware 会承受实在的 store 的 dispatch 办法作为 next 参数，并借此完结调用链。所以，middleware 的函数签名是（{getState，dispatch})=> next => action。

在 Redux 中，何为 store

Store 是一个 javascript 对象，它保留了整个利用的 state。与此同时，Store 也承当以下职责：

• 容许通过 getState() 拜访 state
• 运行通过 dispatch(action) 扭转 state
• 通过 subscribe(listener) 注册 listeners
• 通过 subscribe(listener) 返回的函数解决 listeners 的登记