超性感的React Hooks（六）自定义hooks的思维方式

今天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的文章非常火，到目前为止，已经有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 (
    

      
x: {position.x}, y: {position.y}
    
  );
}

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 (
      

        
x: {position.x}, y: {position.y}
      
    )
  }
})

对比两种方式，有非常大的共同之处。但是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 (
    

      
x: {position.x}, y: {position.y}
    
  )
})

高阶组件面临与mixin同样的问题，当嵌套使用多个高阶组件时，我们在代码中无法识别props中的参数，是哪里来的。并且当参数命名重复时一样无法解决。因此高阶组件在使用时我们也会非常小心，以至于在很多场景下，我们放弃共同逻辑片段的封装，因为这会很容易造成滥用。

render props

class组件中，复用逻辑片段，最好的方案是render props。

首先创建一个组件

import React from ‘react’;

interface Props {
  render: (props: {x: number, y: number}) => any
}

export default class Mouse extends React.Component {
  state = { x: 0, y: 0 }

  handleMouseMove = (event: any) => {
    this.setState({
      x: event.clientX,
      y: event.clientY
    })
  }

  render() {
    return (
      

        {this.props.render(this.state)}
      
    )
  }
}

然后使用

import React from 'react';
import Mouse from ‘./Mouse’;

export default function MousePos() {
  return (
    

       (
          
x: {x}, y: {y}
        )}
      />
    
  )
}

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，利用本文提到的公共片段思维，很快就能掌握他们。

本系列文章的所有案例，都可以在下面的地址中查看

https://github.com/advance-course/react-hooks

本系列文章为原创，请勿私自转载，转载请务必私信我