何时使用命令式 API 与声明式 API

React 倡导声明式风格：您描述给定状态下界面应呈现的样子，React 则协调 DOM 使其保持一致。大多数行为通过属性和状态流动，而不是通过直接的 DOM 命令实现。

这种模型让界面更容易预测，因为渲染输出是状态的纯函数，而不是一系列手动变更的结果。

有些交互难以用纯声明式表达。以命令式方式让元素聚焦、在精确时刻触发动画，或驱动第三方 DOM 控件，通常都无法简洁地表示为状态的函数。

对于这些情况，React 提供了引用和命令式句柄等逃生机制；当声明式属性无法满足需求时，请谨慎使用它们。

命令式接口也有取舍。它们更难测试，因为您必须驱动方法并观察副作用；此外，它们还可能破坏让 React 应用易于理解的单向数据流。

命令式调用还往往会把行为分散到各个事件处理程序中，而不是集中在清晰的状态到界面映射中，从而提高维护成本。

请优先使用声明式接口，仅在处理交互和测量时使用命令式接口，例如聚焦、滚动、动画、媒体播放，以及读取尺寸或位置。

如果某件事可以建模为映射到渲染输出的状态，就采用这种方式。如果它是没有清晰状态表示的一次性操作，那么使用命令式句柄就很合适。

声明式模态框根据父组件持有的 isOpen 属性进行渲染，因此可见性由状态驱动。命令式模态框则暴露打开和关闭方法，将自身状态隐藏在句柄之后。

声明式版本更符合 React 的数据流，通常应优先选择；而当触发操作来自分散的事件驱动代码时，命令式版本可能更方便。

您可以通过更改表单的键属性，以声明式方式重置表单；这会让 React 使用默认状态重新挂载一个全新的表单，不需要任何命令式调用。

另一种命令式方案是在句柄上暴露重置方法。键属性通常更简洁，因为它依靠 React 的协调机制，而不是手动清除状态。

Next.js 路由器暴露了推送、替换和预取等命令式方法。在可能进行导航之前预取路由是一项操作，而不是渲染状态的一部分，因此采用命令式调用很自然。

这说明，即使是符合 React 惯用方式的工具，也会在某个操作本质上是于特定时刻触发的行为时使用命令式接口。

官方指导将引用和命令式句柄描述为逃生机制：只有在确实需要跳出声明式模型时，才使用这些工具。它们不是构建功能的默认方式。

保持这种思维方式可以避免过度使用：只有在确认属性和状态无法清晰表达某种行为后，您才应采用逃生机制。

在添加命令式句柄前，请询问：这能否表示为映射到界面的状态？如果可以，请保持声明式。它是否属于聚焦、滚动、测量、动画或第三方操作？如果是，使用命令式方式可能合理。

还请确认接口表面足够精简且有文档，并确认您不是仅仅为了传递本可以由属性承载的数据而使用引用。

真实应用会混合使用这两种方式。绝大多数逻辑保持声明式，仅为少数确实需要命令式处理的交互增加一层薄薄的命令式句柄。

取得这种平衡可以让代码保持可预测且易于测试，同时仍能在声明式代码无法触及的地方处理焦点管理、媒体控制和库集成。

选择适合使用命令式接口的场景。

React 默认采用由属性和状态驱动的声明式界面，这种界面可预测且易于测试。命令式句柄是处理聚焦、滚动、动画、测量和第三方 DOM 控制的逃生机制。

请比较声明式和命令式模态框，优先使用键属性重置表单，并记住 Next.js 路由器也会使用命令式方法执行操作。请让命令式层保持精简、有文档且确有必要。