信息通路模型

Proto UI 定义组件的方式

在上一篇中，组件被理解为一种可以被协议化处理的交互对象。
接下来的问题是：

如果一个组件要被完整描述，最自然的切分方式是什么？

Proto UI 给出的答案不是从 API 列表开始，也不是从宿主实现开始，
而是先看一件更基础的事：

这个组件正在和谁交换信息。

这一篇要讨论的，就是 Proto UI 用来组织原型能力的基础视角：信息通路模型。

一个组件之所以成为组件，不只是因为它内部有状态、结构或逻辑，
还因为它始终处在关系中。

它会被人操作，被应用使用，被其他组件影响，也可能反过来影响外部。
如果把这些关系全部抹掉，组件就只剩下一段实现，而不再是一个可交互的单位。

因此，要描述一个组件，最自然的问题往往不是：

• 它有哪些函数
• 它有哪些字段
• 它在某个框架里怎么声明

而是：

• 它面对哪些对象
• 它和这些对象之间交换哪些信息
• 这些交换分别沿着什么方向发生

Proto UI 将这种观察方式称为信息通路模型。

在 Proto UI 中，组件至少会面对三类典型对象：

• User
• Maker
• Other Component

这里的“使用者”不是产品岗位，也不是团队分工。
它们是对组件交互关系的抽象。

User 指的是最终与组件发生感知和操作关系的对象。
通常就是产品中的终端用户。

组件对用户产生视觉、听觉、触觉或其他形式的反馈，
用户也会通过点击、输入、手势、焦点变化等方式作用于组件。

Maker 指的是把组件拿来组装、配置、消费的人或系统。
它不一定是“人”，也可以是应用代码、页面作者、上层业务逻辑。

在这个关系里，组件不是被直接操作，而是被设置、被读取、被接入更大的系统。

组件并不只和用户或使用者代码发生关系。
它还可能处在一个组件网络中，与其他组件共享环境、传递语义或建立协作关系。

因此，Proto UI 还需要面对第三类关系对象：其他组件。

这一类关系不一定总是显式的，也不总是像 props 那样直接。
但它同样构成了组件交互的一部分。

当组件与这些对象之间发生信息交换时，就形成了 Proto UI 所说的信息通路。

信息通路并不是一组 API 名字，
也不是文档层面的分类技巧。
它更接近一种组织原则：

先看组件在和谁交换信息，再看这种交换需要怎样的能力来表达。

从这个角度看，很多原本看起来不同的能力，其实都只是不同通路上的具体表现。

也正因为如此，Proto UI 并不是先枚举出一批能力，再去给它们找理由；
相反，能力的组织方式本身就是从这些关系中推导出来的。

如果按信息交换的方向来看，Proto UI 的几项核心能力会自然地出现。

用户和组件之间的关系，至少包含两个方向：

• 用户把信息带给组件
• 组件把信息反馈给用户

于是形成了两类核心能力：

• event：User → Component
• feedback：Component → User

event 负责描述用户如何作用于组件，
feedback 负责描述组件如何把状态和结果反馈给用户。

这两者并不是随意配对的能力名，
而是用户通路在两个方向上的自然展开。

组件被上层系统使用时，也同样存在两个基本方向：

• 上层把配置或输入交给组件
• 组件向上层暴露能力或结果

于是又形成两类能力：

• props：Maker → Component
• expose：Component → Maker

props 不是“某个框架恰好有 props”，
而是因为组件作为被使用对象，本来就需要接收来自外部组装者的信息。

expose 也不是附加功能，
而是因为组件并不只是被动接收，它还需要向外提供某些可消费能力。

当组件处在更大的组件网络中时，还会出现另一类关系：
它不直接面向最终用户，也不只是被 Maker 单向组装，而是处在某种共享环境或语义联动中。

Proto UI 将这部分能力收敛为：

• context

context 对应的不是单一方向上的一次输入输出，
而是一类更环境性的关系：组件如何感知自己所处的外部语境，并与周围组件形成稳定协作。

因此，context 的出现也不是为了补足 API 风格，而是因为组件网络本身构成了一条独立的信息通路。

从信息通路模型来看，feedback、event、props、expose、context 并不是任意挑选出来的几个高频词。

它们之所以成为 Proto UI 的核心子能力，是因为：

• 它们分别对应组件与典型关系对象之间的信息交换
• 这些交换并不是某个框架特有，而是组件作为交互对象时反复出现的基础关系
• 如果缺少其中某一部分，组件的描述就会在某个方向上明显失真

换句话说，这组能力不是从实现习惯中整理出来的，
而是从“组件必须如何与外部发生关系”这个问题中推导出来的。

这也是为什么信息通路模型不只是分类技巧，
而是 Proto UI 组织原型语法的基础。

信息通路解释了组件与外部之间的大部分交换关系，
但它仍然不足以覆盖组件的全部。

一个组件除了“和谁交换什么信息”之外，
还存在一些并不直接属于外部交换关系的内部维度，例如：

• state
• lifecycle
• meta

它们的作用并不完全相同：

• state 处理组件内部的状态性
• lifecycle 处理组件在时间与执行阶段中的秩序
• meta 处理组件的自描述与额外语义

这些维度不能简单地被并入某一条信息通路，
但它们同样是原型成立所必须面对的组成部分。

因此，Proto UI 对组件的定义并不只有“通路”，
而是在信息通路之外，还保留了一组独立的内部维度。

可以。

信息通路模型并不是封闭的。
如果组件面对了一类新的、稳定的、足够重要的关系对象，那么新的通路就可能成立。

例如，组件与宿主本身之间就可能存在一类更直接的关系。
它可能涉及平台能力、系统环境、设备偏好，或者其他并不适合归入 User、Maker、Other Component 的交换方式。

Proto UI 可以承认这种方向存在，并把它视作潜在的 host 通路。

但在默认情况下，Proto UI 不会把这类高度依赖宿主的能力当作跨平台原型的主轴。
原因并不复杂：

宿主越具体，通用性越弱；
越靠近宿主本身，越难成为跨宿主协议的一部分。

因此，信息通路模型是开放的，
但 Proto UI 对哪些通路应当进入核心原型，仍然会保持审慎。

为了保持主线清晰，这一篇不会继续展开：

• 各条通路的正式契约
• 每个子能力的具体 API
• 原型应当如何拆分
• 哪些能力在执行阶段如何受约束

这些问题会在后续章节中分别讨论。

如果信息通路模型成立，那么接下来的问题就会变成：

当一个组件包含这么多关系与维度时，哪些部分应该被放进同一个原型，哪些部分应该被拆开？

这正是下一篇 原型边界 要讨论的内容。