一、背景：只有“读”的绑定，是半个绑定

痛点：表单只能展示状态。但使用者修改后状态不更新，导致 UI 与数据不同步，使用者体验极差。

在做这个功能之前，我的引擎其实已经有“绑定”了——表达式绑定：

{ componentName: 'Text'。props: { text: '{{state.username}}' } }

resolveProps 会在渲染时求值，state.username 变了重渲染后 Text 组件显示新值。话说回来，

但换成表单，比如给 Input 绑 value: '{{state.username}}'修改表单的 value。Text 组件里面的 state.username 却不动。

"受控组件"有两条路：

方向	说明	现状
读	数据 → 组件value: '{{state.username}}'	已支持
写回	组件输入 → 数据（使用者输入 → 写回 state.username)	缺失

受控。就是补全写回:让这个字段始终以 state 里的值为准，读、写都落在同一条 state 方法上，形成 state ↔ 组件 的闭环。其实，

二、Schema 里怎么设计受控绑定

痛点：Scheam 中没有统一声明“双向”语义。导致开发者需要在多个位置手动维护读取与写入逻辑，可维护性差。

我的分层一直是：Scheam 声明→ Runtime 解释 → Renderer / 物料在各端适配。Scheam 中加入受控声明，用节点上的 一行完成「双向绑定」：

interface Schema {
model?的观点是，string // 受控绑定方法，如 'state.username'
}

用法示例的观点是，

{ componentName: 'Input'。model: 'state.username',props: { placeholder: '请输入' } }

Runtime 在解析 model 后会展开成「读当前值 + 写回函数」。读取时通过 ctx.get 找到对应值；写回时通过对称的方法写入，同一处数据源保证闭环。

三、架构主要：Runtime 层归一化

Pain Point: 不同框架的事件模型各异。如果把 DOM/框架细节埋进 Runtime，会导致跨端实现困难。怎么说呢，

The core idea is to let Runtime only deal with **path** and produce a plain value + onChange callback,while Renderer/Material handles framework‑specific prop names and event extraction.

说到Schema，{ componentName: 'Input'。model: 'state.username' }
│
runtime 解析
│
归一化产出的观点是，value = ctx.get
onChange = => ctx.setOnPath
│
↑ 收的是"原始值"
┌───────┴───────┐
React Material Vue Material
value + onModelChange :value + @input
从 e.target.value 从事件取原始值

The generated onChange 参数必须是 **原始值**，而不是完整的 DOM event。其实，这样 Runtime 与 UI 框架彻底解耦。只负责「方法」上的读写，

model: 'state.username'

	事件绑定	表单绑定
Scheam 声明	events: { onClick: 'handleClick' }

runtime解释{ onClick:=>fn{ value。onChange } Renderer层 engine-core不碰 DOM ✅️✅️

• 事件 : 回调 → Renderer 接到对应事件属性
• 表单 : value + 写回方法 → Renderer 注入相应 prop / event

四、技术方法：从 model 声明到双向绑定的完整闭环

从写回对称来看，setOnPath

痛点 :当前实现的写入只落在本地 ctx，导致输入后 UI 弹回旧值，闭环失效。

• 沿父链向上找已有 key 的 scope ✅︎
• 只写本地 ctx ❌︎

/* 沿 parent 向上找第一个已有 key 的 ctx；若不存在则用链顶 */
resolvePathOwner:RuntimeContext{/...*/}

/** 与 get 对称：写到 resolvePathOwner 返回的 scope */ setOnPath:void{ this.resolvePathOwner.set }

resolveModel：受控组件的解释器

ts export function resolveModel( 说到schema。Schema,ctx: RuntimeContext,): ResolvedModel | undefined { if return undefined;其实，const path = schema.model;return { 说到value，ctx.get。// read – 向上找 onChange:=>ctx.setOnPath // write – 对称方法 };}

resolveSchemaNode 会把 resolvedModel 注入节点结果中供 Renderer 使用。设计态 不实现受控逻辑，只负责编辑。

写回后的重渲染链路

scss 使用者输入 → onModelChange ↓ setOnPath ↓ ctx.set ↓ notifyUpwardRendererRoot → rerender → UI 更新

该链路复用了已有的数据变化→UI 更新调度程序，仅多了一个统一入口 setOnPath。

说到物料层。 值形态无关

痛点 :不同组件返回值形式不同，若把这些细节硬编码进 Runtime，将导致 困难。其实，

组件	值 prop	值形态	事件取值
	value	string	e.target.value
checked	boolean	e.target.checked
value	数组 自定义聚合逻辑

对于 CheckboxGroup，没有统一的 e.target.value物料自行计算新数组后调用 onModelChange

ts // value 为当前选中的 opt.value 列表 function onToggle{ onModelChange( value.includes value.filter // 删除 : // 添加 );}

分层职责

• Runtime : /produces {value。 onChange}，不关心类型或 DOM。
• Renderer : /根据 meta 声明将 value 注入对应 prop，并把 onModelChange 接到统一事件。
• 物料 : /读取自身 prop。从框架原生事件抽取原始值，接下来调用 onModelChange。

举例 Input：

tsx const Input = =>( onModelChange?.} {...rest} /> );

这种结构让新增 Radio、DatePicker、Switch 等仅在物料层实现对应 prop/event。即可获得完整双向绑定，而无需改动 engine‑core。

五、成果展示

• Input 输入即更新 state.username，页面其他引用该状态的 Text 实时同步。
• Checkbox 勾选/取消实时同步到数组状态。按理说，
• 嵌套结构下一样保持闭环。无需额外手动同步代码，

六、 & 使用者痛点回顾

主要收益 :

• /完整的数据流程 :/从 UI 到 state 再回到 UI，一次声明即完成双向同步。
• /分层清晰 ：Schema 声明 -> Runtime 解耦 -> Material 实现。各层职责明确，可维护性明显提高。
• /跨框架统一 ：同一套 model + resolvedModel 在 React/Vue 等多端复用，无需重复实现。

Pain Points 已经被解决：

从未来工作方向来看，

局部变量写回机制完善；
更多受控物料快速接入；
表单校验与提交等高级能力逐步叠加，使低代码表单程序真正完整。

---