把 React 应用迁移到 ReasonML，并不是简单地换一种语法写同样的组件，而是借助 OCaml 的类型系统把组件边界、状态流转和副作用调用变成可验证的契约。ReasonML 的语法更接近 JavaScript 的阅读习惯，但底层是完全静态的 OCaml 类型，配合 BuckleScript 编译器可以输出干净的 JavaScript。迁移过程中你会看到，原本需要 PropTypes 或运行时检查才能发现的 props 类型错误，现在在编译阶段就会被拦截。本文从类型建模、组件重写、互操作三个角度拆解迁移路径，并给出可以直接落地的代码示例。
一、用OCaml类型系统重构React组件的输入输出
React 组件最核心的就是 props 和 state。在 JavaScript 中，props 的结构通常靠文档或 PropTypes 描述，运行时才会报错。ReasonML 的做法是把 props 定义为一个 record 类型，组件签名直接声明这个类型。比如一个用户卡片组件，可以定义 type props = { name: string, age: int, online: bool }，组件函数接收这个 record，编译器会强制调用方传入所有字段。类型不匹配时，BuckleScript 会在编译阶段输出错误，而不是等到页面渲染时才出现 undefined 异常。
这种约束带来的另一个好处是重构更安全。修改 props 字段名或类型时，所有调用该组件的地方都会立刻收到编译错误，不再需要全局搜索。OCaml 的变体类型还能描述有限的 UI 状态，比如 loading、error、success 三种状态可以用一个 variant 表示，配合模式匹配处理渲染分支。这比在 JavaScript 中用字符串或布尔值拼状态要可靠得多。模式匹配还会检查穷尽性，漏掉某个状态时编译器会提醒你。
二、用ReasonReact重写函数组件与状态管理
ReasonReact 提供了和 React Hooks 类似的 API，但类型标注更严格。迁移一个使用 useState 的计数器组件时，可以写成如下形式。ReasonML 中 state 的类型可以从初始值推断，但建议显式写出，方便跨模块理解。事件处理函数中的 setState 也受到类型约束，不能传入错误类型的值。
type state = int;
[@react.component]
let make = () => {
let (count, setCount) = React.useState(() => 0);
<div>
<p> {React.string("当前计数：" ++ string_of_int(count))} </p>
<button onClick={_ => setCount(count + 1)}>
{React.string("加一")}
</button>
</div>;
};
上面的代码中，React.useState 返回一个元组，模式匹配直接解构出当前值和更新函数。setCount 的参数类型被推断为 int，因此如果传入字符串会导致编译错误。ReasonML 的 JSX 语法和 React 类似，但表达式需要用大括号包裹，文本节点需要 React.string 转换。这种显式转换一开始会不习惯，但它避免了自动类型转换带来的隐藏 bug。
对于复杂状态，可以继续使用 useReducer。OCaml 的变体类型非常适合描述 action，例如增加、减少、重置。Reducer 函数中用模式匹配处理每个 action，返回新的状态。这种写法比 Redux 的 action 对象加 switch 语句更清晰，因为类型系统会确保所有 action 都被覆盖，不会漏掉分支。迁移时可以把 Redux 的 action 类型直接映射为 variant，reducer 逻辑几乎可以原样保留，只是去掉了字符串常量。
三、与现有JavaScript模块互操作：保留npm生态的关键
迁移不是推倒重来，大多数应用仍然依赖大量 npm 包。ReasonML 提供了外部声明机制，让开发者给 JavaScript 函数写类型签名。比如要调用 lodash 的 debounce，可以写一个 external 声明，把参数和返回值类型标注清楚。BuckleScript 编译时不会检查 JS 实现的正确性，但会检查 ReasonML 调用方是否遵守签名。这样既保留了 JS 库的能力，又获得了调用侧的类型安全。
[@bs.module "lodash"] external debounce: (unit => unit, int) => unit => unit = "debounce";
let handler = debounce(() => Js.log("触发"), 300);
handler();
外部声明还可以处理 React 组件库。比如使用 Ant Design 的按钮组件，可以用 [@bs.module] 和 [@react.component] 配合，把 Button 声明为一个 ReasonReact 组件。这样在 ReasonML 代码中就可以像原生组件一样使用，并获得 props 类型检查。对于事件对象、DOM 操作等场景，ReasonML 提供了 Dom 和 Webapi 模块，也可以自定义抽象类型。
互操作最需要注意的是可空值和对象类型。JavaScript 函数经常返回 null 或 undefined，ReasonML 用 option 类型表达这种不确定性。外部声明时需要把返回值写成 option(string) 之类的形式，调用方就必须处理 None 和 Some 两种分支，避免空指针异常。这让迁移后的代码在边界处特别健壮，但也要求开发者对 JS 库的实际行为有清楚认识。
四、迁移策略与编译性能：如何平滑推进
一次全量迁移风险很高，更实际的做法是从叶子组件开始。叶子组件依赖少、状态独立，适合先用 ReasonML 重写，然后通过外部声明或直接导入的方式暴露给 JavaScript 父组件。BuckleScript 生成的 JS 文件可以被现有打包工具正常识别，团队不需要更换 Webpack 或 Vite，只需要增加一个 Reason 编译步骤。迁移顺序可以是工具函数、纯展示组件、表单组件，最后才是全局状态和路由。
编译速度是 ReasonML 的明显优势。BuckleScript 采用增量编译，改动一个文件只重新编译相关依赖，大型项目的编译反馈通常在几百毫秒内。类型检查不会拖慢开发节奏，反而替代了一部分测试工作。不过要注意，ReasonML 的学习曲线集中在变体、模式匹配和模块系统上，这些概念对熟练 JavaScript 但没接触过函数式语言的开发者需要一个适应期。团队可以采用结对编程或先写类型声明再实现的方式来降低风险。
整体来看，迁移到 ReasonML 的收益并不是代码变短或运行变快，而是大量低级错误消失，状态逻辑变得可追踪。对于长期维护的中大型 React 应用，这种类型安全带来的维护成本下降会随着时间累积。迁移过程中生成的 JS 仍然可读，遇到问题时可以直接查看输出，调试体验不会断层。
