为什么抉择应用框架而不是原生?
框架的益处:
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材料间接点击这里就能够支付了哦。整顿不易，还请点赞评论反对小编，给小编充充能量，谢谢啦！