给选项改名之前,先留下数据库里的稳定键

摘要| 一张订单上的客户改了名字,关联关系该跟着谁走?从稳定键、显示名称和交易快照三个值出发,拆解远程下拉框的历史回显、旧数据兼容与异步覆盖问题。
✦ 一张旧订单,三种不同的名字
订单创建时,客户叫“青屿工作室”;几个月后,它更名为“青屿设计”。打开订单,客户框应该显示新名字还是旧名字?这个问题没有一个适用于所有字段的答案。客户关联要认得同一个对象,当前联系卡要展示今天的名称,历史凭证可能需要保留成交时的称呼。先确定字段表达什么事实,再决定保存哪个值。
先把三个值拆开| 稳定键回答“是谁”,当前名称回答“现在叫什么”,快照回答“当时写了什么”。同一个业务可能同时需要三者。

确定性示意图:身份、当前名称和历史快照各有职责
我在分析 Microi吾码AI 的选择类控件时,把注意力放在这条看似很小的映射链上。AI可以协助生成字段配置,却不能替业务决定历史订单是否允许随主数据改名。否则界面看起来更友好,历史事实却被悄悄重写。
✦ 让Key稳定,把Value留给阅读
字典的选项可以是“draft / 草稿”,客户的选项可以是“cust-018 / 青屿设计”。左侧是机器使用的标识,右侧是人阅读的文字。名称容易变化,身份应尽量稳定。把展示文案同时当唯一键,会在重名、翻译、简称和更名时暴露脆弱性。
{
"DataSource": "KeyValue",
"SelectLabel": "Value",
"SelectSaveField": "Key",
"SelectSaveFormat": "Text"
}
[
{ "Key": "draft", "Value": "草稿" },
{ "Key": "confirmed", "Value": "已确认" }
]
这是一段配置示意:保存draft,展示草稿。它不是本轮向数据库执行的迁移。已有字段不会因为补上一句配置就自动完成数据清洗。如果原数据只保存中文名称,应先盘点重复名称、历史异常和引用关系,再制定可回读的迁移规则。
改文案与改身份| 把“草稿”改成“待确认”,通常是展示变化;把draft改成pending,涉及标识迁移,需要检查所有引用。
✦ Text与Json,比较的对象也不同
远程选择控件拿到的候选项可能是对象,表单实际保存的值却可能只有一个字符串。Text格式按配置字段保存文本;Json格式则需要处理对象身份。把两种情况混在一起,很容易出现选项已加载、文本却选不中的状态。

源码链路示意:配置身份字段、加载候选、合并当前已选值、渲染回显
当前实现中的resolveTextSelectValueKey先看保存格式,再从SelectSaveField与SelectLabel取配置值。它的选择不依赖候选数组有没有加载完成。比较字段在异步加载前后保持一致,可避免界面开始用名称比较,数据到达后突然改用Id。这里描述的是对应工具函数及选择控件调用链,其他控件仍要按自己的实现核对。
- Text:按实际保存字段比较,不凭对象里刚好出现Id就更换规则。
- Json:保留对象形式的兼容逻辑,不能直接照搬Text的字符串比较。
- 数字0可能是有效键;空值判断不应把它误判成没有选择。
✦ 历史选项不在这一页,也能有明确回显
远程搜索只返回当前查询的候选项。旧订单关联的客户可能不在本页,也可能已停用。当控件用新结果直接替换所有选项时,历史值容易看起来像丢了。当前mergeCurrentSelectOptions的处理是:以本次远程结果为基础,再补回表单当前已保存或已选择的值。
补回的是当前选择| 历史回显服务于理解这条记录;它不意味着把旧搜索池里的所有选项重新变成可选,更不代表用户获得新的操作权限。
这段实现会兼容文本、对象、数组以及可解析的JSON字符串,并按标识去重。它只保留当前选择,避免把上一次搜索里毫无关系的对象带到新列表中。如果保存的旧值只有一个Id,没有名称,兜底回显也只能保留可识别的键,不能凭空恢复已经丢失的历史称呼。
- 显示停用客户时,可以明确注明“历史关联”。
- 新增选择继续以服务端当前授权数据为准。
- 提交时由服务端复核状态、归属和操作权限。
✦ 旧请求晚到,不能覆盖新选择
用户先搜索“青屿”,随后搜索“青山”。第二个请求先完成,第一个请求却最后才到。如果界面接受所有响应,列表会倒回旧查询。当前选择控件在完成加载时,会检查组件是否已销毁以及请求标识是否仍是最新;过期响应不继续写回候选数组。
这个保护说明了异步数据也有归属。复杂联动还应结合表单实例、记录身份、依赖字段和当前选择进行核对。不要把单个控件的请求标识保护推广成整个系统所有异步操作都已得到保证。AI生成联动脚本时,也要把这些条件作为设计输入,而不是等出现闪回再追加零散补丁。
const resultBelongsToCurrentQuery =
responseRequestId === currentRequestId;
if (!resultBelongsToCurrentQuery) return;
上面是解释请求归属的伪代码,不是直接粘贴到接口引擎的生产实现。真实组件还需要处理销毁、失败和loading清理。
✦ 当前名称和历史快照,要同时讲得通
官方数据源文档还提出一个业务取舍:当交易需要保存当时的名称时,保留名称文本,并另存关联Id。这与稳定键原则能够同时成立。客户Id保持关联,客户名称快照保留成交时事实;查看当前客户信息时,再通过Id读取今天的主数据。

确定性示意图:同一稳定Id连接当前资料,订单另外保存成交时名称
设计快照,而非猜测| 交易快照应在创建或确认交易的受控时点形成。历史凭证是否允许修改、谁能修改、修改如何审计,属于业务规则。
应避免一边要求历史凭证原样保留,一边又把所有名称字段实时覆盖为最新值。快照可能包含名称、地址、税号等多个字段;哪些值必须留存,需要结合实际业务确定。本轮没有执行数据库写入,也没有声称已经替任何客户完成字段迁移。
✦ 五项测试通过,结论有边界
本轮实际执行了当前工作区已有的五项专项测试,五项全部通过。覆盖Text比较字段在加载前后保持稳定、Json对象比较、远程结果外当前已选项保留、旧格式去重,以及不带入无关旧搜索项。这是工具函数层的验证结果。

根据实际执行回执排版的测试结果,非产品界面截图
- 通过:现有五项Node专项测试。
- 未由这些测试证明:浏览器全部操作、客户线上数据质量、数据库迁移或权限配置。
- 后续接入:按真实保存格式、数据源和字段配置验证一条更名记录及一条历史停用记录。
AI辅助开发的价值在这里很具体:帮你把“下拉框不好用”拆成保存值、比较键、候选范围和请求归属,再寻找对应源码和测试。最后还要有人确定历史事实的表达方式。文中已标注的概念图由AI生成;源码与实测证据均来自当前工作区。参考:Microi官方数据源说明与选择类组件配置。
更多推荐




所有评论(0)