今天Spenser在公众号里说，今年许多公司都在裁员。市场上供大于求，但是，好多企业还是招不到人。真正的人才，市面上太稀缺了。这句话真的深有体会。我们公司想要招一个Java的高级开发，招了一个多月都没找到满意的。真的痛苦。
出现这种局面，两极分化就会日渐严重。就以前端行业来看，厉害的人，会越来越难找，也会越来越值钱。而普通的人，混口饭吃都不容易。
还是那句话说得对，外面的世界很精彩，可精彩是属于真正厉害的人
1
上一篇文章留下了一个思考题：在实践场景中，几乎每个页面都会在初始化时加载至少一个接口，而这个接口有一些统一的处理逻辑可以抽离，例如请求成功，返回数据，请求失败，异常处理，特定时机下刷新。我们如何利用自定义hooks来封装这个场景？
直接给出我的建议答案。
import {useState, useEffect} from 'react'; export default function useInitial<T, P>( api: (params: P) => Promise<T>, params: P, defaultData: T ) { const [loading, setLoading] = useState(true); const [response, setResponse] = useState(defaultData); const [errMsg, setErrmsg] = useState(''); useEffect(() => { if (!loading) { return }; getData(); }, [loading]); function getData() { api(params).then(res => { setResponse(res); }).catch(e => { setErrmsg(errMsg); }).finally(() => { setLoading(false); }) } return { loading, setLoading, response, errMsg } }
在页面中使用
export default function FunctionDemo() { // 只需要传入api， 对应的参数与返回结果的初始默认值即可 const {loading, setLoading, response, errMsg} = useInitial(api, {id: 10}, {}); }
当我们想要刷新页面，只需要执行一句代码即可
setLoading(true);
该方案仅供参考，具体使用需要根据实际情况优化，切勿直接生搬硬套。
实践场景也不会如此简单，会有更多的不同情况需要处理，例如，传入参数改变之后，需要重新请求接口刷新数据，我们应该怎么办？
这个留给大家自己结合项目情况去完善。
在这里更重要的是，我们应该想明白，自定义hooks解决了什么样的问题？
2
一些理解不够深刻的文章里说，解决了代码复用的问题？这样说准确吗？其实不完全准确。
准确来说，应该是逻辑片段复用。
和组件化思维不同，这是另外一个粒度更细的代码复用思维。例如我们之前提到的，获取同样的数据。在组件化思维中，一个完整的组件，包括了这份数据，以及这份数据在页面上的展示结果。因此这是不同的复用思维。
处理获取数据过程中的公用逻辑，处理公用的登陆逻辑等。自定义hooks封装的大多数情况下不是一个完整的页面逻辑实现，而是其中的一个片段。
而和普通函数更强一点的是，自定义hooks还能够封装异步逻辑片段。
针对逻辑片段的封装，在React发展历史中的不同阶段，有不同的处理方案。面试的时候，许多面试官比较喜欢问这方面的问题。我们总结一下，各个阶段，分别都是如何处理的。
3
在medium上有一篇安利Render Prop[1]的文章非常火，到目前为止，已经有2万多的点赞。
这篇文章中提到一个需求：某一个组件，需要跟踪鼠标的实时位置。例如拖拽，K线图，走马灯等场景都会需要用到这个逻辑片段。
Hooks
首先使用hooks，我们应该如何实现与运用？
自定义一个hook，这个钩子函数中保存位置信息，以及定义一个回调
import { useState } from ‘react'; export default function usePointor() { const [position, setPosition] = useState({x: 0, y: 0}); function handleMouseMove(event: React.MouseEvent<HTMLDivElement, any>) { setPosition({x: event.clientX, y: event.clientY}); } return {position, handleMouseMove} }
使用时
import React from ‘react’; import usePointor from './usePointor'; export default function MousePos() { const {position, handleMouseMove} = usePointor(); return ( <div onMouseMove={handleMouseMove} style={{width: 500, height: 500}}> <div>x: {position.x}, y: {position.y}</div> </div> ); }
Mixin
React最初使用React.createClass来创建组件。那个时候我们使用mixin来解决同样的问题。
首先创建一个mixin
const MouseMixin = { getInitialState() { return { x: 0, y: 0 } }, handleMouseMove(event) { this.setState({ x: event.clientX, y: event.clientY }) } }
然后在组件中使用
const App = React.createClass({ mixins: [MouseMixin], render() { const { x, y } = this.state return ( <div onMouseMove={this.handleMouseMove}> <div>x: {position.x}, y: {position.y}</div> </div> ) } })
对比两种方式，有非常大的共同之处。但是mixins的问题在于，我们不知道当前我使用的state属性来自于哪里。
当使用多个mixin时，如果各自定义的state命名冲突了怎么办？
mixin当年非常受欢迎，但这两个问题一直是mixin的痛点，导致我们在自定义mixin时必须非常小心。特别是在大型多人协作的项目中，常常会因为维护不好带来麻烦。而这样的痛点，在hooks中不存在。
class
class语法取代React.createClass来创建组件之后，我们使用高阶组件的方式来达到同样的目的。
首先定义一个高阶组件
const withMouse = (Component) => { return class extends React.Component { state = { x: 0, y: 0 } handleMouseMove = (event) => { this.setState({ x: event.clientX, y: event.clientY }) } render() { return ( <div onMouseMove={this.handleMouseMove}> <Component {...this.props} {...this.state} /> </div> ) } } }
然后使用
const App2 = withMouse(({ x, y }) => { return ( <div style={{ height: '100%' }}> <div>x: {position.x}, y: {position.y}</div> </div> ) })
高阶组件面临与mixin同样的问题，当嵌套使用多个高阶组件时，我们在代码中无法识别props中的参数，是哪里来的。并且当参数命名重复时一样无法解决。因此高阶组件在使用时我们也会非常小心，以至于在很多场景下，我们放弃共同逻辑片段的封装，因为这会很容易造成滥用。
render props
class组件中，复用逻辑片段，最好的方案是render props。
首先创建一个组件
mport React from ‘react’; interface Props { render: (props: {x: number, y: number}) => any } export default class Mouse extends React.Component<Props> { state = { x: 0, y: 0 } handleMouseMove = (event: any) => { this.setState({ x: event.clientX, y: event.clientY }) } render() { return ( <div onMouseMove={this.handleMouseMove}> {this.props.render(this.state)} </div> ) } }
然后使用
import React from 'react'; import Mouse from ‘./Mouse’; export default function MousePos() { return ( <div> <Mouse render={({ x, y }) => ( <div>x: {x}, y: {y}</div> )} /> </div> ) }
render props使用非常广泛。原因就在于render props解决了来源问题，同时也避免了命名冲突。
但render props的问题在于
1.可读性不高，直观上比较别扭。我们可以在Mouse组件中处理很多额外逻辑，甚至定义更多的交互样式。因此使用时会造成一些困扰。2.存在局限性。我们期望的是能够切割逻辑片段，render props最终仍然是组件化思维的扩展运用3.代码不够优雅，这个是我个人主观上的看法
自定义hook是目前为止，解决逻辑片段复用的最佳方案。
这种思维和函数式编程思维有共通之处。
例如数组的forEach, map, filter等方法。在所有的for循环中，共同的逻辑是对每一个元素的遍历。我们可以将这个逻辑抽取出来。封装成为forEach
forEach：循环过程中，执行某种操作
Array.prototype.forEach = function () { const ary = this; const [callbackfn, thisArg] = [].slice.call(arguments); if (typeof callbackfn !== 'function') { throw new TypeError(callbackfn + 'is not a function') } for (let i = 0; i < ary.length; i++) { callbackfn.call(thisArg, ary[i], i, ary); } }
map 循环过程中，返回新的子项，最终组成新的数组。
和forEach相比，循环过程中执行的某种操作具体化了，map完全可以基于forEach实现。
function map(arr, fn) { const res = []; arr.forEash((item, i) => { res[i] = fn(item, i); }) return res; }
filter: 循环过程中，过滤出符合条件的子项。同理。
function filter(arr, fn) { const res = []; arr.forEash((item, i) => { const isOk = fn(item, i); if (isOk) { res.push[item]; } }) return res; }
同样的方式，我们可以非常简单的基于forEach实现some, every，reduce等方法。
原则上来说，公共逻辑片段无论是在业务场景中，还是在工具模块中，都非常多。而React Hooks能够轻松解决在React环境中的逻辑片段封装。这是自定义hook的底层思维。
理解了这个思维，我们能够容易的辨别出来，哪些场景需要使用自定义hooks。也能够感受得到，在大型项目中，自定义hooks对于大型项目的重要性。
React Hooks剩余的许多api，包括useCallback，useMemo等，其实都是自定义的hooks，利用本文提到的公共片段思维，很快就能掌握他们。
