React 面试筹备不完全指南

开篇

我们今天主要讲解的内容就是关于 React 面试相关的，我相信你在面试中，也会被问到各种各样的非常多的问题，我举几个例子你看看，在自己心里想一想，你会怎么回答？

为什么 React 选择使用 JSX ？

JSX 映射虚拟 Dom 的原理

setState 到底是同步的，还是异步的？

如何面向组件跨层级通信？

聊聊 Redux 和 Vuex 的设计思想有什么不同和相同之处？

React 事件与 DOM 事件有什么区别？

为什么 React 要加入 Hook ?

说一下你对 diff 算法的理解

谈一谈 React 的数据流管理

上面这些问题，非常的常见，除此之外，类似的问题还有很多，一个一个的讲，根本讲不完，也不可能每个都讲到；当然网上有很多面试宝典，各种典型面试题都会涉及到，大家可能最近都在准备面试，迫切想要知道这些问题的答案，这也是大家最容易陷入的一个职场误区，对自己的现状不满，想要跳槽涨薪，又缺乏日常积累，面试前疯狂的刷一些面试题，应付当前的几场面试，1-2年后，又一次轮回，忽略日常的积累和总结，总想着临阵才磨枪，倒是会有些闪亮，但永远不会锋利；

解这些题，并不是今天的重点，我想给你的，是一套方法论，是解决这一类问题的通用方法：

总体来说分为三个部分：

1：对 React 框架的全面了解；

这需要你在日常的开发中，不断积累总结，有意识的主动探索和思考，今天我就分享一下我自己的总计和思考，没有绝对的正确，但我相信一定对你有所启发；

2：面试问题解答的思路和技巧；

我对 React 的使用有很多经验了，写过几个项目，也有了自己的思考和理解，但是，在面试的时候，是不是又这样的情况呢？知道这个知识点，但不能准确完整地表达、不知道该如何描述，但当面试官提起的时候，又能记忆起来，说，“对对对，就是那个，我刚确实不知道该怎么讲”。肚子里有东西，却在嘴上吃了大亏？

3：经典面试题案例解答

前面介绍了这些思路和技巧，那么如何应用到具体的问题解答上呢？我们使用几个比较典型的面试题案例来解答；

如何理解 React 框架？

先从前端框架的发展来看，之前是没有前端框架这样的工具的，但是前端的业务量越来越大，页面变得越来越复杂，前端的工程也开始庞大了起来，如何组织代码结构，如何有效提升复用率，开始成为大型前端项目迫切需要解决的问题。2009年，带有大量的 Java 开发思想的 AngularJS 问世：https://angular.cn/ ；

AngularJS 提供了一揽子全家桶解决方案，从底层开始深度封装，向上提供了路由、双向绑定、指令、组件等框架特性。现在也一样，你需要的，它全部都有，但是学习成本太高了，各种全新概念应接不暇，让我们一度怀疑我写的不是 前端代码，而是 AngularJS 代码；

而 React 的思维模式是完全不同的，概念也极为简单：“一切皆组件”，而 组件 == Function / Class ；

官方手册 https://react.docschina.org/ 的第一句话就是 “ 用于构建用户界面的 JavaScript 库 ” ；

image-20210225154149524.png

从各自的 “一句话” 介绍中，我们也可以看到，React 把自己定义为 “ JavaScript 库 ”，而 AngularJS 才是 “框架”，虽然我们经常说 “React 框架”，但是人家从来都说自己是个 库 的，框架这个名字，是我们强加给人家的，不要觉得这仅仅是一个称呼而已，其实从一定程度上，确实误导了很多人，尤其是新手，甚至有过几年工作经验的老油条，也在误会着 React ，那这个误会是怎么来的呢？

其实在 React 中，只有组件，没有页面，没有控制器，也没用模型，在 AngularJS 框架中这些习以为常的概念，React 统统没有。没有页面？那就用组件组合生成一个页面，没有控制器，那就用组件充当控制器。就像搭建乐高玩具一样，组件就是组成整个应用唯一零部件。

但是从实际编码上来讲，可以是纯函数组件或者类组件，也可能在函数中产生影响 UI 生成的副作用，比如直接操作 DOM 或者绑定事件等。在 React 中我们只需要关心两件事：数据与组件。React 负责组件开发者负责数据；这也就是我所理解的 MVVM 框架的概念；程序员负责 MV 的处理，React 负责 VM 的构建；那么对于 React 本身来说就只负责构建视图的工作了，因此在适用场景上远比传统框架更为广泛，你可以使用 React-dom 开发 PC 网页或者移动端网页；使用 React-Native，开发 iOS 与 Android 应用；还有 React-360 可以开发 VR 应用；甚至可以使用 React-ink 开发命令行应用。

当然 React 也有缺点， 由于 React 并不是一个典型的框架，比如路由、状态管理这样的功能，React 团队更希望交给社区来解决。所以导致在技术选型与学习使用上有比较高的成本。但也正因为社区蓬勃发展，非官方的一揽子解决方案还是有的，比如 Redux、 React Router 、组件库 Antd 、长列表 React-window 等填补了生态位的缺失。而日常开发应用，这些总要去学习使用，而更多的人，将这些社区的方案当作了 React 的一部分，因此就觉得 React 是个 “框架” 了，这样的说法虽然不准确，但其实也没必要必须纠正，因为 “React+社区方案” 的组合，确实是一个框架应该有的样子；也正为如此，React 成了一个使用者上限与下限差距极大的框架， 而社区方案的组合和应用能力，也成为了进大厂的必考内容；

虽然我这里在一定程度上拿 AngularJS 和 React 再做对比，但是请注意，如果你觉得 AngularJS 无懈可击宇宙无敌吊炸天，那一定是你说的对，而如果你觉得 Vue 无懈可击宇宙无敌吊炸天，那当然也是你说的对；

对于各种框架的对比调查也有很多，正巧，前一段时间 stateofjs2020 刚刚发布，大家感兴趣可以去看看一下；

stateofjs 2020 年度前端开发者调查报告：https://2020.stateofjs.com/zh-Hans/technologies/front-end-frameworks/

报告显示，React 的占用量明显高于 Vue 和 AngularJS , 80%的调查者使用英语语种，说白了，就是欧美方面的调查，并不能说明国内的情况，而 react 在 Github 的 star 是 164K，Vue2.x 在 Github 的star 是 180K，大家也可以自己去看看，https://github.com/facebook/react、https://github.com/vuejs/vue，如果有时间，还可以去看看 NPM 的下载数；

其实，我想说的是，不要做那个框架好的对比， Vue 和 React 或者AngularJS 或者其他 MVVM 框架，都是非常优秀且值得学习的，也都有各自的优点和缺点；与其在网络上撕逼，不如认真学习学习，奉劝各位，井蛙不可语海，夏虫不可语冰；

总结一下：

React 本质上就是一个构建用户界面的 JavaScript 库，通过组件化的方式解决视图层开发复用的问题；

组件化的优势在于视图的拆分与模块复用，可以更容易做到高内聚低耦合，

通用性更强，一次学习，随处编写。比如 React Native，React 360 等， 这里主要靠虚拟 DOM 来保证实现。

这使得 React 的适用范围变得足够广

但作为一个视图层的框架，React 的劣势也十分明显。它并没有提供传统框架的一整套完整解决方案，在开发大型前端应用时，需要向社区寻找并整合解决方案。虽然一定程度上促进了社区的繁荣，但也为开发者在技术选型和学习适用上造成了一定的成本。

为什么 React 选择使用 JSX ？

这里问 “为什么 React 选择使用 JSX ？”，其引申含义是 “为什么不用 A、B、C？”

举个例子，你二婶儿给你介绍了俩对象，一个温婉可爱小鸟依人，一个上得厅堂下得厨房，结果你依然选择单身不找对象，你二婶儿就问你为啥呀？你如果说单身有多好，你一定会被怼？怎么回答呢？温柔的太粘人，贤惠的长得丑；然后在说单身有多好；

套路就是，之所以选择x，是因为 y 和 z 不好，然后再说明 x 怎么怎么好；

但是，放到技术上，要答好这个问题，为什么 React 选择使用 JSX ？你需要先了解 React 可选的其他解决方案，然后才能知道有什么不好的地方；其实相关方案有很多，最直观的就是 模板，Vue 和 AngularJS 都选择使用模板方案，而 React 团队认为引入模板是一种不佳的实现，你觉得模板不好吗？我觉得还行啊，你觉得丑，我觉得美若天仙啊；这不仅仅是眼光不同，更多的是基于不同的角度来思考，再结合自身的特性做出的选择，React 团队之所以认为模板不是最佳实现，原因在于，React 团队认为模板分离了技术栈，分散了组件内的关注点，其次模板还会引入更多的概念，类似模板语法、模板指令等，JSX 并不会引入太多新的概念，它仍然是 JavaScript，就连条件表达式和循环都仍然是 JavaScript 的方式。更具有可读性，更贴近 HTML。而对于关注点分离这个问题，我们可以用两段代码来展示：

image-20210225154149566.png

上面的两端代码分别使用了 React 及 Vue 的单文件组件来呈现，在 React 中，声明的 Users 类就是一个组件，全部的 方法、数据及 UI 视图，可以以任意的方式呈现， 而在 Vue 的组件中，很明确的要将 UI 部分写入 template 模板标签中(当然还可以在 component 方法中使用 template 字符串 )，功能及数据相关的 要写入 script 标签中，而相对应的数据展示能力，则需要使用模板指令进行呈现，如：@click 指令绑定点击事件，v-for 循环遍历数据及样式结构；而在 JSX 中，全部都是 JavaScript 的，没什么规矩可言；

两种方式各有不同，我自己也说不上喜欢那个，但是，站在技术角度，我比较喜欢 JSX ，而站在产品研发角度，我更倾向于 Vue 的模板方式；

就类似我妈做饭超级好吃，选媳妇就选小鸟依人的，但是我妈做饭根本没法吃，我还是选下得厨房的媳妇要好一些。毕竟程序员是不需要爱情的……

如果你想解答的更加完善，还可以加入其他方式进行阐述，比如 模板字符、JXON；篇幅有限，我这里就不展开说了；

对于 为什么 React 选择使用 JSX ？到这里，我们其实已经说的差不多了，但是，总觉得少点什么，那就是对于 JSX 本身的阐述还不到位；

那么 JSX 到底是什么呢？

我们知道它不是字符串也不是 HTML，是一个 JavaScript 的语法扩展，用于描述组件 UI 。 实际上，官方手册上早就说的很清楚了，JSX 仅仅只是 React.createElement(component, props, ...children) 函数的语法糖，最终会被编译为 React.createElement() 函数调用，返回称为 “React 元素” 的普通 JavaScript 对象。

我们用一段简单的代码展示一下，具体来看看：

image-20210225154149576.png

上面的代码中，我们直接将 JSX 的内容打印到控制台，效果如下：

image-20210305133806872.png

那么，从 JSX 到控制台打印的结果中，到底发生了什么？手册上说 JSX 仅仅只是 React.createElement() 函数的语法糖，那么问题就来了，React.createElement 到底做了什么呢？ 走，翻一下源码看看就知道了

image-20210305133806882.png

对于这段代码，并没有什么高大上的骚操作，在这里，我大致说一下，做了什么事情：

React. createElement 二次处理 key、ref、self、 source 四个属性值；

遍历 config，筛出可以提进 props 里的属性；

提取子元素，推入 childArray（也即 props.children）数组；

格式化 defaultProps；

结合以上数据作为入参，发起 ReactElement调用；

那么接着让我们进入到 ReactElement 方法，继续查看 到底做了什么事情：

image-20210305133806892.png

而这些代码就更有意思了，就是把传入的内容，组装进 element 对象并返回，注意，这个 element 实际就是我们之前打印到控制台的那个对象，其实这个对象就是我们常说的 ”虚拟 DOM “ ，而从虚拟 DOM 到真实 DOM 的工作，就是我们调用 ReactDOM.render 方法去做的事情了，这里咱们就不再继续分析了；

来波小总结

为什么 React 选择使用 JSX ？本质就是萝卜青菜各有所爱，React 团队认为 JSX 不会引入太多新的概念，编码更纯净，更具有可读性，更贴近 HTML，而对于 JSX 本身来说，是 React.createElement() 函数的语法糖，createElement() 对参数进行拆解后，发起 ReactElement 调用生成虚拟 DOM 对象；