关于hooks:当设计模式遇上-Hooks

简介：数据结构与设计模式可能领导咱们在开发简单零碎中寻得一条清晰的路线，既然都说 Hooks 难以保护，那就尝试让「神」来援救这凌乱的场面。对于「设计模式是否有助于咱们写出更优雅的 Hooks」这个问题，看完本文，置信你心中也会有本人的答案。

作者 | 阿晨
起源 | 阿里技术公众号

一 前言

「设计模式」是一个陈词滥调的话题，但更多是集中在面向对象语言畛域，如 C++，Java 等。前端畛域对于设计模式的探讨热度并不是很高，很多人感觉对于 JavaScript 这种典型的面向过程的语言来说，设计模式的价值很难体现。之前我持有相似的观点，对于设计模式的了解仅停留在概念层面，没有深刻去理解其在前端工程中的实际。近期浏览了《JavaScript 设计模式与开发实际》一书，书中介绍了 15 种常见设计模式和根本的设计准则，以及如何应用 JavaScript 优雅实现并利用于理论工程中。碰巧前不久团队举办了一场对于 Hooks 的辩论赛，而 Hooks 的核心思想在于函数式编程，于是决定探索一下「设计模式是否有助于咱们写出更优雅的 Hooks」这一话题。

二 为什么是设计模式

在逆袭武侠剧中，主人公向第一位师父求教武艺时，最开始老师父只会让主人公挑水、扎马步等基本功，主人公这时总是会诸般埋怨，但又因为某些客观原因又不得不保持，之后开始学习真正的武艺时才顿悟之前老师父的一番苦心，夯实根底后学习武艺突飞猛进，最终成为一代大侠。对于咱们开发者来说，「数据结构」和「设计模式」就是老师父所教的基本功，它不肯定可能让咱们走得更快，但肯定能够让咱们走得更稳、更远，有助于咱们写出高牢靠且易于保护的代码，防止日后被“挖坟”。

在 Hooks 公布以来，饱受诟病的一点就是保护老本激增，特地是对于成员能力程度差距较大的团队来说。即使一开始由经验老到的同学搭建整个我的项目框架，一旦交由新人保护一段时间后，大概率也会变得面目全非，更不用说让新人应用 Hooks 开发从零到一的工程。我了解这是因为 Hooks 的高度灵活性所导致的，Class Component 尚有一系列生命周期办法来束缚，而 Hooks 除了 API 参数上的束缚，也仅有“只在最顶层应用 Hook”“只在 React 函数中调用 Hook”两条强制规定。另一方面自定义 Hook 进步组件逻辑复用率的同时，也导致经验不足的开发者在形象时短少设计。Class Component 中对于逻辑的形象通常会形象为纯函数，而 Hooks 的封装则可能携带各种副作用（useEffect），呈现 bug 时排查老本较大。

那么既然「设计模式」是一种基本功，而「Hooks」是一种新招式，那咱们就尝试从设计模式登程，攻克新招式。

三 有哪些经典的设计模式

在正式进入话题之前，咱们先简略回顾一下那些快被咱们忘记的经典设计模式和设计准则。日常中，咱们提到设计准则都会将其简化为「SOLID」，对应于繁多职责准则（Single Responsibility Principle）、凋谢 / 关闭准则（Open Closed Principle）、里氏代替准则（Liskov Substitution Principle）、最小晓得准则（Law of Demeter）、接口隔离准则（Interface Segregation Principle）和依赖倒置准则（Dependence Inversion Principle）。设计模式又包含了单例模式、策略模式、代理模式、迭代器模式、公布 - 订阅模式、命令模式、组合模式、模版办法模式、亨元模式、职责链模式、中介者模式、装璜者模式、状态模式、适配器模式等。

对于设计准则和设计模式有很多优良的解说文章，这里就不过多赘述了。

四 1 + 1 > 2

1 非得用 useContext 吗

在 React Hook 工程中，一旦波及到全局状态治理，咱们的直觉会是应用 useContext。举个例子，假如工程中须要依据灰度接口返回的信息，决定某些组件是否进行渲染。因为整个工程共享一份灰度配置，咱们很容易就想到将其作为一个全局状态，在工程初始化时调用异步接口获取并进行初始化，而后在组件外部应用 useContext 来获取。

然而 createContext 的应用会造成一旦全局状态产生变更，Provider 下的所有组件都会进行从新渲染，哪怕它没有生产 context 下的任何信息。

认真想想，这种场景和设计模式中的“公布 - 订阅模式”有着殊途同归之处，咱们能够本人定义一个全局状态实例 GrayState，在 App 组件中初始化值，在子组件中订阅该实例的变动，也可能达到雷同的成果，并且仅订阅了 GrayState 变动的组件会进行从新渲染。

最终实现的成果是统一的，不同的是获取灰度状态后，仅仅依赖灰度配置信息的 GrayComponent 进行了从新渲染。

思考更好复用的话咱们还能够将对 Status 监听的局部形象为一个自定义 Hook：

当然，借助 redux 也是可能做到按需从新渲染，但如果我的项目中并没有大量全局状态的状况下，应用 redux 就显得有点杀鸡用牛刀了。

2 useState 还是 useReducer

Hooks 初学者经常会感叹“我开发中只用到 useStateuseEffect，其它钩子仿佛不怎么须要的样子”。这种感叹源于对 Hooks 的了解还不够透彻。useCallbackuseMemo 是一种在必要时刻才应用的性能优化钩子，平时接触较少也是有可能的，但 useReducer 却值得咱们器重。在官网的解释中，useReducer 是 useState 的代替计划，什么状况下值得代替呢，这里同样以一个例子来剖析。

举个状态模式中最为常见的例子 —— 音乐播放器的程序切换器。

在下面的实现中，能够看到模式的切换依赖于上一个状态，在“程序播放 - 随机播放 - 循环播放”三个模式中顺次切换。目前只有三种模式，能够应用简略的 if…else 形式实现，但一旦模式多了便会非常难以保护和扩大，因而，针对这种行为依赖于状态的场景，当分支增长到肯定水平时，便须要思考应用“状态模式”从新设计。

React 官网中对 useReducer 的解释中提到「在某些场景下，useReducer 会比 useState 更实用，例如 state 逻辑较简单且蕴含多个子值，或者下一个 state 依赖于之前的 state 等」。这里着重看一下后一个场景，「类的行为是基于它的状态扭转」的“状态模式”就是一种典型的依赖上一个状态的场景，这使 useReducer 人造的实用于多状态切换的业务场景。

3 自定义 Hook 封装准则

自定义 Hook 是 React Hook 广受欢迎的重要起因，然而一个形象不佳的自定义 Hook 却可能极大减少了保护老本。在《The Ugly Side of React Hooks》“The hidden side effect”章节中就列举了一个层层嵌套的副作用带来的异样排查老本。咱们常常说设计准则和设计模式有助于进步代码的可维护性和可扩展性，那么有哪些准则 / 模式可能帮忙咱们优雅地封装自定义 Hooks 呢？

OS：“如何优雅地封装自定义 Hooks”是一个很大的话题，这里仅仅抛转引玉讲述几个观点。

第零要义：存在数据驱动

在比拟 Hooks 和类组件开发模式时，经常提到的一点就是 Hooks 有助于咱们在组件间实现更宽泛的性能复用。于是，刚开始学习 Hooks 时，对于任何可能有复用价值的性能逻辑，我常常矫枉过正地封装成奇奇怪怪的 Hooks，比方针对「在用户敞开告诉且当天第一次关上时，进行二次揭示关上」这么一个性能，我形象了一个 useTodayFirstOpen：

事实上，它并没有返回任何货色，在组件内调用时也仅仅是 useTodayFirstOpen()。回过头来，这块性能并没有任何的内部数据流入，也没有数据流出，齐全能够将其形象为一个高阶函数，而不是一个自定义 Hooks。因而具备复用价值且与内部存在数据驱动关系的功能模块才有必要形象为自定义 Hooks。

第一要义：繁多职责准则

繁多职责准则（SRP）倡议一个办法仅有一个引起变更的起因。自定义 Hooks 实质上就是一个形象办法，不便实现组件内逻辑性能的复用。然而如果一个 Hooks 承当了太多职责，则可能造成某一个职责的变动会影响到另一个职责的执行，造成意想不到的结果，也减少了后续性能迭代过程中出错的概率。至于什么时候应该拆分，参照 SRP 中举荐的职责拆散准则，在 Hooks 中更适宜解释为「如果引起两个数据变更的起因不是同一个时，则应该将两者拆散」。

以 useTodayFirstOpen 为例，假如外界还有 Switch 控件须要依据 status 做展现与交互：

const [status, setStatus] = useState();
const [isTodayFirstOpen, setIsTodayFirstOpen] = useState(false);

// ...

const updateStatus = async (val) => {const res = await updateUserStatus(val);
  // dosomething...
}

return [status, updateStatus];
}

假如 getUserStatus 的返回格局产生了扭转，须要批改该 Hook。

const [status, setStatus] = useState();
const [isTodayFirstOpen, setIsTodayFirstOpen] = useState(false);

useEffect(() => {
  // 获取用户状态
  const fetchStatus = async () => {const res = await getUserStatus();
    setStatus(res.notice);
  };
  fetchStatus();
  // ...
}, []);

// ...
}

假如再有一天，监管反馈每天二次揭示频率太高了，要求改为每周「二次揭示」，又须要再次重构该 Hook。

const [status, setStatus] = useState();
const [isThisWeekFirstOpen, setIsThisWeekFirstOpen] = useState(false);

useEffect(() => {
  // 获取用户状态
  // ...
  // 判断明天是否首次关上
  const value = window.locaStorage.getItem('isThisWeekFirstOpen');
  if (!value) {setIsTodayFirstOpen(true);
  } else {const curr = getNowDate();
    setIsThisWeekFirstOpen(diffDay(curr, value) >= 7);
  }
}, []);

// ...
}

这显然违反了繁多职责准则，此时须要思考拆散 status 和 …FirstOpen 逻辑，使其更加通用，再以组合的模式形象为业务 Hook。

革新之后，如果获取 / 设置用户状态的接口产生变动，则批改 useUserStatus；如果二次揭示的成果须要改变（如上报日志），则批改 useSecondConfirm；如果业务上调整了二次揭示逻辑（会员不二次揭示），则仅需批改 useStatusWithSecondConfirm，各自定义 Hooks 各司其职。

第 n + 1 要义致力摸索中……

五 总结

数据结构与设计模式可能领导咱们在开发简单零碎中寻得一条清晰的路线，那既然都说 Hooks 难以保护，那就尝试让「神」来援救这凌乱的场面。对于「设计模式是否有助于咱们写出更优雅的 Hooks」这个问题，看完后面的章节，置信你心中也有本人的答案，当然，本文并不是为了答辩「Hooks 是否强于类开发」这一话题，如果有趣味的话，欢送评论留言～

原文链接
本文为阿里云原创内容，未经容许不得转载。