Frond：面向应用依赖图的前端运行时

背景

现代前端应用的状态管理方案（Redux、Zustand、React Query、MobX、React Context）本质上都在回答同一个问题：值存在哪里？ 它们各自提供了不同的存储与更新机制——本地可变状态、服务端缓存、可观察对象或React组件树中的值传递。

然而，一个正在成长的前端应用所面临的真正挑战并非状态存储本身，而是运行时生命周期：服务之间如何依赖、当当前用户切换时哪些资源需要清理、进行中的请求如何中断。这些逻辑通常以"清单"形式散落在各个Provider、useEffect和手动的清理函数中，随着业务复杂度增长而变得难以维护。

Frond提出了一种新思路：将应用的运行时建模为一个显式的依赖图（dependency graph），由Effect驱动执行，React则回归其渲染层的本职。

核心内容

1. 运行时图模型

Frond将应用运行时抽象为一张图，其中每个节点（Node）代表一个具有明确生命周期的服务或资源。节点通过声明式规格（NodeSpec）定义其参数、依赖关系、身份标识（key）和驱动逻辑（driver）。

节点生命周期由Frond完全托管：React读取节点状态，MobX提供可观察性，Effect执行实际工作，而Frond负责决定节点何时存活、就绪、过期、释放或销毁。

2. 子图驱逐与自动清理

当用户身份发生变化时（如登出），所有依赖该用户的资源必须被清理。传统做法是在signOut函数中手动列举所有需要清理的服务，每新增一个用户级服务都必须记得添加对应清理行，否则会导致状态泄漏。

Frond通过**图所有权（graph ownership）**机制解决此问题：当SessionNode被驱逐时，所有依赖它的节点（如PresenceNode）会自动被驱逐。运行时执行节点的release逻辑、中断进行中的工作、清除就绪状态，并拒绝过期提交。

示例对比：

• 手动清理：在signOut中依次调用session.end()、localStorage.removeItem、queryClient.clear()、abortInFlightRequests()等，每增加新服务都需记得添加一行。
• Frond方式：调用controls.evict("selfAndDependents", "sign-out")，所有依赖节点自动执行其release逻辑，无需在调用方了解具体依赖细节。

3. 运行时边界与资源所有权

清理逻辑属于获取资源的节点本身。每个节点通过acquire获取资源，通过release释放资源，形成对称的运行时契约。例如PresenceNode在acquire时加入频道，在release时离开频道，登出逻辑无需感知presence服务的存在。

4. 端到端类型安全

Frond实现了从后端到React消费端的完整类型传播：

• 依赖携带类型：dep(ProfileNode)自动携带该节点的result类型
• 类型传播：依赖节点的类型自动流入当前节点的deps.x.result
• 消费端零注解：React组件通过useNode(BillingNode, {})获取节点时，node.plan的类型通过依赖链自动推断，无需手动类型标注

若后端使用tRPC、gRPC或OpenAPI等类型化方案，类型可沿整个运行时图传播至最终消费者。

5. 结构化错误处理

Frond将错误视为图中的另一种值流动，而非需要猜测的catch (e: unknown)。每个错误携带kind、tag、retryable标记及原因链（cause chain），依赖节点可明确知道什么失败了。

运行时自动遍历错误链生成可序列化的报告（包含指纹、标签、上下文、依赖聚合、运行时事件元数据），只需配置一次错误接收器（sink），所有错误即按图感知的分组方式路由到追踪系统，无需在每个组件中添加try/catch。

6. 状态与生命周期的分离

Frond明确区分了状态管理工具与运行时生命周期管理的职责：

| 层面 | 回答的问题 | 代表方案 | |------|-----------|---------| | 状态表面 | 值存在哪里？如何变更？ | Redux/Zustand（值、变更、选择器）、React Query（服务端缓存、失效、重试）、MobX（可观察领域状态）、Context（React中的值布线） | | 运行时契约 | 加载前需要哪些就绪条件？状态绑定到哪个键？依赖变更时谁取消进行中的工作