Avue动态选择框联动刷新与字典机制实践

1. 为什么“动态刷新选择框”是个容易被低估的活表单里的下拉选择框静态数据谁都会写options一塞、v-model一绑收工。但一旦这个选择框的数据来源变成依赖关系——选了省份再出城市、选了部门再出岗位、选了类型再出模板——问题就全冒出来了什么时候触发刷新、刷新时旧值怎么处理、刷新过程中要不要禁用、接口返回慢的时候用户已经改了三次怎么保证最终一致。这些细节才是真正消耗时间的部分。我用 Avue 做过不少中后台表单这个框架的好处是把column配置和crud的增删改查收敛成一份声明式配置写起来快坏处也在这里因为它把很多行为封装在内部一旦遇到动态场景你会发现自己不清楚它内部到底在什么时候读dicData、什么时候重新渲染组件于是只能靠试。选择框type: select的动态刷新就是最典型的例子。这篇文章我想把这件事从头说清楚Avue 的字典机制是怎么工作的联动刷新有哪几种可靠做法异步接口和本地字典分别怎么处理多级联动怎么做才不会互相打架以及在实际项目里踩过的那些坑——回显丢失、清空失效、重复请求、下拉框闪一下又变回旧数据等等。适合已经上手过 Avue、但被动态选项折腾过或者准备踩坑的同学如果你只用过静态表单我也会从最基础的字典配置讲起不会跳步。先说结论定个调Avue 的选择框刷新本质上不是“刷新组件”而是“刷新字典数据并让组件感知到变化”。理解这句话后面所有问题都会变得好解释。2. 先把字典机制摸透再谈刷新2.1 dicData 和 dicUrl 到底谁在干活Avue 的select、radio、checkbox、cascader这类带选项的列选项数据统一挂在字典体系下。你在column里写的这几种属性最终都会汇入同一个地方dicData直接写死的选项数组格式是[{ label: 显示文字, value: 实际值 }]。dicUrl给一个接口地址组件自己去请求返回的数据结构通常要在props里说明字段映射。props用来告诉组件接口返回的数据里哪个字段是显示名、哪个字段是值、哪个字段是子级比如{ label: name, value: id }。关键在于dicUrl只在合适时机请求一次请求结果会被缓存到内部字典表里。这个“缓存”是很多人踩坑的根源你以为改了dicUrl它就会重新请求实际上如果地址没变、参数没变它可能直接用上次的结果。所以真正需要按参数变化刷新时光改dicUrl是不够的得配合下面要说的手段。// 静态字典的基本写法先建立直观印象 { label: 状态, prop: status, type: select, dicData: [ { label: 启用, value: 1 }, { label: 停用, value: 0 } ] }想拿到组件内部当前认的这份字典可以用 Avue 提供的能力去查但更稳的做法是我们自己维护一份数据源让dicData始终由我们赋值。只有数据源在自己手里刷新时机才可控。这是我踩了几次坑之后形成的习惯后面所有的方案都围绕这一点展开。2.2 选项刷新的三种触发时机动态刷新听起来抽象落到实际场景其实就三类触发点搞清楚它们你的方案选型会快很多。第一种是表单初始化时的依赖回填。比如编辑一条已有记录记录里存着省份 ID 和城市 ID页面打开就得先把省份选项拉出来、选中省份、再拉城市选项、选中城市。这是“串行两次请求”顺序不能乱。第二种是用户交互引起的联动。用户手动改了省份城市选项必须立刻清空并重新请求。这是最常见也最容易出问题的场景难点在于“清空旧值”这个动作。第三种是外部条件变化引起的整体重置。比如表单上面有个“业务类型”筛选业务类型一变下面一连串选项和已选值全部要重置。这种场景考验的是批量处理能力一个个清空太啰嗦容易漏。触发时机典型场景主要难点初始化回填编辑页数据回显串行请求的顺序与等待用户联动省市级联、部门岗位旧值清空与请求时序外部重置业务类型切换批量清空与初始值恢复2.3 一个必须先想明白的问题值先清还是数据先来这是我认为整个动态选择框里最需要提前决定的点它直接决定你后面代码的写法。假设用户选了城市 A然后把省份从“江苏”改成“浙江”。此时城市旧值 A 对浙江来说是无效的。你有两个选择先清空城市的值再请求新选项或者先请求新选项回来再校验旧值是否合法。我的建议是先清空值、再拉数据。理由很实际请求是异步的你在等待期间用户看到的是“城市有新选项但值还显示着江苏的某个城市”视觉上很怪而且如果用户这时候直接点保存会把脏值提交上去。先清空虽然会短暂出现空白但状态是干净的用户不会误解。代价是清空动作如果处理不当会误触发校验或触发额外的联动。所以清空要用组件提供的方式去改而不是硬改对象属性这部分在第 4 章会具体写。3. 方案选型几套做法各自的适用边界3.1 方案一dicData 整体替换最简单也最稳如果你的选项数据来自前端自己的请求不是 Avue 内部按dicUrl去拉最直接有效的做法就是拿到新数组后整体赋给对应列的dicData。因为dicData是响应式的赋值后组件会重新读取选项就变了。// 假设 option 是表单的 column 配置数组 async function reloadCity(provinceId) { if (!provinceId) { setDicData(city, []); return; } const res await requestCityList({ provinceId }); setDicData(city, res.data.map(it ({ label: it.name, value: it.id }))); } // 用一个函数统一改列配置里的字典避免到处写着重复代码 function setDicData(prop, list) { const col option.find(c c.prop prop); if (col) col.dicData list; }这套写法的好处是没有黑盒数据什么时候来、什么时候赋值、赋值成什么全在你手里出问题好查。而且它绕开了dicUrl的缓存逻辑不会出现“参数变了但没请求”的困惑。需要注意的一点是如果列的dicData一开始是通过dicUrl由组件自己拉取的你又在外部赋dicData两者可能混用导致行为不一致。我的做法是只要这个字段有动态刷新需求就别用dicUrl统一走手动请求 dicData赋值。规则统一了后面维护的人也不会误以为它会自动拉。3.2 方案二借 dicUrl 的动态拼接能省事但有前提dicUrl并非完全不能用于动态场景条件是让地址或参数真的随依赖变化。常见做法有两种一种是地址里直接拼参数另一种是给列加dicQuery之类的查询参数让请求带上当前条件。// 依赖变化后把参数拼进 dicUrl再强制节点重渲染 function refreshByDicUrl(provinceId) { const col option.find(c c.prop city); col.dicUrl /api/city/list?provinceId${provinceId}_t${Date.now()}; }那个_t时间戳是刻意加的目的是让地址每次不同避免命中内部缓存或被浏览器/中间层缓存。这种做法能跑通但我不太推荐作为主方案原因有三一是地址里塞参数不好看也不好调试二是缓存行为依赖内部实现版本升级后可能变三是请求失败的处理不在你掌控中错误提示和 loading 都难定制。提示如果你的项目里已经在用dicUrl拉静态不变的字典那就让它继续用不必全部改掉。只有当某个字段的选项会随其他字段变化时才把它切到手动模式减少改动面。3.3 方案三整表单重绘暴力但有时是正解还有一种非常粗暴的办法改了依赖项之后把整个crud或表单重新构建一次或者干脆刷新页面数据。这种做法看起来不优雅但在某些极端场景下反而最省事——比如选项的依赖链条特别长或者表单是“模板配置驱动”的动态改单项配置的复杂度已经超过重绘成本。什么时候我会用一般是表单刚打开、还没让用户输入任何东西的时候重绘几乎没有感知成本。反过来用户已经填了一屏内容你再重绘输入内容丢失绝对不行。方案适用场景优点风险点dicData 整体替换绝大多数动态联动可控、好调试需自己管请求与清空dicUrl 动态拼接改动面小的老项目改动少依赖内部缓存行为整表单重绘初始化阶段、配置驱动表实现快丢输入、性能浪费3.4 怎么选一个简单的判断标准我给自己的判断标准只有一条这个字段的选项是不是只由前端已知的上下文决定是就走方案一手动管理否如果只是某一层字典需要按当前行的某个 ID 过滤且项目里已经在用dicUrl用方案二最省事。至于方案三只在初始化时用不放在交互链路上。选型定了之后再往下看细节否则你会觉得每种做法都别扭。4. 联动实操从配置到代码一步步落地4.1 先把两份 column 配置写对下面是一个省份到城市的联动最小示例我按实际项目里的写法给出包括监听、清空、请求、赋值四步。// 表单配置 const option { column: [ { label: 省份, prop: provinceId, type: select, props: { label: name, value: id }, dicData: [], change: ({ value, column }) { // 用户切换省份时触发 handleProvinceChange(value); } }, { label: 城市, prop: cityId, type: select, props: { label: name, value: id }, dicData: [] } ] };change回调是 Avue 列配置里比较实用的一个钩子参数里能拿到当前值。用它来驱动联动比在外部监听v-model找字段更聚焦也避免了一个大监听器里写一堆if。4.2 清空旧值必须走组件能感知的方式这里是我早期踩得最狠的坑。一开始我拿到表单实例直接改了数据对象上的cityId改的是我本地那份对象结果组件的显示没有跟着变提交时传出去的还是旧值。可靠做法是用表单实例提供的方法去更新字段值。常见的两种思路一是用表单实例的更新方法传入{ cityId: }这样的对象二是如果这层封装下不易操作借助$refs拿到内部表单组件再做clearValidate和值重置。// vModel 指代表单实例 ref注意按你项目的实际 ref 名替换 async function handleProvinceChange(provinceId) { // 第一步清空下游值并且清掉它的校验状态 vModel.updateForm({ cityId: }); vModel.clearValidate([cityId]); // 第二步没选省份时下游选项也置空直接结束 if (!provinceId) { setDicData(city, []); return; } // 第三步拉取新选项并赋值 const list await requestCityList({ provinceId }); setDicData(city, list.map(it ({ label: it.name, value: it.id }))); }顺序很关键清空在请求之前。如果反过来先请求等待期间旧值还挂在表单上一旦用户手快点了保存就会带上脏数据。注意清空值的时候一定顺手清校验状态。否则如果这个字段之前被标红过“必填”清空后红框会一直挂着用户选了新城市红框也不消失体验很差。4.3 编辑页回填串行请求的顺序不能乱编辑页是动态联动的高发场景。数据里同时有provinceId和cityId页面打开必须先把省份选项准备好才能显示省份名称然后拿provinceId去拉城市选项才能显示城市名称。少一步就会出现“值有但显示为空白”的现象。async function initEditForm(detail) { // 先拉一级选项 const provinces await requestProvinceList(); setDicData(provinceId, provinces.map(it ({ label: it.name, value: it.id }))); // 再拉二级选项注意用详情里的 provinceId if (detail.provinceId) { const cities await requestCityList({ provinceId: detail.provinceId }); setDicData(cityId, cities.map(it ({ label: it.name, value: it.id }))); } // 最后再回填表单数据 vModel.updateForm(detail); }这里的顺序是字典在前、回填在后。反过来的话值先写了、字典还没到组件在渲染时会找不到匹配的 label虽然值还在但视觉上是空白的如果这时有校验就会立刻报错。还有一种更隐蔽的问题某些版本下如果先回填值、后改字典组件可能不会重新计算 label导致你明明字典也赋值了显示还是空。所以我的习惯固定成“字典 → 回填”把不确定性消灭掉。4.4 多级联动用数组驱动别写死层级三级甚至四级联动如果一层层写if代码会膨胀得很快。更好的做法是维护一个层级关系表用一个通用函数按索引递归处理。// 层级定义从上游到下游 const linkChain [ { prop: provinceId, api: requestProvinceList }, { prop: cityId, api: requestCityList, dependsOn: provinceId }, { prop: districtId, api: requestDistrictList, dependsOn: cityId } ]; // 某个层级变化后把它下游全部清空 function clearDownstream(startIndex) { const patch {}; for (let i startIndex 1; i linkChain.length; i) { patch[linkChain[i].prop] ; } vModel.updateForm(patch); vModel.clearValidate(linkChain.slice(startIndex 1).map(it it.prop)); }有了这个结构新增一级只往linkChain里加一项不用到处改代码。清空下游时遍历生成 patch 对象一次提交比逐个updateForm更干净也少了几次渲染。5. 异步与并发请求时序才是真正的难点5.1 快速切换导致的结果错乱用户操作从来不会按你设想的节奏来。他可能先选江苏看到下拉转圈立刻改成浙江这时两个请求都在飞。如果江苏的响应后回来它会把浙江的选项覆盖掉用户看到的是浙江的省份配江苏的城市——错得很离谱而且不好复现。解决思路是给每次请求打一个序号回来时比对是不是最新的一次不是就丢弃。let cityReqSeq 0; async function loadCity(provinceId) { const seq cityReqSeq; const list await requestCityList({ provinceId }); // 只有最后一次请求的结果才允许落到界面上 if (seq ! cityReqSeq) return; setDicData(cityId, list.map(it ({ label: it.name, value: it.id }))); }这段代码很短但它是这个功能里最有价值的一小段。凡是联动请求我都会加这个序号守卫不管产品有没有提过“快速切换”的要求因为它防的是小概率但后果严重的错数据。5.2 加载态和禁用态要不要做严格说 Avue 内部有自己的加载表现但在手动请求模式下请求期间下拉框是可以被点开的用户点开会看到空列表或者上一次的旧列表。我的处理是请求开始时给这一列加disabled: true回来再放开。function setColLoading(prop, loading) { const col option.find(c c.prop prop); if (col) col.disabled loading; }代价是列配置变化也会引起一次渲染频率别太高就行。如果觉得闪可以只在请求超过一定时长后才显示禁用态这叫延迟加载指示交互上更平滑。另一种思路是不禁用而是保留下拉里旧数据并加个“加载中”提示但这就得看组件是否支持自定义空状态改动成本高常规场景用禁用更实用。5.3 请求失败时别让界面停在“无数据”接口挂了或者超时手动方案下界面上就是空下拉用户会以为是“没有数据可选”而不是“请求失败”。这两种含义完全不同。所以要显式处理失败给出提示、把选项置空、把状态复位。try { const list await requestCityList({ provinceId }); setDicData(cityId, list.map(it ({ label: it.name, value: it.id }))); } catch (e) { setDicData(cityId, []); vModel.updateForm({ cityId: }); // 提示文案要能区分“暂无数据”和“加载失败” ElMessage.error(城市列表加载失败请重新选择省份); } finally { setColLoading(cityId, false); }提示失败提示里最好带上“请重新选择”这样的动作引导否则用户会反复点同一个下拉得不到任何反馈。5.4 缓存加与不加都要有理由同一个省份的城市列表用户来回切换时会重复请求。加一层内存缓存按provinceId存结果能明显减少无谓请求。const cityCache new Map(); async function loadCityWithCache(provinceId) { if (cityCache.has(provinceId)) { setDicData(cityId, cityCache.get(provinceId)); return; } const list await requestCityList({ provinceId }); const mapped list.map(it ({ label: it.name, value: it.id })); cityCache.set(provinceId, mapped); setDicData(cityId, mapped); }但缓存不是无脑加。如果选项数据会因权限、租户、业务状态变化缓存就可能让你拿到过期的选项。我的取舍是基础数据行政区划、部门架构、字典项可以缓存业务数据可选模板、待处理任务不缓存。分不清的时候就不缓存多一次请求的成本远低于展示错数据的成本。6. 踩坑实录那些文档里不会写的问题6.1 值变了显示不变先查 label 有没有匹配上现象是值明明赋进去了下拉框里显示空白或者显示的是原始 ID。原因几乎都是当前dicData里找不到这个值对应的项。组件只能靠 value 去字典里找 label找不到就退化成显示原始值或空白。排查顺序我一般是这三步先打印当前dicData看里面有没有这个 value再确认props.value字段名是否和接口返回一致id还是value很多人这里错最后确认赋值时机是不是在字典到达之前。// 调试用快速确认字典与当前值是否对得上 console.log(当前字典:, option.find(c c.prop cityId).dicData); console.log(当前值:, vModel.value.cityId);注意不要在dicData还是空数组的时候就去校验或回填值。空字典配上有值的状态就是页面闪烁和误报错的来源。6.2 清空了值但下拉里还留着旧选项这通常是清值清了、字典没清或者反过来。记住这两者是独立的两份数据一个在表单值里一个在列的dicData里。联动时两者都要处理光是清值不换字典用户还能从下拉里看到上一个省份的城市点了就出错。6.3 监听写在 change 里却触发两次有些场景下change会被触发多次一次是用户交互一次是你程序里updateForm改变了同一个字段的值。如果你的联动逻辑写在change里就会重复发请求。我一般加一个前置判断如果新值和旧值相同直接返回如果是程序触发的清空空值就跳过联动。change: ({ value }) { if (!value) return; // 程序清空不触发联动 if (value lastProvinceId) return; // 值没变不重复请求 lastProvinceId value; loadCity(value); }6.4 表单弹窗复用时数据污染dialog里的表单反复打开同一条或不同条记录最容易出现上一轮的城市选项残留。因为option是同一份对象引用dicData上还挂着旧数据。处理方式是每次打开前重置字典和值而不是打开后才处理。我通常封装一个resetFormState()把联动链上的dicData清空、值清空、校验清掉三件事一起做然后才赋值详情。6.5 常见问题速查现象大概率原因处理方式值有但显示空白字典里没有匹配 value补齐字典核对 props 映射下拉里是旧选项只清了值没换字典两者同清选项对不上当前条件并发请求覆盖加请求序号守卫联动触发两次请求change 被清空动作触发空值或同值时跳过弹窗重开数据残留option 引用未重置打开前统一重置6.6 我个人的三条硬经验第一条动态字段一旦有了刷新需求就把这个字段的数据源解释权收回前端。别指望它既走dicUrl又走手动赋值两套机制打架的时候你会花半天找一个只需要改一行的问题。第二条清空、请求、赋值这三件事写成一个函数按固定顺序执行。散落在各处的结果是这个场景清了没请求那个场景请求了没清修一个坏一个。第三条联动的正确性靠代码保证不靠用户手速。序号守卫、失败重置、清空时机这些在人少的测试环境里几乎看不出来一旦用户量上来就是偶发的脏数据工单。我把这几条当成交付前的检查项而不是可选项。另外补一个小技巧导出或打印表单配置时先JSON深拷贝一份再打印避免打印的是引用控制台展示的永远是你最后改完的结果看起来像“字典一直是新的”容易误判。7. 收个尾动态刷新选择框这件事表面看是“改一个数组”实际上是三个问题的叠加字典怎么给、旧值怎么清、并发怎么防。Avue 把第一件事简化了也顺带把第一件事模糊了后两件事从头到尾都得自己扛。我的做法一直是把字典从框架托管收回来自己管用dicData赋值代替dicUrl自动拉用表单实例的方法改值而不是硬改对象用序号守卫挡住并发覆盖——这四件事做到位联动基本不会再出幺蛾子。至于缓存、加载态、失败提示都属于在正确的基础上做体验优化顺序别搞反。