开头
我们今天主要说明的内容是关于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库”。
从各自的“一句话”介绍中也可以看出，React将自己定义为“JavaScript库”，AngularJS才是“框架”。 人们常说“React框架”，但人们从未说过自己是库。 框架这个名字是我们强加的，不要以为它只是一个框架。 确实误解了很多人，特别是初学者。 即使是有几年工作经验的老油条也误解了React。 那么，这个误会是怎么来的呢？
实际上，React没有组件、页面、控制器和型号。 在AngularJS框架中，React中没有这些常见概念。 没有页面吗？ 它通过组件的组合生成页面。 如果没有控制器，请使用组件作为控制器。 就像制作乐高玩具一样，组件是构成整个APP应用程序的唯一部件。
然而，在实际编码中，它可以是纯函数组件或类组件，或者函数可能产生直接影响UI生成的副作用，如操作DOM或绑定事件。 React只关心两件事：数据和组件。 React由组件开发人员负责数据，这是我理解的MVVM框架的概念。因为程序员负责处理MV，而React负责构建虚拟机，对React本身来说，只负责构建视图，所以在应用场景中传统的MVVM框架可以使用React-dom开发PC页面和移动端页面。 使用还原主动开发iOS和安卓APP； 然后React-360可以开发VR APP； 也可以使用React-ink开发命令行APP应用程序。
当然，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-满意的戒指/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？”
举个例子，你kydbg儿给你介绍了俩对象，一个温婉可爱小鸟依人，一个上得厅堂下得厨房，结果你依然选择单身不找对象，你kydbg儿就问你为啥呀？你如果说单身有多好，你一定会被怼？怎么回答呢？温柔的太粘人，贤惠的长得丑；然后在说单身有多好；
套路就是，之所以选择x，是因为 y 和 z 不好，然后再说明 x 怎么怎么好；
但是，放到技术上，要答好这个问题，为什么 React 选择使用 JSX ？你需要先了解 React 可选的其他解决方案，然后才能知道有什么不好的地方；其实相关方案有很多，最直观的就是 模板，Vue 和 AngularJS 都选择使用模板方案，而 React 团队认为引入模板是一种不佳的实现，你觉得模板不好吗？我觉得还行啊，你觉得丑，我觉得美若天仙啊；这不仅仅是眼光不同，更多的是基于不同的角度来思考，再结合自身的特性做出的选择，React 团队之所以认为模板不是最佳实现，原因在于，React 团队认为模板分离了技术栈，分散了组件内的关注点，其次模板还会引入更多的概念，类似模板语法、模板指令等，JSX 并不会引入太多新的概念，它仍然是 JavaScript，就连条件表达式和循环都仍然是 JavaScript 的方式。更具有可读性，更贴近 HTML。而对于关注点分离这个问题，我们可以用两段代码来展示：
上面的两端代码分别使用了 React 及 Vue 的单文件组件来呈现，在 React 中，声明的 Users 类就是一个组件，全部的 方法、数据及 UI 视图，可以以任意的方式呈现， 而在 Vue 的组件中，很明确的要将 UI 部分写入 template 模板标签中(当然还可以在 component 方法中使用 template 字符串 )，功能及数据相关的 要写入 script 标签中，而相对应的数据展示能力，则需要使用模板指令进行呈现，如：@click 指令绑定点击事件，v-for 循环遍历数据及样式结构；而在 JSX 中，全部都是 JavaScript 的，没什么规矩可言；
两种方式各有不同，我自己也说不上喜欢那个，但是，站在混技术角度，我肯定选择 JSX ，而站在产品研发角度，我更倾向于 Vue 的模板方式；
就类似mhdyb做饭超级好吃，选媳妇就选小鸟依人的，但是mhdyb做饭根本没法吃，我还是选下得厨房的媳妇要好一些。毕竟程序员是不需要爱情的……
如果你想解答的更加完善，还可以加入其他方式进行阐述，比如 模板字符、JXON；篇幅有限，我这里就不展开说了；
对于 为什么 React 选择使用 JSX ？到这里，我们其实已经说的差不多了，但是，总觉得少点什么，那就是对于 JSX 本身的阐述还不到位；
那么 JSX 到底是什么呢？
我们知道它不是字符串也不是 HTML，是一个 JavaScript 的语法扩展，用于描述组件 UI 。 实际上，官方手册上早就说的很清楚了，JSX 仅仅只是 `React.createElement(component, props, ...children)` 函数的语法糖，最终会被编译为 React.createElement() 函数调用，返回称为 “React 元素” 的普通 JavaScript 对象。
我们用一段简单的代码展示一下，具体来看看：
上面的代码中，我们直接将 JSX 的内容打印到控制台，效果如下：
那么，从 JSX 到控制台打印的结果中，到底发生了什么？手册上说 JSX 仅仅只是 React.createElement() 函数的语法糖，那么问题就来了，React.createElement 到底做了什么呢？ 走，翻一下源码看看就知道了
对于这段代码，并没有什么高大上的骚操作，在这里，我大致说一下，做了什么事情：
React. createElement 二次处理 key、ref、self、 source 四个属性值；
遍历 config，筛出可以提进 props 里的属性；
提取子元素，推入 childArray（也即 props.children）数组；
格式化 defaultProps；
结合以上数据作为入参，发起 ReactElement调用；
那么接着让我们进入到 ReactElement 方法，继续查看 到底做了什么事情：
而这些代码就更有意思了，就是把传入的内容，组装进 element 对象并返回，注意，这个 element 实际就是我们之前打印到控制台的那个对象，其实这个对象就是我们常说的 ”虚拟 DOM “ ，而从虚拟 DOM 到真实 DOM 的工作，就是我们调用 ReactDOM.render 方法去做的事情了，这里咱们就不再继续分析了；
来波小总结
为什么 React 选择使用 JSX ？本质就是萝卜青菜各有所爱，React 团队认为 JSX 不会引入太多新的概念，编码更纯净，更具有可读性，更贴近 HTML，而对于 JSX 本身来说，是 React.createElement() 函数的语法糖，createElement() 对参数进行拆解后，发起 ReactElement 调用生成虚拟 DOM 对象；