批次 1 燃尽(objectui#3167 / objectstack#4115)的遗留。该 PR 把 DashboardWidgetSchema 从"只声明 spec 22 个键中的 10 个"改为按引用派生,唯独 responsive 保留为 any,并在声明处写明了原因,没有擅自调和。
冲突
| 侧 |
responsive 的形状 |
| objectui 渲染器 |
按断点分的 record(每个断点一份配置) |
@objectstack/spec |
单个 responsive 对象 |
两者不是宽窄之别,是结构不同。强行取任一侧都会让另一侧的现有写法失效,所以需要产品决定。
三条可能的出路
- spec 侧改为按断点建模 —— 若"每个断点不同配置"是真实需求,这是正解,但要 spec 出版本。
- objectui 收敛到单对象 —— 若按断点配置实际没人用,这是最省的,但要先确认存量仪表盘里没有依赖。
- 确认为两层词汇 —— authored 层是单对象、runtime 层展开成按断点 record,那正解不是派生而是"枢纽 + 键集覆盖闸门"(参照 objectstack#4115 里
FormField 的论证:枢纽做翻译、闸门枚举 SpecSchema.in.shape 双向比对)。
判别法同样是那一句:这两者描述的是同一个对象,还是管道上下游的两个阶段?
在此之前
any 是有意的、写明理由的占位,不是遗漏。但它也意味着这个键当前完全不受校验——objectui validate 对 responsive 里的任何内容都放行,包括拼写错误。这是选项 3 若成立时要补的闸门所要解决的。
批次 1 燃尽(objectui#3167 / objectstack#4115)的遗留。该 PR 把
DashboardWidgetSchema从"只声明 spec 22 个键中的 10 个"改为按引用派生,唯独responsive保留为any,并在声明处写明了原因,没有擅自调和。冲突
responsive的形状@objectstack/specresponsive对象两者不是宽窄之别,是结构不同。强行取任一侧都会让另一侧的现有写法失效,所以需要产品决定。
三条可能的出路
FormField的论证:枢纽做翻译、闸门枚举SpecSchema.in.shape双向比对)。判别法同样是那一句:这两者描述的是同一个对象,还是管道上下游的两个阶段?
在此之前
any是有意的、写明理由的占位,不是遗漏。但它也意味着这个键当前完全不受校验——objectui validate对responsive里的任何内容都放行,包括拼写错误。这是选项 3 若成立时要补的闸门所要解决的。