乐趣区

关于前端:11道高频React面试题及详解另附有React面试题集合

为什么抉择应用框架而不是原生?

框架的益处:

1. 组件化: 其中以 React 的组件化最为彻底, 甚至能够到函数级别的原子组件, 高度的组件化能够是咱们的工程易于保护、易于组合拓展。

2. 人造分层: JQuery` 时代的代码大部分状况下是面条代码, 耦合重大, 古代框架不论是 MVC、MVP 还是 MVVM 模式都能帮忙咱们进行分层,代码解耦更易于读写。

3. 生态: 当初支流前端框架都自带生态, 不论是数据流治理架构还是 UI 库都有成熟的解决方案。

4. 开发效率: 古代前端框架都默认自动更新 DOM, 而非咱们手动操作, 解放了开发者的手动 DOM 老本, 进步开发效率, 从根本上解决了 UI 与状态同步问题.

虚构 DOM 的优劣如何?

长处:

  • 保障性能上限: 虚构 DOM 能够通过 diff 找出最小差别, 而后批量进行 patch, 这种操作尽管比不上手动优化, 然而比起粗犷的 DOM 操作性能要好很多, 因而虚构 DOM 能够保障性能上限
  • 无需手动操作 DOM: 虚构 DOM 的 diff 和 patch 都是在一次更新中主动进行的, 咱们无需手动操作 DOM, 极大进步开发效率
  • 跨平台: 虚构 DOM 实质上是 JavaScript 对象, 而 DOM 与平台强相干, 相比之下虚构 DOM 能够进行更不便地跨平台操作, 例如服务器渲染、挪动端开发等等

毛病:

  • 无奈进行极致优化: 在一些性能要求极高的利用中虚构 DOM 无奈进行针对性的极致优化, 比方 VScode 采纳间接手动操作 DOM 的形式进行极其的性能优化

    虚构 DOM 实现原理?

  • 虚构 DOM 实质上是 JavaScript 对象, 是对实在 DOM 的形象
  • 状态变更时,记录新树和旧树的差别
  • 最初把差别更新到真正的 dom 中

    React 的申请应该放在哪个生命周期中?

    React 的异步申请到底应该放在哪个生命周期里, 有人认为在 componentWillMount 中能够提前进行异步申请, 防止白屏, 其实这个观点是有问题的.

因为 JavaScript 中异步事件的性质,当您启动 API 调用时,浏览器会在此期间返回执行其余工作。当 React 渲染一个组件时,它不会期待 componentWillMount 它实现任何事件 – React 继续前进并持续 render, 没有方法“暂停”渲染以期待数据达到。

而且在 componentWillMount 申请会有一系列潜在的问题, 首先, 在服务器渲染时, 如果在 componentWillMount 里获取数据,fetch data 会执行两次,一次在服务端一次在客户端,这造成了多余的申请, 其次, 在 React 16 进行 React Fiber 重写后,componentWillMount 可能在一次渲染中屡次调用.

目前官网举荐的异步申请是在 componentDidmount 中进行.

如果有非凡需要须要提前申请, 也能够在非凡状况下在 constructor 中申请:

setState 到底是异步还是同步?

先给出答案: 有时体现出异步, 有时体现出同步

1.setState 只在合成事件和钩子函数中是“异步”的,在原生事件和 setTimeout 中都是同步的。

2.setState 的“异步”并不是说外部由异步代码实现,其实自身执行的过程和代码都是同步的,只是合成事件和钩子函数的调用程序在更新之前,导致在合成事件和钩子函数中没法立马拿到更新后的值,造成了所谓的“异步”,当然能够通过第二个参数 setState(partialState, callback) 中的 callback 拿到更新后的后果。

3.setState 的批量更新优化也是建设在“异步”(合成事件、钩子函数)之上的,在原生事件和 setTimeout 中不会批量更新,在“异步”中如果对同一个值进行屡次 setState,setState 的批量更新策略会对其进行笼罩,取最初一次的执行,如果是同时 setState 多个不同的值,在更新时会对其进行合并批量更新。

React 组件通信如何实现?

React 组件间通信形式:

  • 父组件向子组件通信: 父组件能够向子组件通过传 props 的形式,向子组件进行通信
  • 子组件向父组件通信: props+ 回调的形式, 父组件向子组件传递 props 进行通信,此 props 为作用域为父组件本身的函数,子组件调用该函数,将子组件想要传递的信息,作为参数,传递到父组件的作用域中
  • 兄弟组件通信: 找到这两个兄弟节点独特的父节点, 联合下面两种形式由父节点转发信息进行通信
  • 跨层级通信: Context 设计目标是为了共享那些对于一个组件树而言是“全局”的数据,例如以后认证的用户、主题或首选语言, 对于逾越多层的全局数据通过 Context 通信再适宜不过
  • 公布订阅模式: 发布者公布事件,订阅者监听事件并做出反馈, 咱们能够通过引入 event 模块进行通信
  • 全局状态管理工具: 借助 Redux 或者 Mobx 等全局状态管理工具进行通信, 这种工具会保护一个全局状态核心 Store, 并依据不同的事件产生新的状态

    redux 的工作流程?

    首先,咱们看下几个外围概念:

  • Store:保留数据的中央,你能够把它看成一个容器,整个利用只能有一个 Store。
  • State:Store 对象蕴含所有数据,如果想得到某个时点的数据,就要对 Store 生成快照,这种时点的数据汇合,就叫做 State。
  • Action:State 的变动,会导致 View 的变动。然而,用户接触不到 State,只能接触到 View。所以,State 的变动必须是 View 导致的。Action 就是 View 收回的告诉,示意 State 应该要发生变化了。
  • Action Creator:View 要发送多少种音讯,就会有多少种 Action。如果都手写,会很麻烦,所以咱们定义一个函数来生成 Action,这个函数就叫 Action Creator。
  • Reducer:Store 收到 Action 当前,必须给出一个新的 State,这样 View 才会发生变化。这种 State 的计算过程就叫做 Reducer。Reducer 是一个函数,它承受 Action 和以后 State 作为参数,返回一个新的 State。
  • dispatch:是 View 收回 Action 的惟一办法。

而后咱们过下整个工作流程:
1. 首先,用户(通过 View)收回 Action,收回形式就用到了 dispatch 办法。

2. 而后,Store 主动调用 Reducer,并且传入两个参数:以后 State 和收到的 Action,Reducer 会返回新的 State

3.State 一旦有变动,Store 就会调用监听函数,来更新 View。

到这儿为止,一次用户交互流程完结。能够看到,在整个流程中数据都是单向流动的,这种形式保障了流程的清晰。

react-redux 是如何工作的?

  • Provider: Provider 的作用是从最内部封装了整个利用,并向 connect 模块传递 store
  • connect: 负责连贯 React 和 Redux

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

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

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

redux 与 mobx 的区别?

两者比照:

  • redux 将数据保留在繁多的 store 中,mobx 将数据保留在扩散的多个 store 中
  • redux 应用 plain object 保留数据,须要手动解决变动后的操作;mobx 实用 observable 保留数据,数据变动后主动解决响应的操作
  • redux 应用不可变状态,这意味着状态是只读的,不能间接去批改它,而是应该返回一个新的状态,同时应用纯函数;- – – – mobx 中的状态是可变的,能够间接对其进行批改
  • mobx 相对来说比较简单,在其中有很多的形象,mobx 更多的应用面向对象的编程思维;redux 会比较复杂,因为其中的函数式编程思维把握起来不是那么容易,同时须要借助一系列的中间件来解决异步和副作用
  • mobx 中有更多的形象和封装,调试会比拟艰难,同时后果也难以预测;而 redux 提供可能进行工夫回溯的开发工具,同时其纯函数以及更少的形象,让调试变得更加的容易

场景辨析:
基于以上区别, 咱们能够简略得剖析一下两者的不同应用场景.

mobx 更适宜数据不简单的利用: mobx 难以调试, 很多状态无奈回溯, 面对复杂度高的利用时, 往往力不从心.

redux 适宜有回溯需要的利用: 比方一个画板利用、一个表格利用,很多时候须要撤销、重做等操作,因为 redux 不可变的个性,人造反对这些操作.

mobx 适宜短平快的我的项目: mobx 上手简略, 样板代码少, 能够很大水平上进步开发效率.
当然 mobx 和 redux 也并不一定是非此即彼的关系, 你也能够在我的项目中用 redux 作为全局状态治理, 用 mobx 作为组件部分状态管理器来用.

redux 中如何进行异步操作?

当然, 咱们能够在 `componentDidmount 中间接进行申请毋庸借助 redux.

然而在肯定规模的我的项目中, 上述办法很难进行异步流的治理, 通常状况下咱们会借助 redux 的异步中间件进行异步解决.

redux 异步流中间件其实有很多, 然而当下支流的异步中间件只有两种 redux-thunk、redux-saga,当然 redux-observable 可能也有资格占据一席之地, 其余的异步中间件不论是社区活跃度还是 npm 下载量都比拟差了.

redux 异步中间件之间的优劣?

redux-thunk 长处:

  • 体积小: redux-thunk 的实现形式很简略, 只有不到 20 行代码
  • 应用简略: redux-thunk 没有引入像 redux-saga 或者 redux-observable 额定的范式, 上手简略

redux-thunk 缺点:

  • 样板代码过多: 与 redux 自身一样, 通常一个申请须要大量的代码, 而且很多都是反复性质的
  • 耦合重大: 异步操作与 redux 的 action 偶合在一起, 不方便管理
  • 性能孱弱: 有一些理论开发中罕用的性能须要本人进行封装

redux-saga 长处:

  • 异步解耦: 异步操作被被转移到独自 saga.js 中,不再是掺杂在 action.js 或 component.js 中
    action 解脱 thunk function: dispatch 的参数仍然是一个纯正的 action (FSA),而不是充斥“黑魔法”thunk function
  • 异样解决: 受害于 generator function 的 saga 实现,代码异样 / 申请失败 都能够间接通过 try/catch 语法间接捕捉解决
  • 功能强大: redux-saga 提供了大量的 Saga 辅助函数和 Effect 创立器供开发者应用, 开发者毋庸封装或者简略封装即可应用
  • 灵便: redux-saga 能够将多个 Saga 能够串行 / 并行组合起来, 造成一个十分实用的异步 flow
    易测试,提供了各种 case 的测试计划,包含 mock task,分支笼罩等等

redux-saga 缺点:

  • 额定的学习老本: redux-saga 不仅在应用难以了解的 generator function, 而且有数十个 API, 学习老本远超 redux-thunk, 最重要的是你的额定学习老本是只服务于这个库的, 与 redux-observable 不同,redux-observable 尽管也有额定学习老本然而背地是 rxjs 和一整套思维
  • 体积宏大: 体积略大, 代码近 2000 行,min 版 25KB 左右
  • 性能过剩: 实际上并发管制等性能很难用到, 然而咱们仍然须要引入这些代码
  • ts 反对不敌对: yield 无奈返回 TS 类型

redux-observable 长处:

  • 性能最强: 因为背靠 rxjs 这个弱小的响应式编程的库, 借助 rxjs 的操作符, 你能够简直做任何你能想到的异步解决
  • 背靠 rxjs: 因为有 rxjs 的加持, 如果你曾经学习了 rxjs,redux-observable 的学习老本并不高, 而且随着 rxjs 的降级 redux-observable 也会变得更弱小

redux-observable 缺点:

  • 学习老本奇高: 如果你不会 rxjs, 则须要额定学习两个简单的库
  • 社区个别: redux-observable 的下载量只有 redux-saga 的 1 /5, 社区也不够沉闷, 在简单异步流中间件这个层面 redux-saga 仍处于领导位置

    React 面试题汇合

    面试光看这 11 道题怎么够呢?小编把 React 面试题整顿成了一个汇合,不多但经典哦。

    基本知识

  • 辨别 Real DOM 和 Virtual DOM
  • 什么是 React?
  • React 有什么特点?
  • 列出 React 的一些次要长处。
  • React 有哪些限度?
  • 什么是 JSX?

    React 组件

  • 你了解“在 React 中,一切都是组件”这句话。
  • 解释 React 中 render() 的目标。
  • 如何将两个或多个组件嵌入到一个组件中?
  • 什么是 Props?
  • React 中的状态是什么?它是如何应用的?
  • 辨别状态和 props

    React Redux

  • MVC 框架的次要问题是什么?
  • 解释一下 Flux
  • 什么是 Redux?
  • Redux 遵循的三个准则是什么?
  • 你对“繁多事实起源”有什么了解?
  • 列出 Redux 的组件。

    React 路由

  • 什么是 React 路由?
  • 为什么 React Router v4 中应用 switch 关键字?
  • 为什么须要 React 中的路由?
  • 列出 React Router 的长处。
  • React Router 与惯例路由有何不同?


完整版的 React 面试题汇合 PDF 材料间接点击这里就能够支付了哦。 整顿不易,还请点赞评论反对小编,给小编充充能量,谢谢啦!

退出移动版