前端面试宝典六（react篇）

1、生命周期的理解

初始化阶段：

getDefaultProps:获取实例的默认属性
getInitialState:获取每个实例的初始化状态
componentWillMount：组件即将被装载、渲染到页面上
render:组件在这里生成虚拟的 DOM 节点
componentDidMount:组件真正在被装载之后
运行中状态：

componentWillReceiveProps:组件将要接收到属性的时候调用
shouldComponentUpdate:组件接受到新属性或者新状态的时候（可以返回 false，接收数据后不更新，阻止 render 调用，后面的函数不会被继续执行了）
componentWillUpdate:组件即将更新不能修改属性和状态
render:组件重新描绘
componentDidUpdate:组件已经更新
销毁阶段：

componentWillUnmount:组件即将销毁

2、创建组件的方法

• 函数声明
• class声明组件 

3、函数组件和类组件的区别

两种创建组件方式的对比
使用class创建的组件，有自己的私有数据（this.state）和生命周期
使用function创建的组件，只有props，没有自己的私有数据和生命周期函数。
用构造函数创建的组件叫无状态组件，用class创建的组件叫有状态组件
组件中的props和state/data之间的区别

props的数据都是从外界传递过来的
state/data中的数据，都是组件私有的；（通过ajax获取的数据一般都是私有数据）
props中的数据都是只读的，不能重新赋值的。
state/data中的数据，都是可读可写的。
使用范围
如果一个组件有自己的私有数据，则推荐使用class创建有状态组件；
如果一个组件不需要私有的数据，则推荐使用，无状态组件。

有状态组件和无状态组件的本质区别就是：是否有state属性和是否有生命周期函数。

4、列举组件通信的方法

1）父组件向子组件通信
React数据流动是单向的,父组件向子组件通信也是最常见的;父组件通过props向子组件传递需要的信息
Child.jsx

2）子组件向父组件通信

• 利用回调函数
• 利用自定义事件机制

回调函数
实现在子组件中点击隐藏组件按钮可以将自身隐藏的功能
3）跨级组件通信

层层组件传递props

例如A组件和B组件之间要进行通信,先找到A和B公共的父组件,A先向C组件通信,C组件通过props和B组件通信,此时C组件起的就是中间件的作用

使用context

context是一个全局变量,像是一个大容器,在任何地方都可以访问到,我们可以把要通信的信息放在context上,然后在其他组件中可以随意取到;
但是React官方不建议使用大量context,尽管他可以减少逐层传递,但是当组件结构复杂的时候,我们并不知道context是从哪里传过来的;而且context是一个全局变量,全局变量正是导致应用走向混乱的罪魁祸首

4）没有嵌套关系的组件通信

使用自定义事件机制

在componentDidMount事件中,如果组件挂载完成,再订阅事件;在组件卸载的时候,在componentWillUnmount事件中取消事件的订阅;
以常用的发布/订阅模式举例,借用Node.js Events模块的浏览器版实现

总结

• 父组件向子组件通信: props
• 子组件向父组件通信: 回调函数/自定义事件
• 跨级组件通信: 层层组件传递props/context
• 没有嵌套关系组件之间的通信: 自定义事件

5、state和prop的区别

props
主要是用于组件之间传递参数，获取组件的属性值。 组件之间数据单向流动 ，从父组件流向子组件。
对于外界/父组件的属性值，无法直接修改，它是只读的。

state
主要用于组件更新控制，如果想重新渲染或更新组件，只需要修改state即可，然后根据具体修改的state,
重新渲染用户界面（无需操作DOM对象）；
本组件内的数据   相对封闭的单元/结构的数据

6、受控组件和非受控组件

受控组件

1）每当表单的状态发生变化时，都会被写入到组件的state中

2）在受控组件中，组件渲染出的状态与它的value或checked prop相对应

3）react受控组件更新state的流程

• • 通过在初始state中设置表单的默认值
  • 每当表单的值发生变化时，调用onChange事件处理器
  • 事件处理器通过合成对象e拿到改变后的状态，并更新应用的state
  • SetState触发视图的重新渲染，完成表单组件值的更新

4）使用受控组件需要为每一个组件绑定一个change事件,并且定义一个事件处理器来同步表单值和组件的状态,某些情况可以使用一个事件处理器来处理多个表单域

5）在受控组件上指定 value 的 prop 可以防止用户更改输入。(如果指定了 value，但输入仍可编辑，则可能是意外地将value 设置为 undefined 或 null)

非受控组件

1）如果一个表单组件没有value prop就可以称为非受控组件
2）非受控组件是一种反模式，它的值不受组件自身的state或props控制
3）通常需要为其添加ref prop来访问渲染后的底层DOM元素

7、refs的作用及应用场景

Refs 是 React 提供给我们的安全访问 DOM 元素或者某个组件实例的句柄。

我们可以为元素添加 ref 属性然后在回调函数中接受该元素在 DOM 树中的句柄，该值会作为回调函数的第一个参数返回

8、组件key的作用

Key 是 React 用于追踪哪些列表中元素被修改、被添加或者被移除的辅助标识。
在开发过程中，我们需要保证某个元素的 key 在其同级元素中具有唯一性。在 React Diff 算法中 React 会借助元素的 Key 值来判断该元素是新近创建的还是被移动而来的元素，从而减少不必要的元素重渲染。此外，React 还需要借助 Key 值来判断元素与本地状态的关联关系

9、高阶组件

高阶组件是一个以组件为参数并返回一个新组件的函数。HOC 运行你重用代码、逻辑和引导抽象。最常见的可能是 Redux 的 connect 函数。除了简单分享工具库和简单的组合，HOC 最好的方式是共享 React 组件之间的行为。如果你发现你在不同的地方写了大量代码来做同一件事时，就应该考虑将代码重构为可重用的 HOC

10、对setState同步异步的理解，在setState之后如何保证拿到最新的值

由React控制的事件处理程序，以及生命周期函数调用setState不会同步更新state 。
React控制之外的事件中调用setState是同步更新的。比如原生js绑定的事件，setTimeout/setInterval等。
大部分开发中用到的都是React封装的事件，比如onChange、onClick、onTouchMove等，这些事件处理程序中的setState都是异步处理的
在 React 的 setState 函数实现中，会根据一个变量 isBatchingUpdates 判断是直接更新 this.state 还是放到队列中延时更新，而 isBatchingUpdates 默认是 false，表示 setState 会同步更新 this.state；但是，有一个函数 batchedUpdates，该函数会把 isBatchingUpdates 修改为 true，而当 React 在调用事件处理函数之前就会先调用这个 batchedUpdates将isBatchingUpdates修改为true，这样由 React 控制的事件处理过程 setState 不会同步更新 this.state。可通过setState的第二个参数获取最新的state

11、虚拟dom的理解

1） 原生 DOM 操作 vs. 通过框架封装操作。
这是一个性能 vs. 可维护性的取舍。框架的意义在于为你掩盖底层的 DOM 操作，让你用更声明式的方式来描述你的目的，从而让你的代码更容易维护。没有任何框架可以比纯手动的优化 DOM 操作更快，因为框架的 DOM 操作层需要应对任何上层 API 可能产生的操作，它的实现必须是普适的。针对任何一个 benchmark，我都可以写出比任何框架更快的手动优化，但是那有什么意义呢？在构建一个实际应用的时候，你难道为每一个地方都去做手动优化吗？出于可维护性的考虑，这显然不可能。框架给你的保证是，你在不需要手动优化的情况下，我依然可以给你提供过得去的性能。
2）对 React 的 Virtual DOM 的误解。
React 从来没有说过 “React 比原生操作 DOM 快”。React 的基本思维模式是每次有变动就整个重新渲染整个应用。如果没有 Virtual DOM，简单来想就是直接重置 innerHTML。很多人都没有意识到，在一个大型列表所有数据都变了的情况下，重置 innerHTML 其实是一个还算合理的操作... 真正的问题是在 “全部重新渲染” 的思维模式下，即使只有一行数据变了，它也需要重置整个 innerHTML，这时候显然就有大量的浪费。
我们可以比较一下 innerHTML vs. Virtual DOM 的重绘性能消耗：

• innerHTML: render html string O(template size) + 重新创建所有 DOM 元素 O(DOM size)
• Virtual DOM: render Virtual DOM + diff O(template size) + 必要的 DOM 更新 O(DOM change)

Virtual DOM render + diff 显然比渲染 html 字符串要慢，但是！它依然是纯 js 层面的计算，比起后面的 DOM 操作来说，依然便宜了太多。可以看到，innerHTML 的总计算量不管是 js 计算还是 DOM 操作都是和整个界面的大小相关，但 Virtual DOM 的计算量里面，只有 js 计算和界面大小相关，DOM 操作是和数据的变动量相关的。前面说了，和 DOM 操作比起来，js 计算是极其便宜的。这才是为什么要有 Virtual DOM：它保证了 1）不管你的数据变化多少，每次重绘的性能都可以接受；2) 你依然可以用类似 innerHTML 的思路去写你的应用。
3）MVVM vs. Virtual DOM
相比起 React，其他 MVVM 系框架比如 Angular, Knockout 以及 Vue、Avalon 采用的都是数据绑定：通过 Directive/Binding 对象，观察数据变化并保留对实际 DOM 元素的引用，当有数据变化时进行对应的操作。MVVM 的变化检查是数据层面的，而 React 的检查是 DOM 结构层面的。MVVM 的性能也根据变动检测的实现原理有所不同：Angular 的脏检查使得任何变动都有固定的 O(watcher count) 的代价；Knockout/Vue/Avalon 都采用了依赖收集，在 js 和 DOM 层面都是 O(change)：

• 脏检查：scope digest O(watcher count) + 必要 DOM 更新 O(DOM change)
• 依赖收集：重新收集依赖 O(data change) + 必要 DOM 更新 O(DOM change)

可以看到，Angular 最不效率的地方在于任何小变动都有的和 watcher 数量相关的性能代价。但是！当所有数据都变了的时候，Angular 其实并不吃亏。依赖收集在初始化和数据变化的时候都需要重新收集依赖，这个代价在小量更新的时候几乎可以忽略，但在数据量庞大的时候也会产生一定的消耗。
MVVM 渲染列表的时候，由于每一行都有自己的数据作用域，所以通常都是每一行有一个对应的 ViewModel 实例，或者是一个稍微轻量一些的利用原型继承的 "scope" 对象，但也有一定的代价。所以，MVVM 列表渲染的初始化几乎一定比 React 慢，因为创建 ViewModel / scope 实例比起 Virtual DOM 来说要昂贵很多。这里所有 MVVM 实现的一个共同问题就是在列表渲染的数据源变动时，尤其是当数据是全新的对象时，如何有效地复用已经创建的 ViewModel 实例和 DOM 元素。假如没有任何复用方面的优化，由于数据是 “全新” 的，MVVM 实际上需要销毁之前的所有实例，重新创建所有实例，最后再进行一次渲染！这就是为什么题目里链接的 angular/knockout 实现都相对比较慢。相比之下，React 的变动检查由于是 DOM 结构层面的，即使是全新的数据，只要最后渲染结果没变，那么就不需要做无用功。
Angular 和 Vue 都提供了列表重绘的优化机制，也就是 “提示” 框架如何有效地复用实例和 DOM 元素。比如数据库里的同一个对象，在两次前端 API 调用里面会成为不同的对象，但是它们依然有一样的 uid。这时候你就可以提示 track by uid 来让 Angular 知道，这两个对象其实是同一份数据。那么原来这份数据对应的实例和 DOM 元素都可以复用，只需要更新变动了的部分。或者，你也可以直接 track by $index 来进行 “原地复用”：直接根据在数组里的位置进行复用。在题目给出的例子里，如果 angular 实现加上 track by $index 的话，后续重绘是不会比 React 慢多少的。甚至在 dbmonster 测试中，Angular 和 Vue 用了 track by $index 以后都比 React 快: dbmon (注意 Angular 默认版本无优化，优化过的在下面）
顺道说一句，React 渲染列表的时候也需要提供 key 这个特殊 prop，本质上和 track-by 是一回事。
4）性能比较也要看场合
在比较性能的时候，要分清楚初始渲染、小量数据更新、大量数据更新这些不同的场合。Virtual DOM、脏检查 MVVM、数据收集 MVVM 在不同场合各有不同的表现和不同的优化需求。Virtual DOM 为了提升小量数据更新时的性能，也需要针对性的优化，比如 shouldComponentUpdate 或是 immutable data。

• 初始渲染：Virtual DOM > 脏检查 >= 依赖收集
• 小量数据更新：依赖收集 >> Virtual DOM + 优化 > 脏检查（无法优化） > Virtual DOM 无优化
• 大量数据更新：脏检查 + 优化 >= 依赖收集 + 优化 > Virtual DOM（无法/无需优化）>> MVVM 无优化

不要天真地以为 Virtual DOM 就是快，diff 不是免费的，batching 么 MVVM 也能做，而且最终 patch 的时候还不是要用原生 API。在我看来 Virtual DOM 真正的价值从来都不是性能，而是它：

• 为函数式的 UI 编程方式打开了大门；
• 可以渲染到 DOM 以外的 backend，比如 ReactNative。

12、diff算法

把树形结构按照层级分解，只比较同级元素。
给列表结构的每个单元添加唯一的 key 属性，方便比较。
React 只会匹配相同 class 的 component（这里面的 class 指的是组件的名字）
合并操作，调用 component 的 setState 方法的时候, React 将其标记为 dirty.到每一个事件循环结束, React 检查所有标记 dirty 的 component 重新绘制.
选择性子树渲染。开发人员可以重写 shouldComponentUpdate 提高 diff 的性能。

13、redux 数据流转过程

redux作为一种单向数据流的实现，尤其是在项目比较大，逻辑比较复杂的时候，单项数据流的思想能使数据的流向、变化都能得到清晰的控制，并且能很好的划分业务逻辑和视图逻辑。
Redux的运作流程：
当用户触摸界面时，调用store.dispatch(action)捕捉具体的action动作。
然后Redux的store自动调用reducer函数，store传递两个参数给reducer函数：当前state和收到的action。其中，reducer函数必须是一个纯函数，该函数会返回一个新的state。
根reducer会把多个子reducer的返回结果合并成最终的应用状态，在这一过程中，可以使用Redux提供的combineReducers方法。使用combineReducers方法时，action会传递给每个子的reducer进行处理，在子reducer处理后会将结果返回给根reducer合并成最终的应用状态。
store调用store.subscribe(listener)监听state的变化，state一旦发生改变就会触发store的更新，最终view会根据store数据的更新刷新界面

14、react-redxu实现原理

Redux作为一个通用模块，主要还是用来处理应用中state的变更，通过react-redux做连接，可以在React+Redux的项目中将两者结合的更好。
react-redux是一个轻量级的封装库，它主要通过两个核心方法实现：

Provider：从最外部封装了整个应用，并向connect模块传递store。
Connect：

• 包装原组件，将state和action通过props的方式传入到原组件内部。
• 监听store tree变化，使其包装的原组件可以响应state变化

15、redux中间件的理解，使用过哪些

中间件就是要对redux的store.dispatch方法做一些改造，以实现其他的功能