Cristina Rosu：用 Incr_dom 和 OCaml 构建动态 Web 应用

在 Jane Street，我们设计了 Incr_dom，让内部网页界面更容易用 OCaml 编写。我会先解释它的主要思想，再构建一个小应用，展示这些思想如何结合。

我们的许多工程工作涉及交易系统，但也经常需要界面让用户查看和修改大量数据。我们希望能够编写网页界面，又不必让每位开发者都成为 Web 专家。

一个模拟交易系统界面说明了这个问题：它有 10,000 行，每秒变化几十次。用户可以移动焦点、编辑单元格、筛选标的并按列排序；数据变化也可能改变行的顺序。

相关数据变化时，排序和筛选必须作出响应。为提高渲染效率，示例使用部分渲染：只实际渲染当前视口中的行，用户滚动时再增加或移除行。这项技术经常与 Incr_dom 配合使用，但并非库本身的一部分。

我们的目标是让网页界面易于编写、维护和优化。我们希望开发者无需深入学习 JavaScript，就能为现有系统添加界面，而且在面对大量频繁变化的数据时，界面仍能保持响应。

Incr_dom 借鉴了已有思想，尤其是 React 和 Elm。React 是用于构建交互界面的 JavaScript 库，Elm 则是专为界面设计的函数式语言；这个框架将两者的思想与 OCaml 工具结合起来。

第一块基石是 js_of_ocaml，它将 OCaml 字节码编译为 JavaScript，使 OCaml 能在浏览器中运行。这样客户端和服务器就能共享代码，后端改动更容易传播，编译错误也更容易发现。

我们还可以复用多年积累的 OCaml 库和工具，以及开发者已经掌握的语言知识。类型安全、表达能力等优点也因此适用于网页界面。

Elm 架构提供了一种组织应用的模式。它类似模型—视图—控制器：模型表示应用状态，视图展示状态，动作描述模型可能如何改变。

视图由模型生成。按钮点击或文本输入等事件处理器会调度动作；应用动作后产生新模型，再由此构建下一个视图。

这样的分离让每个部分都有明确职责，也让视图成为声明式的：程序员只需描述新视图应该是什么样，而不必列出修改旧界面的具体步骤。

由 Incr_dom 管理的应用需要提供模型和动作类型，以及 apply_action 和 view 函数。框架负责调度并连接各部分；apply_action 接收模型和动作，返回新模型。

最初看起来，视图生成的是 HTML DOM，即与浏览器相连的一棵可变树。修改实际 DOM 可能触发浏览器中成本高昂的工作，例如重新计算样式、布局和重绘。

每次模型变化时都重建真实 DOM 并不现实。虚拟 DOM 通过保存轻量的内存表示来解决这个问题；修改它不会直接触发浏览器工作。

在差异与补丁示例中，旧虚拟树有 A、B、C 三个节点，新树增加了 D。比较两者会产生包含这一新增内容的补丁，随后只将补丁应用到实际 DOM。

我们的虚拟 DOM 库提供属性和节点。节点具有标签、属性及子节点，与 HTML 非常相似；body 等便捷函数可以简化 OCaml 语法。

返回虚拟 DOM，而不是重建真实 DOM，可以减少浏览器工作，但每次模型变化后重新创建整棵虚拟树，成本仍可能过高。这时就要用到 Incremental 库。

Incremental 支持以依赖图表示的自调整计算。输入变化时，可以重新计算其后代；如果重新计算的节点值与之前相同，截断机制就会停止继续传播。

在 Incr_dom 中，Incremental 让模型到虚拟 DOM 的转换更加高效。如果模型只有一小部分变化，计算就只需更新虚拟视图的相应部分。

类型为 alpha Incr.t 的增量值表示图中的一个节点，其值的类型为 alpha。Incr.map 根据一个父节点和一个函数创建节点，map2 则组合两个父节点。

let%map 语法是一种 PPX 展开，不会改变语义。增量值位于右侧，映射函数可用的普通值位于左侧；and 用来组合多个增量输入。

举例来说，给定三个整数输入节点，可以推导出它们的最小值和最大值。再用两个节点把这些值转换为虚拟 DOM 文本，得到一张准确反映结果与输入依赖关系的图。

在应用中，这些输入节点可以从增量模型中提取，再把它们的视图组合成一个 body 节点。由于每个视图节点都是模型的后代，截断机制很重要：无关模型字段变化时，未变的投影能够阻止不必要的下游重复计算。

Incr_map 建立在 Incremental 之上，用于处理键值映射。普通映射变换会产生新映射；对应的增量操作接收并返回增量映射，可以根据输入差异的大小更新输出。

展示可能原本用列表表示的行或单元格时，这一点尤其有用。现在视图接口接收增量模型并生成增量虚拟 DOM，不必每次变化时都重建全部内容。

演示从一个只有标题的页面开始。Dune 文件指定 OCaml 可执行程序、依赖、js_of_ocaml 编译和预处理器；HTML 包含生成的 JavaScript，CSS 提供基本样式。

OCaml 主文件实现应用接口和初始模型。起初模型与动作都是 unit，因此应用没有有意义的状态或行为。模型截断机制使用一个相等性函数，这里采用物理相等。

动作模块还指定序列化方式，以及哪些动作需要记录。单独的 State 模块保存服务器连接等命令式状态；模型则应保持不可变，以便 Incremental 按预期工作。

最初，apply_action 原样返回模型，view 创建一个简单的 body 节点。在 view 开头对整个模型做映射很容易理解，但每当模型变化，其下的所有内容都会重新计算。

应用还为其他必需的接口函数提供简单实现，并通过 Start_app.simple 启动。使用 Dune 构建并刷新浏览器后，更新后的标题确认编译出的代码正在运行。

我把 unit 模型替换成一个包含 100 个计数器的列表，初始值是 0 到 99 的随机整数。遍历列表生成表格行，每行包含索引和计数值；普通 CSS 提供边框和交替的行颜色。

计数值也可以决定自身样式：小于 10 的数显示为绿色，小于 100 的显示为蓝色，更大的数显示为红色。这些属性由普通 OCaml 代码计算，并能随数据变化而改变。

为了让表格具有交互性，我定义带索引的 Increment 和 Reset 动作变体。apply_action 对动作进行模式匹配，更新选中的计数器：Increment 加一，Reset 将值设为零。

事件处理器负责调度这些动作。视图接收 inject，它与 schedule 类似，但类型专为虚拟 DOM 事件处理器设计：单击使该行递增，双击则将其重置。

启动函数还会每秒约 20 次调度随机递增。浏览器中的数值会自行变化，单击递增，双击重置；对于 100 行，运行相当流畅。

为了测试规模，我让行数可以通过 URL 查询参数配置，默认值为 100。达到 30,000 行时，初次加载需要数秒，滚动变得卡顿，重置计数器也有明显延迟。

一位观众问，更换数据结构是否有帮助。我认为可能有帮助，并将列表换成映射，以便应用使用 Incr_map。不过，仅仅改变数据结构和相应调用，还不会让视图具备增量特性。

原来的视图在构建行之前会映射整个模型，因此即使只发生小改动，也会重新计算整个页面主体。我去掉这一映射，对增量模型使用 Incr.Map.mapi，并在需要普通值的地方映射得到的行。

重新编译后，第一次加载仍然很慢：Incremental 有助于更新已有计算，并不能免费完成初始工作。加载完成后，滚动以及点击或重置计数器都明显更流畅。

为了演示另一种增量映射操作，我使用 unordered_fold 添加所有计数器的总数。累加器从零开始；新增条目时加上其值，移除条目时减去其值。

总数显示在表格上方，计数器变化时仍保持响应。将行数设为 10 后，重置数值更容易让人看到总数按预期下降。

真实应用还需要其他技术。部分渲染只渲染可见元素，并用尺寸合适的占位元素代替屏幕外内容，可以改善初始加载；尺寸正确则能避免意外跳动。

让焦点行保持在视口中需要使用 update_visibility 和 on_display。前者在 DOM 变化、窗口调整大小或滚动后调用，可以测量焦点相对视口的位置；后者可以比较当前模型和之前的模型。

这种比较让应用在用户移动焦点时将其滚动到视口中，同时避免用户有意滚动到其他位置时又被拉回去，例如用户到搜索框输入文字时。

更大的应用可能需要在 view 之外使用增量计算。在交易界面中，排序后的行既用于显示表格，也用于决定焦点如何移动；派生接口允许 view 和 apply_action 共享这一计算。

这些部分共同满足了最初的目标：js_of_ocaml 支持复用 OCaml，Elm 架构提供简单的结构，虚拟 DOM、Incremental 和部分渲染等技术则帮助大型界面保持响应。

一位观众询问高阶组件，以及与 React、Reason 和 BuckleScript 的比较。我解释说，当时 Incr_dom 尚无明确的组件概念，虽然其模式可以组合，而且明确的组件方案正在开发。

我对这些比较对象的使用经验不足，无法给出明确评价。Incr_dom 让开发者能够控制增量性能；我听说 BuckleScript 可能落后于 OCaml 的版本，不过它生成的 JavaScript 比 js_of_ocaml 的输出更易读。

被问到 Elm 时，我说两种架构有许多共同思想，据说语言也很相似，但我对 Elm 了解不足，无法判断开发者转换起来有多容易。

一个关于大型虚拟 DOM 树的问题指出，获取映射数据的列表仍需要重建列表。我们已经注意到这一成本，目前没有针对性的解决方案；避免重建各个节点仍能节省工作量，而非常大的应用可能需要部分渲染。

另一位观众问哪些内容应放在 model，哪些应放在 state。只有模型用于生成视图，因此视图所需的全部信息都应放在模型中；模型必须不可变。服务器连接等可变资源则放在 state 中。

被问到图形和绘图时，我承认多个界面都需要它们，而现有的图形专用工具不足。构建更好的组件会很有帮助。

增量计算本身有开销，因此并非对每个小模型都一定值得使用。如果应用已经响应良好，增加增量机制可能弊大于利；需要通过实验了解其中的权衡。

关于调试和测试，我提到可以使用控制台日志，也可以考虑将虚拟 DOM 转成 HTML 进行检查。团队曾讨论改进测试工具，但尚未完全建成。

这场演讲主要关注客户端。与服务器通信时，Jane Street 使用基于 WebSocket 的 RPC；如果数据流推送更新的速度超过浏览器的处理能力，就可能出问题，因此有时轮询更合适。

对于异步请求，apply_action 会收到一个 schedule_action 函数，可用于稍后调度动作。与此同时其他动作可能运行，因此延迟动作执行时，模型可能已经变化。

这种竞态需要在应用层谨慎处理：应用异步调度的动作之前，应检查当前模型，确保该动作仍然合理。问答结束后，我感谢了观众。