年前端 react 面试打怪升级之路
react 和 vue 的区别
相同点：
数据驱动页面，提供响应式的试图组件
都有 virtual DOM,组件化的开发，通过 props 参数进行父子之间组件传递数据，都实现了 webComponents 规范
数据流动单向，都支持服务器的渲染 SSR
都有支持 native 的方法，react 有 React native， vue 有 wexx
不同点：
数据绑定：Vue 实现了双向的数据绑定，react 数据流动是单向的
数据渲染：大规模的数据渲染，react 更快
使用场景：React 配合 Redux 架构适合大规模多人协作复杂项目，Vue 适合小快的项目
开发风格：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 中什么是受控组件和非控组件？
（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 代码。如果你不介意代码美观性，并且希望快速编写代码，使用非受控组件往往可以减少你的代码量。否则，你应该使用受控组件。
例如，下面的代码在非受控组件中接收单个属性：
总结： 页面中所有输入类的 DOM 如果是现用现取的称为非受控组件，而通过 setState 将输入的值维护到了 state 中，需要时再从 state 中取出，这里的数据就受到了 state 的控制，称为受控组件。
React 中有使用过 getDefaultProps 吗？它有什么作用？
通过实现组件的 getDefaultProps，对属性设置默认值（ES5 的写法）：
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()用于设置状态对象，其语法如下：
nextState，将要设置的新状态，该状态会和当前的 state 合并
callback，可选参数，回调函数。该函数会在 setState 设置成功，且组件重新渲染后调用。
合并 nextState 和当前 state，并重新渲染组件。setState 是 React 事件处理函数中和请求回调函数中触发 UI 更新的主要方法。
（2）replaceState() replaceState()方法与 setState()类似，但是方法只会保留 nextState 中状态，原 state 不在 nextState 中的状态都会被删除。其语法如下：
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 中获取到的元素状态相同。官方参考代码：
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：
构造函数用来新建父类的 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 组件。以下是一个类组件：
可以看出，React 类组件内部预置了相当多的“现成的东西”等着我们去调度/定制，state 和生命周期就是这些“现成东西”中的典型。要想得到这些东西，难度也不大，只需要继承一个 React.Component 即可。
当然，这也是类组件的一个不便，它太繁杂了，对于解决许多问题来说，编写一个类组件实在是一个过于复杂的姿势。复杂的姿势必然带来高昂的理解成本，这也是我们所不想看到的。除此之外，由于开发者编写的逻辑在封装后是和组件粘在一起的，这就使得类组件内部的逻辑难以实现拆分和复用。
（2）函数组件：函数组件就是以函数的形态存在的 React 组件。早期并没有 React-Hooks，函数组件内部无法定义和维护 state，因此它还有一个别名叫“无状态组件”。以下是一个函数组件：
相比于类组件，函数组件肉眼可见的特质自然包括轻量、灵活、易于组织和维护、较低的学习成本等。
通过对比，从形态上可以对两种组件做区分，它们之间的区别如下：
类组件需要继承 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。它为其后代元素触发额外的检查和警告。可以为应用程序的任何部分启用严格模式。例如：
在上述的示例中，不会对 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 的注销
还未添加个人签名 2022-09-01 加入
还未添加个人简介
评论