Hooks 和 HOCs 是不同的编程模型，比较它们就像比较橙子和苹果一样。

TL; 博士

根据经验，当我想要组件的条件渲染（如果条件：渲染 A，否则渲染 B）时，我使用 HOC，否则，我使用钩子。这只是我的意见。

优点缺点：

HOC 优点

• 轻松地将所有逻辑与 UI 组件分离（请参阅重构）。
• 易于作曲。
• 在任何渲染之前操作组件。

HOC 的缺点

• 名称冲突 - 2 个 HOC 可以使用和设置同名的props。
• React dom 是巨大的。
• 父属性的每一个变化都会导致子属性重新渲染——这是 React 中的默认行为，但是当我们有很多 HOC 时，我们需要非常小心。
• 类型 - 从组件的角度来看，很难理解我们得到了哪些 props 和类型。
• 使用 HOC 会将所有 props 传递给 child，即使 child 只需要来自该特定 HOC 的 prop x。
• 使用依赖于 HOC 的组件props的参数的过程可能很复杂

HOCs Pro & Con

• 无需定义变量，只需用 HOC 包裹，您将获得 HOC 提供的props - 这使我们的 UI 组件“猜测”props的名称。

钩子的优点

• 可读性和声明性。
• 性能 - 仅在更改特定props时更新。
• 成长中的社区。

钩子的缺点

• 仅在组件内 - 这意味着不能通过传递的props条件渲染组件。
• 包含 UI 和逻辑的巨型组件文件。

并且根据React FAQs hooks可以用作renderPropsand的替代HOCs，但可以与它们共存

通常，渲染props和高阶组件仅渲染一个子组件。我们认为 Hooks 是一种更简单的方法来服务于这个用例。这两种模式仍有一席之地（例如，虚拟滚动组件可能有一个 renderItem props，或者可视化容器组件可能有自己的 DOM 结构）。但在大多数情况下，Hooks 就足够了，可以帮助减少树中的嵌套。

Hooks 允许在功能组件中有状态逻辑，并且类似于 React 中的类组件。

钩子更难管理，因为你必须查看实际的组件代码才能看到它。

并非如此，因为您可以在自定义钩子中提取您的 HOC 或 renderProps 中的自定义逻辑并查找其实现，而不是了解实际组件中实际发生的情况。

我经常看到的一件事是在组件中使用带有副作用的钩子。这会使您的组件更难测试，并且对于钩子来说不是一个好的用例，恕我直言。

例如，您使用一些自定义创建一个组件，const {data, loading, error} = useFetch(endpointUrl)然后直接return <>{data.name}</>在同一组件的渲染部分中使用它。

对我来说，这仍然是 HOC 的一个用例。在 HOC 中加载数据，将其作为属性提供给静态转储组件。通过这种方式，您可以更轻松地测试组件，并且仍然可以分离关注点。