Redux 原理及工作流程
（1）原理 Redux 源码次要分为以下几个模块文件
- compose.js 提供从右到左进行函数式编程
- createStore.js 提供作为生成惟一 store 的函数
- combineReducers.js 提供合并多个 reducer 的函数，保障 store 的唯一性
- bindActionCreators.js 能够让开发者在不间接接触 dispacth 的前提下进行更改 state 的操作
- applyMiddleware.js 这个办法通过中间件来加强 dispatch 的性能
const actionTypes = {
ADD: 'ADD',
CHANGEINFO: 'CHANGEINFO',
}
const initState = {info: '初始化',}
export default function initReducer(state=initState, action) {switch(action.type) {
case actionTypes.CHANGEINFO:
return {
...state,
info: action.preload.info || '',
}
default:
return {...state};
}
}
export default function createStore(reducer, initialState, middleFunc) {if (initialState && typeof initialState === 'function') {
middleFunc = initialState;
initialState = undefined;
}
let currentState = initialState;
const listeners = [];
if (middleFunc && typeof middleFunc === 'function') {
// 封装 dispatch
return middleFunc(createStore)(reducer, initialState);
}
const getState = () => {return currentState;}
const dispatch = (action) => {currentState = reducer(currentState, action);
listeners.forEach(listener => {listener();
})
}
const subscribe = (listener) => {listeners.push(listener);
}
return {
getState,
dispatch,
subscribe
}
}
（2）工作流程
- const store= createStore（fn）生成数据;
- action: {type: Symble(‘action01), payload:’payload’ }定义行为;
- dispatch 发动 action：store.dispatch(doSomething(‘action001’));
- reducer：解决 action，返回新的 state;
艰深点解释：
- 首先，用户（通过 View）收回 Action，收回形式就用到了 dispatch 办法
- 而后，Store 主动调用 Reducer，并且传入两个参数：以后 State 和收到的 Action，Reducer 会返回新的 State
- State—旦有变动，Store 就会调用监听函数，来更新 View
以 store 为外围，能够把它看成数据存储核心，然而他要更改数据的时候不能间接批改，数据批改更新的角色由 Reducers 来负责，store 只做存储，中间人，当 Reducers 的更新实现当前会通过 store 的订阅来告诉 react component，组件把新的状态从新获取渲染，组件中也能被动发送 action，创立 action 后这个动作是不会执行的，所以要 dispatch 这个 action，让 store 通过 reducers 去做更新 React Component 就是 react 的每个组件。
当调用 setState 时，React render 是如何工作的？
咱们能够将 ”render“ 分为两个步骤：
- 虚构 DOM 渲染: 当
render办法被调用时，它返回一个新的组件的虚构 DOM 构造。当调用setState()时，render会被再次调用，因为默认状况下shouldComponentUpdate总是返回true，所以默认状况下 React 是没有优化的。 - 原生 DOM 渲染:React 只会在虚构 DOM 中批改实在 DOM 节点，而且批改的次数非常少——这是很棒的 React 个性，它优化了实在 DOM 的变动，使 React 变得更快。
如何解决 props 层级过深的问题
- 应用 Context API：提供一种组件之间的状态共享，而不用通过显式组件树逐层传递 props；
- 应用 Redux 等状态库。
React Hook 的应用限度有哪些？
React Hooks 的限度次要有两条：
- 不要在循环、条件或嵌套函数中调用 Hook；
- 在 React 的函数组件中调用 Hook。
那为什么会有这样的限度呢？Hooks 的设计初衷是为了改良 React 组件的开发模式。在旧有的开发模式下遇到了三个问题。
- 组件之间难以复用状态逻辑。过来常见的解决方案是高阶组件、render props 及状态治理框架。
- 简单的组件变得难以了解。生命周期函数与业务逻辑耦合太深，导致关联局部难以拆分。
- 人和机器都很容易混同类。常见的有 this 的问题，但在 React 团队中还有类难以优化的问题，心愿在编译优化层面做出一些改良。
这三个问题在肯定水平上妨碍了 React 的后续倒退，所以为了解决这三个问题，Hooks 基于函数组件 开始设计。然而第三个问题决定了 Hooks 只反对函数组件。
那为什么不要在循环、条件或嵌套函数中调用 Hook 呢？因为 Hooks 的设计是基于数组实现。在调用时按程序退出数组中，如果应用循环、条件或嵌套函数很有可能导致数组取值错位，执行谬误的 Hook。当然，本质上 React 的源码里不是数组，是链表。
这些限度会在编码上造成肯定水平的心智累赘，老手可能会写错，为了防止这样的状况，能够引入 ESLint 的 Hooks 查看插件进行预防。
为什么列表循环渲染的 key 最好不要用 index
举例说明
变动前数组的值是[1,2,3,4]，key 就是对应的下标：0，1，2，3
变动后数组的值是[4,3,2,1]，key 对应的下标也是：0，1，2，3
- 那么 diff 算法在变动前的数组找到 key = 0 的值是 1，在变动后数组里找到的 key= 0 的值是 4
- 因为子元素不一样就从新删除并更新
- 然而如果加了惟一的 key, 如下
变动前数组的值是[1,2,3,4]，key 就是对应的下标：id0，id1，id2，id3
变动后数组的值是[4,3,2,1]，key 对应的下标也是：id3，id2，id1，id0
- 那么 diff 算法在变动前的数组找到 key =id0 的值是 1，在变动后数组里找到的 key=id0 的值也是 1
- 因为子元素雷同，就不删除并更新，只做挪动操作，这就晋升了性能
Redux 状态管理器和变量挂载到 window 中有什么区别
两者都是存储数据以供前期应用。然而 Redux 状态更改可回溯——Time travel，数据多了的时候能够很清晰的晓得改变在哪里产生，残缺的提供了一套状态管理模式。
随着 JavaScript 单页利用开发日趋简单，JavaScript 须要治理比任何时候都要多的 state（状态）。这些 state 可能包含服务器响应、缓存数据、本地生成尚未长久化到服务器的数据，也包含 UI 状态，如激活的路由，被选中的标签，是否显示加载动效或者分页器等等。
治理一直变动的 state 十分艰难。如果一个 model 的变动会引起另一个 model 变动，那么当 view 变动时，就可能引起对应 model 以及另一个 model 的变动，顺次地，可能会引起另一个 view 的变动。直至你搞不清楚到底产生了什么。state 在什么时候，因为什么起因，如何变动未然不受管制。当零碎变得盘根错节的时候，想重现问题或者增加新性能就会变得举步维艰。
如果这还不够蹩脚，思考一些来自前端开发畛域的新需要，如更新调优、服务端渲染、路由跳转前申请数据等等。前端开发者正在禁受前所未有的复杂性，难道就这么放弃了吗? 当然不是。
这里的复杂性很大水平上来自于：咱们总是将两个难以理清的概念混同在一起：变动和异步。能够称它们为曼妥思和可乐。如果把二者离开，能做的很好，但混到一起，就变得一团糟。一些库如 React 视图在视图层禁止异步和间接操作 DOM 来解决这个问题。美中不足的是，React 仍旧把解决 state 中数据的问题留给了你。Redux 就是为了帮你解决这个问题。
参考 前端进阶面试题具体解答
React setState 调用之后产生了什么？是同步还是异步？
（1）React 中 setState 后产生了什么
在代码中调用 setState 函数之后，React 会将传入的参数对象与组件以后的状态合并，而后触发和谐过程(Reconciliation)。通过和谐过程，React 会以绝对高效的形式依据新的状态构建 React 元素树并且着手从新渲染整个 UI 界面。
在 React 失去元素树之后，React 会主动计算出新的树与老树的节点差别，而后依据差别对界面进行最小化重渲染。在差别计算算法中，React 可能绝对准确地晓得哪些地位产生了扭转以及应该如何扭转，这就保障了按需更新，而不是全副从新渲染。
如果在短时间内频繁 setState。React 会将 state 的扭转压入栈中，在适合的机会，批量更新 state 和视图，达到进步性能的成果。
（2）setState 是同步还是异步的
如果所有 setState 是同步的，意味着每执行一次 setState 时（有可能一个同步代码中，屡次 setState），都从新 vnode diff + dom 批改，这对性能来说是极为不好的。如果是异步，则能够把一个同步代码中的多个 setState 合并成一次组件更新。所以默认是异步的，然而在一些状况下是同步的。
setState 并不是单纯同步 / 异步的，它的体现会因调用场景的不同而不同。在源码中，通过 isBatchingUpdates 来判断 setState 是先存进 state 队列还是间接更新，如果值为 true 则执行异步操作，为 false 则间接更新。
- 异步： 在 React 能够管制的中央，就为 true，比方在 React 生命周期事件和合成事件中，都会走合并操作，提早更新的策略。
- 同步： 在 React 无法控制的中央，比方原生事件，具体就是在 addEventListener、setTimeout、setInterval 等事件中，就只能同步更新。
个别认为，做异步设计是为了性能优化、缩小渲染次数：
setState设计为异步，能够显著的晋升性能。如果每次调用setState都进行一次更新，那么意味着render函数会被频繁调用，界面从新渲染，这样效率是很低的；最好的方法应该是获取到多个更新，之后进行批量更新；- 如果同步更新了
state，然而还没有执行render函数，那么state和props不能放弃同步。state和props不能放弃一致性，会在开发中产生很多的问题；
React-Router 的实现原理是什么？
客户端路由实现的思维：
-
基于 hash 的路由：通过监听
hashchange事件，感知 hash 的变动- 扭转 hash 能够间接通过 location.hash=xxx
-
基于 H5 history 路由：
- 扭转 url 能够通过 history.pushState 和 resplaceState 等，会将 URL 压入堆栈，同时可能利用
history.go()等 API - 监听 url 的变动能够通过自定义事件触发实现
- 扭转 url 能够通过 history.pushState 和 resplaceState 等，会将 URL 压入堆栈，同时可能利用
react-router 实现的思维：
- 基于
history库来实现上述不同的客户端路由实现思维，并且可能保留历史记录等，磨平浏览器差别，下层无感知 - 通过保护的列表，在每次 URL 发生变化的回收，通过配置的 路由门路，匹配到对应的 Component，并且 render
React.createClass 和 extends Component 的区别有哪些？
React.createClass 和 extends Component 的 bai 区别次要在于：
（1）语法区别
- createClass 实质上是一个工厂函数，extends 的形式更加靠近最新的 ES6 标准的 class 写法。两种形式在语法上的差异次要体现在办法的定义和动态属性的申明上。
- createClass 形式的办法定义应用逗号，隔开，因为 creatClass 实质上是一个函数，传递给它的是一个 Object；而 class 的形式定义方法时务必谨记不要应用逗号隔开，这是 ES6 class 的语法标准。
（2）propType 和 getDefaultProps
- React.createClass：通过 proTypes 对象和 getDefaultProps()办法来设置和获取 props.
- React.Component：通过设置两个属性 propTypes 和 defaultProps
（3）状态的区别
- React.createClass：通过 getInitialState()办法返回一个蕴含初始值的对象
- React.Component：通过 constructor 设置初始状态
（4）this 区别
- React.createClass：会正确绑定 this
- React.Component：因为应用了 ES6，这里会有些微不同，属性并不会主动绑定到 React 类的实例上。
（5）Mixins
- React.createClass：应用 React.createClass 的话，能够在创立组件时增加一个叫做 mixins 的属性，并将可供混合的类的汇合以数组的模式赋给 mixins。
- 如果应用 ES6 的形式来创立组件，那么
React mixins的个性将不能被应用了。
React 事件机制
<div onClick={this.handleClick.bind(this)}> 点我 </div>
React 并不是将 click 事件绑定到了 div 的实在 DOM 上，而是在 document 处监听了所有的事件，当事件产生并且冒泡到 document 处的时候，React 将事件内容封装并交由真正的处理函数运行。这样的形式不仅仅缩小了内存的耗费，还能在组件挂在销毁时对立订阅和移除事件。
除此之外，冒泡到 document 上的事件也不是原生的浏览器事件，而是由 react 本人实现的合成事件（SyntheticEvent）。因而如果不想要是事件冒泡的话应该调用 event.preventDefault()办法，而不是调用 event.stopProppagation()办法。JSX 上写的事件并没有绑定在对应的实在 DOM 上，而是通过事件代理的形式，将所有的事件都对立绑定在了 document 上。这样的形式不仅缩小了内存耗费，还能在组件挂载销毁时对立订阅和移除事件。
另外冒泡到 document 上的事件也不是原生浏览器事件，而是 React 本人实现的合成事件（SyntheticEvent）。因而咱们如果不想要事件冒泡的话，调用 event.stopPropagation 是有效的，而应该调用 event.preventDefault。
实现合成事件的目标如下：
- 合成事件首先抹平了浏览器之间的兼容问题，另外这是一个跨浏览器原生事件包装器，赋予了跨浏览器开发的能力；
- 对于原生浏览器事件来说，浏览器会给监听器创立一个事件对象。如果你有很多的事件监听，那么就须要调配很多的事件对象，造成高额的内存调配问题。然而对于合成事件来说，有一个事件池专门来治理它们的创立和销毁，当事件须要被应用时，就会从池子中复用对象，事件回调完结后，就会销毁事件对象上的属性，从而便于下次复用事件对象。
在 React 中组件的 props 扭转时更新组件的有哪些办法？
在一个组件传入的 props 更新时从新渲染该组件罕用的办法是在 componentWillReceiveProps 中将新的 props 更新到组件的 state 中（这种 state 被成为派生状态（Derived State）），从而实现从新渲染。React 16.3 中还引入了一个新的钩子函数 getDerivedStateFromProps 来专门实现这一需要。
（1）componentWillReceiveProps（已废除）
在 react 的 componentWillReceiveProps(nextProps)生命周期中，能够在子组件的 render 函数执行前，通过 this.props 获取旧的属性，通过 nextProps 获取新的 props，比照两次 props 是否雷同，从而更新子组件本人的 state。
这样的益处是，能够将数据申请放在这里进行执行，须要传的参数则从 componentWillReceiveProps(nextProps)中获取。而不用将所有的申请都放在父组件中。于是该申请只会在该组件渲染时才会收回，从而加重申请累赘。
（2）getDerivedStateFromProps（16.3 引入）
这个生命周期函数是为了代替 componentWillReceiveProps 存在的，所以在须要应用 componentWillReceiveProps 时，就能够思考应用 getDerivedStateFromProps 来进行代替。
两者的参数是不雷同的，而 getDerivedStateFromProps 是一个动态函数，也就是这个函数不能通过 this 拜访到 class 的属性，也并不举荐间接拜访属性。而是应该通过参数提供的 nextProps 以及 prevState 来进行判断，依据新传入的 props 来映射到 state。
须要留神的是，如果 props 传入的内容不须要影响到你的 state，那么就须要返回一个 null，这个返回值是必须的，所以尽量将其写到函数的开端：
static getDerivedStateFromProps(nextProps, prevState) {const {type} = nextProps;
// 当传入的 type 发生变化的时候，更新 state
if (type !== prevState.type) {
return {type,};
}
// 否则，对于 state 不进行任何操作
return null;
}
在 React 中页面从新加载时怎么保留数据？
这个问题就设计到了 数据长久化， 次要的实现形式有以下几种：
- Redux： 将页面的数据存储在 redux 中，在从新加载页面时，获取 Redux 中的数据；
- data.js： 应用 webpack 构建的我的项目，能够建一个文件，data.js，将数据保留 data.js 中，跳转页面后获取；
- sessionStorge： 在进入抉择地址页面之前，componentWillUnMount 的时候，将数据存储到 sessionStorage 中，每次进入页面判断 sessionStorage 中有没有存储的那个值，有，则读取渲染数据；没有，则阐明数据是初始化的状态。返回或进入除了抉择地址以外的页面，清掉存储的 sessionStorage，保障下次进入是初始化的数据
- history API： History API 的
pushState函数能够给历史记录关联一个任意的可序列化state，所以能够在路由push的时候将以后页面的一些信息存到state中，下次返回到这个页面的时候就能从state外面取出来到前的数据从新渲染。react-router 间接能够反对。这个办法适宜一些须要长期存储的场景。
Redux 中异步的申请怎么解决
能够在 componentDidmount 中间接进⾏申请⽆须借助 redux。然而在⼀定规模的项⽬中, 上述⽅法很难进⾏异步流的治理, 通常状况下咱们会借助 redux 的异步中间件进⾏异步解决。redux 异步流中间件其实有很多，当下支流的异步中间件有两种 redux-thunk、redux-saga。
（1）应用 react-thunk 中间件
redux-thunk长处:
- 体积⼩: redux-thunk 的实现⽅式很简略, 只有不到 20 ⾏代码
- 使⽤简略: redux-thunk 没有引⼊像 redux-saga 或者 redux-observable 额定的范式, 上⼿简略
redux-thunk缺点:
- 样板代码过多: 与 redux 自身⼀样, 通常⼀个申请须要⼤量的代码, ⽽且很多都是反复性质的
- 耦合重大: 异步操作与 redux 的 action 偶合在⼀起, 不⽅便治理
- 性能孱弱: 有⼀些理论开发中常⽤的性能须要⾃⼰进⾏封装
应用步骤：
- 配置中间件，在 store 的创立中配置
import {createStore, applyMiddleware, compose} from 'redux';
import reducer from './reducer';
import thunk from 'redux-thunk'
// 设置调试工具
const composeEnhancers = window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ ? window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__({}) : compose;
// 设置中间件
const enhancer = composeEnhancers(applyMiddleware(thunk)
);
const store = createStore(reducer, enhancer);
export default store;
- 增加一个返回函数的 actionCreator，将异步申请逻辑放在外面
/** 发送 get 申请，并生成相应 action，更新 store 的函数 @param url {string} 申请地址 @param func {function} 真正须要生成的 action 对应的 actionCreator @return {function} */
// dispatch 为主动接管的 store.dispatch 函数
export const getHttpAction = (url, func) => (dispatch) => {axios.get(url).then(function(res){const action = func(res.data)
dispatch(action)
})
}
- 生成 action，并发送 action
componentDidMount(){var action = getHttpAction('/getData', getInitTodoItemAction)
// 发送函数类型的 action 时，该 action 的函数领会主动执行
store.dispatch(action)
}
（2）应用 redux-saga 中间件
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-saga 能够捕捉 action，而后执行一个函数，那么能够把异步代码放在这个函数中，应用步骤如下：
- 配置中间件
import {createStore, applyMiddleware, compose} from 'redux';
import reducer from './reducer';
import createSagaMiddleware from 'redux-saga'
import TodoListSaga from './sagas'
const composeEnhancers = window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ ? window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__({}) : compose;
const sagaMiddleware = createSagaMiddleware()
const enhancer = composeEnhancers(applyMiddleware(sagaMiddleware)
);
const store = createStore(reducer, enhancer);
sagaMiddleware.run(TodoListSaga)
export default store;
- 将异步申请放在 sagas.js 中
import {takeEvery, put} from 'redux-saga/effects'
import {initTodoList} from './actionCreator'
import {GET_INIT_ITEM} from './actionTypes'
import axios from 'axios'
function* func(){
try{
// 能够获取异步返回数据
const res = yield axios.get('/getData')
const action = initTodoList(res.data)
// 将 action 发送到 reducer
yield put(action)
}catch(e){console.log('网络申请失败')
}
}
function* mySaga(){
// 主动捕捉 GET_INIT_ITEM 类型的 action，并执行 func
yield takeEvery(GET_INIT_ITEM, func)
}
export default mySaga
- 发送 action
componentDidMount(){const action = getInitTodoItemAction()
store.dispatch(action)
}
当调用 setState 的时候，产生了什么操作？**
当调用 setState 时，React 做的第一件事是将传递给 setState 的对象合并到组件的以后状态，这将启动一个称为和解（reconciliation）的过程。
和解的最终目标是，依据这个新的状态以最无效的形式更新 DOM。
为此，React 将构建一个新的 React 虚构 DOM 树（能够将其视为页面 DOM 元素的对象示意形式）。
一旦有了这个 DOM 树，为了弄清 DOM 是如何响应新的状态而扭转的，React 会将这个新树与上一个虚构 DOM 树比拟。
这样做，React 会晓得产生的确切变动，并且通过理解产生的变动后，在相对必要的状况下进行更新 DOM，即可将因操作 DOM 而占用的空间最小化。
React 中 setState 的第二个参数作用是什么？
setState 的第二个参数是一个可选的回调函数。这个回调函数将在组件从新渲染后执行。等价于在 componentDidUpdate 生命周期内执行。通常倡议应用 componentDidUpdate 来代替此形式。在这个回调函数中你能够拿到更新后 state 的值：
this.setState({
key1: newState1,
key2: newState2,
...
}, callback) // 第二个参数是 state 更新实现后的回调函数
什么是 Props
Props 是 React 中属性的简写。它们是只读组件，必须放弃纯，即不可变。它们总是在整个利用中从父组件传递到子组件。子组件永远不能将 prop 送回父组件。这有助于保护单向数据流，通常用于出现动静生成的数据。
在应用 React Router 时，如何获取以后页面的路由或浏览器中地址栏中的地址？
在以后组件的 props 中，蕴含 location 属性对象，蕴含以后页面路由地址信息，在 match 中存储以后路由的参数等数据信息。能够间接通过 this .props 应用它们。
哪些办法会触发 React 从新渲染？从新渲染 render 会做些什么？
（1）哪些办法会触发 react 从新渲染?
- setState（）办法被调用
setState 是 React 中最罕用的命令，通常状况下，执行 setState 会触发 render。然而这里有个点值得关注，执行 setState 的时候不肯定会从新渲染。当 setState 传入 null 时，并不会触发 render。
class App extends React.Component {
state = {a: 1};
render() {console.log("render");
return (
<React.Fragement>
<p>{this.state.a}</p>
<button
onClick={() => { this.setState({ a: 1}); // 这里并没有扭转 a 的值 }} > Click me </button>
<button onClick={() => this.setState(null)}>setState null</button>
<Child />
</React.Fragement>
);
}
}
- 父组件从新渲染
只有父组件从新渲染了，即便传入子组件的 props 未发生变化，那么子组件也会从新渲染，进而触发 render
（2）从新渲染 render 会做些什么?
- 会对新旧 VNode 进行比照，也就是咱们所说的 Diff 算法。
- 对新旧两棵树进行一个深度优先遍历，这样每一个节点都会一个标记，在到深度遍历的时候，每遍历到一和个节点，就把该节点和新的节点树进行比照，如果有差别就放到一个对象外面
- 遍历差别对象，依据差别的类型，依据对应对规定更新 VNode
React 的解决 render 的根本思维模式是每次一有变动就会去从新渲染整个利用。在 Virtual DOM 没有呈现之前，最简略的办法就是间接调用 innerHTML。Virtual DOM 厉害的中央并不是说它比间接操作 DOM 快，而是说不论数据怎么变，都会尽量以最小的代价去更新 DOM。React 将 render 函数返回的虚构 DOM 树与老的进行比拟，从而确定 DOM 要不要更新、怎么更新。当 DOM 树很大时，遍历两棵树进行各种比对还是相当耗性能的，特地是在顶层 setState 一个渺小的批改，默认会去遍历整棵树。只管 React 应用高度优化的 Diff 算法，然而这个过程依然会损耗性能.
Hooks 能够取代 render props 和高阶组件吗？
通常，render props和高阶组件仅渲染一个子组件。React 团队认为，Hooks 是服务此用例的更简略办法。
这两种模式依然有一席之地(例如，一个虚构的 scroller 组件可能有一个 renderItem prop，或者一个可视化的容器组件可能有它本人的 DOM 构造)。但在大多数状况下，Hooks 就足够了，能够帮忙缩小树中的嵌套。
个别能够用哪些值作为 key
- 最好应用每一条数据中的惟一标识作为 key，比方：手机号，id 值，身份证号，学号等
- 也能够用数据的索引值（可能会呈现一些问题）