何时应将React Hook的返回值作为属性传递而非重复调用Hook？

问题描述 #

有些React「只读型」Hook被设计为可在多处调用并返回相同信息，例如：

const myTheme = useTheme()   // From @mui/material
const myApp = useApp()       // From MongoDB Realm

这种情况下，直接在深层子组件中调用它们会比逐层传递myTheme或myApp更便捷。

但如果自定义「读写型」Hook内部包含可更新的状态，例如：

const myToDos = useToDos()

这类Hook通常应仅在应用（或每个用户等）中调用一次，否则会生成多个可独立更新的内部状态副本。

是否存在相关约定，能区分哪些Hook可安全地在多处调用，哪些只能调用一次并将结果传递给子组件？

我的疑问源于一次调试经历：因在不同位置重复调用自定义Hook，导致出现两个独立的内部状态副本，花费了大量时间才排查出问题。

核心区分约定与实践 #

1. 依赖外部共享源的Hook：可安全多处调用 #

这类Hook本身不持有独立状态，仅从外部共享数据源读取信息：

• 典型特征：内部依赖useContext、全局单例实例（如Realm App对象）或外部全局存储；多次调用时，返回的都是同一个共享源的最新值。
• 例子：useTheme本质是读取Theme Context，useApp是获取全局Realm实例，无论在哪个组件调用，结果完全一致。

2. 内部持有独立状态的Hook：需单例化调用 #

如果Hook内部使用useState、useReducer管理状态，每次调用都会创建全新的状态副本：

• 问题场景：自定义useToDos若内部用useState维护待办列表，在两个组件中调用会生成两份互不关联的待办数据，导致状态不同步。
• 解决方式：
  • 在顶层组件（如App或用户级根组件）调用一次Hook，通过Props或Context把状态和操作方法传递给子组件；
  • 把状态逻辑封装到Context Provider中，再写一个仅读取Context的自定义Hook（此时该Hook就变成了第一类可多调用的类型）。

3. 通过命名与文档明确规则 #

• 第三方库Hook：官方文档通常会明确说明调用限制，比如MUI的useTheme文档会标注它是Context读取工具，可在任意组件使用。
• 自定义Hook：通过命名区分职责，比如将单例状态型Hook命名为useToDosStore，明确它是状态存储；将仅读取的Hook命名为useToDos，用于读取Store Context。

4. 快速验证技巧 #

• 在Hook内部添加日志，打印状态初始化/更新事件，若多次调用时日志重复触发，说明会生成多份状态；
• 检查Hook代码：只要包含useState/useReducer，除非是为组件私有状态设计，否则都需要考虑状态共享的问题。

内容的提问来源于stack exchange，提问作者pancake