共计 3421 个字符，预计需要花费 9 分钟才能阅读完成。
本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一工夫和你分享前端行业趋势，学习路径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi，蕴含一线大厂面试残缺考点、材料以及我的系列文章。
快来收费体验 ChatGpt plus 版本的，咱们出的钱
体验地址:https://chat.waixingyun.cn
能够退出网站底部技术群，一起找 bug.
这篇文章《Where Did Hooks Come From?》次要探讨了 React Hooks 的起源和背景。在引入 Hooks 之前，React 类须要扩大 React.Component 或 React.PureComponent，而 React 自身没有提供共享代码的 API。因而，React 社区开发人员创立了两种无效共享组件代码的模式，别离是高阶组件（Higher Order Components，简称 HOC）和 Render Props。这些模式在肯定水平上解决了代码重用的问题，但依然存在一些局限性。为了更好地解决这些问题，React Hooks 被引入，为开发者提供了一种更简洁、易于了解的形式来共享和重用组件的逻辑。
上面是注释~~
Hooks 是用于在组件之间共享通用逻辑的。明确地说，咱们所说的“逻辑”并不是指组件的 UI 局部（JSX）。咱们议论的是组件中 JSX 之前的所有内容。在基于类的组件中，咱们会说它在生命周期办法和自定义办法中。在性能组件中，它只是 JSX 之上的货色。
在某种程度上，Hooks 的故事与 React 及其先前用于共享代码的 API 的故事密切相关。所以请急躁听我从头说起 …
2013：第一个 React API：
React 开发者不喜爱 mixins，这是共享逻辑的第一个 API。
最后，React 有一种在组件之间共享通用逻辑的办法，称为 mixins。这是在 JavaScript 领有类之前的 React 晚期。这些伪类看起来的组件容许“混入”可共享的逻辑。过后，mixins 被指摘为社区开始风行的一些反模式的根本原因。因而，当 React 在 2016 年取得真正的类时，大多数 React 开发人员为 mixins 的 API 隐没而欢呼。
2016：类组件
在 JavaScript 在 ES2015（ES6）中取得类之后，React 很快跟进了明天依然能够应用的类组件。然而，如果你对 React 较为生疏，可能会想晓得为什么普遍认为应该在 React 中完全避免应用类组件？
次要起因是共享逻辑艰难。当咱们失去了 mixins 时，咱们也失去了一种原始的共享代码形式。咱们能够通过创立一个新组件来共享 / 重用 UI，以共享 JSX，然而没有内置办法能够共享生命周期办法，例如 componentDidMount、componentDidUpdate 和 componentWillUnmount。
这些特定办法是咱们可能心愿治理组件副作用的中央。因而，如果您用某个副作用编写 ComponentOne，咱们将不得不将该逻辑复制到 ComponentTwo，从而使逻辑无奈以一种只编写一次的形式形象。
咱们不能用继承吗？
class ComponentOne extends SharableStuff {// ...}
class ComponentTwo extends SharableStuff {// ...}不，React 不容许咱们编写从其余组件继承的组件。而且，即便 React 容许你这样做，你将如何将多个逻辑体共享到 ComponentOne？不容许多重继承，所以这不起作用：
class ComponentOne extends SharableStuffA extends SharableStuffB {// ...}React 类必须扩大 React.Component 或 React.PureComponent，并且 React 自身没有共享代码的 API。
社区尽管很聪慧。React 开发人员创立了两种模式，无效地在组件之间共享代码，这两种模式被称为高阶组件（Hoc）和 Render Props。
无状态函数组件
在同一期间，React 团队发表了一种应用函数而不是类来创立组件的新办法。过后的次要想法是领有一个仅承受属性并能够返回 JSX 的组件。没有状态或应用相似于类生命周期办法的 React API 的能力。
咱们称之为 无状态函数组件，因为它们也不能有状态。
不久之后，React 团队通知咱们不要这样称说它们。咱们应该称之为 函数组件，因为 … 他们有打算🤔
2018 Hooks
从实质上讲，Hooks 只是咱们能够从函数组件中调用的函数。咱们能够应用内置的钩子并编写本人的：
- 内置钩子：这些 API（如
useState()）使性能组件可能“挂钩”到 React 的所有性能。 - 自定义钩子：这些只是咱们编写的实现内置钩子的函数。自定义钩子的个别概念是为任何想要应用它的组件创立可重用的逻辑。
React 有 useState()，因而函数组件能够领有与类状态相似的本人的本地状态。然而，如果刷新页面，所有本地状态都会重置（就像任何其余 JS 变量一样）。因而，咱们能够创立本人的 useLocalStorageState()，它可能的工作形式与 useState() 完全相同，但还将状态放弃到 localStorage ，以便在刷新后复原值。
上面是一个应用自定义钩子共享数据获取逻辑的示例。你不用齐全理解如何应用 useState 和 useEffect，只须要理解它们为组件执行一些逻辑，我想共享它。如果另一个组件也想依据 productId 获取产品，那么须要从新编写上面高亮的代码：
这里是雷同的逻辑移至自定义钩子。当初任何组件都能够应用 useFetchProduct 钩子：
// Custom Hook
function useFetchProduct(productId) {const [product, setProduct] = useState(null)
useEffect(() => {fetchProduct(productId).then((product) => setProduct(product))
}, [productId])
return product
}
function BrowseProducts({productId}) {const product = useFetchProduct(productId)
// return <div>...</div>
}这是一个过于简化的例子，下面的 useEffect 代码是不残缺的。如果你想要一个获取数据的自定义 Hook，举荐来自 React Query 的自定义钩子，名为 useQuery()。
现在，如果你违心，你依然能够应用类。如果你感觉它们更容易应用，那齐全取决于你。然而，在类之间共享逻辑时，你将会遇到问题。即便你能够承受这些问题，并且你不感觉高阶组件（HOC）和 Render Props 凌乱，与过来五年开始学习 React 的其余开发者单干或者组队工作时，你可能会发现艰难。
他们在 Hooks 被当作 React 次要办法传授时开始接触 React。他们可能不理解类组件的“进退两难”，如何解决这种奇怪的作用域问题，以及何时以及如何应用 HOC 或 Render Props。此外，React 生态系统中绝大多数第三方库曾经放弃了 HOC 和 Render Props，转而采纳了 Hooks。因而，你将无奈轻松地应用它们的工具，因为 Hooks 仅实用于函数式组件。
我的一些敌人曾经应用 React 很长时间了，他们记得这些探讨和衡量。然而我留神到（至多在 Twitter 上），历史正在重演。有一整代新的 React 开发者不晓得这个背景故事，也不晓得咱们为什么要有 Hooks。我抵赖，Hooks 的某些局部比类更难，比方咱们可能须要记忆化（useMemo 和 useCallback），但这是一种衡量。你能够抉择应用带有 HoC 和 Render Props 的类（也不容易），或者应用具备轻松共享代码能力的 Hooks，但须要了解记忆化的复杂性。
代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。
交换
有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。
