useState
useState 接管的值只作为初始渲染时的状态，后续的从新渲染的值都是通过 setState 去设置
1. 函数式更新
除了惯例的 setState(value)的形式去更新状态以外，setState 还能够接管一个函数来更新状态。这种更新状态的形式通常应用在新的 state 须要通过应用先前的 state 计算得出的场景。
在 effect 的依赖频繁变动的场景下有时也能够通过函数式更新状态来解决问题，例如一个每秒中自增状态的场景：
然而依赖项设置后会导致每次扭转产生时定时器都被重置，这并不是咱们想要的，所以这时就可能通过函数式更新状态并且不援用以后 state。
2. 惰性初始 state
一些须要简单计算的初始状态如果间接将函数运行后果传入 useState，会在每次从新渲染时执行所传入的函数，比方：
codesandbox
所以能够向 useState 中传入一个函数，在函数中计算并返回初始的 state，此函数只在初始渲染时被调用 codesandbox
useEffect
useEffect 用来实现副作用。
## 1. 解决副作用与 class 组件的区别
在 class 组件中，通常做法是在生命周期中去查看 props.A 和 state.B，如果合乎某个条件就去触发 XXX 副作用。而在 function 组件中，思维模式是我须要解决 XXX 副作用，它的依赖数据是 props.A 和 state.B。从之前的命令式转变到 function 组件的申明式，开发者不再须要将精力投入到思考不同生命周期判断各种条件再执行副作用这样的事中，而能够将精力聚焦在更高的抽象层次上。
## 2. 须要将 effect 中用到的所有组件内的值都要蕴含在依赖中
React 在每次渲染都有这次对应的 state、props、事件处理函数和 effect，如果设置了谬误的依赖就可能会导致副作用函数中所应用到的值并不是最新的。
举个例子，咱们来写一个每秒递增的计数器。在 Class 组件中，咱们的直觉是：“开启一次定时器，革除也是一次”。这里有一个例子阐明怎么实现它。当咱们天经地义地把它用 useEffect 的形式翻译，直觉上咱们会设置依赖为[]，因为“我只想运行一次 effect”。
然而，这个例子只会递增一次。因为副作用函数只在第一次渲染时候执行，第一次渲染对应的 count 是 0，所以定时器中永远是 setCoun(1)。
依赖项是咱们给 react 的提醒，通知 react 不用每次渲染都去执行 effect，只须要在依赖项变动时才去执行对应的 effect。谬误的依赖项导致 effect 中拿到的状态的值可能跟上一次 effect 执行时一样而不是最新的状态。
相似于这样的问题是很难被想到的，所以须要启用 eslint-plugin-react-hooks 中的 exhaustive-deps 规定，此规定会在增加谬误依赖时收回正告并给出修复倡议。
## 3. 优化依赖项
尽量设置少的依赖项
### 在 effect 外部去申明它所须要的函数
比方在某些状况下，组件内函数和 effect 依赖同一个 state
因为 doSomething 这个函数并没有被应用到多个中央，所以能够将它申明到 effect 外部去缩小依赖项
### 函数应用 useCallback 去包裹
和下面一种状况相似，然而doSomething 这个函数在多个中央应用
这种状况不不便把一个函数挪动到 effect 外部，能够将函数应用 useCallback 去包裹这个函数
### 将函数申明到组件内部
如果函数没有应用到组件内的值，能够将函数申明到组件内部以缩小依赖项
### 应用函数式更新状态来缩小依赖项
比方在依赖以后状态来更新状态的状况下，能够应用函数式更新状态来缩小依赖项，就像下面 useState 中所举的例子一样。
# useRef
## 1. 应用 useRef 保留组件中所须要的的惟一实例对象
比方在 function 组件中去应用 rxjs 数据流时，须要在组件挂载和销毁时监听和勾销监听，如果在组件外去定义 subject，全局监听的都是同一个 observable
这样在其中任一个组件中 next 值时，都会被所有观察者接管到。
所以这里须要放弃每个组件有本人独立的 observable，并且它又不须要作为状态去参加渲染，所以这块应用 useRef 去保留这个 observable。
这样就达到了目标。
2. 保留一些不参加渲染的值
当 ref 对象内容发生变化时，useRef 并不会告诉你。变更 .current 属性不会引发组件从新渲染，所以咱们能够应用 useRef 去保留一些不参数渲染的值。
# useMemo useCallback
useMemo 和 useCallback 一起作为组件渲染优化的抉择而呈现，然而它们不能作为性能优化的银弹而去在任何状况上来应用。
咱们须要晓得这两个 api 自身也有开销。它们 会「记住」一些值，同时在后续 render 时，将依赖数组中的值取出来和上一次记录的值进行比拟，如果不相等才会从新执行回调函数，否则间接返回「记住」的值。这个过程自身就会耗费肯定的内存和计算资源。因而，适度应用 useMemo/useCallback 可能会影响程序的性能。
所以要想正当应用 useMemo/useCallback，咱们须要搞清楚 它们 实用的场景：
- 有些计算开销很大，咱们就须要「记住」它的返回值，防止每次 render 都去从新计算。
- 因为值的援用发生变化，导致上游组件从新渲染，咱们也须要「记住」这个值。
# useReducer
useState 的代替模式，在状态之间逻辑简单时应用 useReducer 能够将 what 和 how 离开，只须要在组件中申明式的 dispatch 对应的行为，所有行为的具体实现都在 reducer 中保护，让咱们的代码能够像用户的行为一样，更加清晰。
这是一个登录 demo, 通过 useReducer 将登录的相干状态抽离出组件外部，避免组件外部多处去保护这些状态，组件外部只须要通过 dispatch 行为来实现各种交互。
如果你的页面 state 比较复杂（state 是一个对象或者 state 十分多散落在各处）请应用 userReducer
# useContext
## 与 useReducer 联合应用，代替将回调函数作为参数向下传递的形式，改为共享 context 中的 dispatch
改写之前的登录 demo，将登录 button 改为子组件，通过 useContext 去拿到dispatch。
如果你的页面组件层级比拟深，并且须要子组件触发 state 的变动，能够思考 useReducer + useContext
参考文章：
- https://overreacted.io/zh-han…
- https://zhuanlan.zhihu.com/p/…
- https://zhuanlan.zhihu.com/p/…