对于疫情数据平台而言，最怕的是什么呢？那便是数据堆积如山，致使用户看着感到头疼，然而在出行之前依旧不清楚究竟应不应该动身前往。将复杂的跨省政策转化为简单明了的出行建议，这才是该平台能够留住用户的核心价值所在。
双向选择表单的交互设计逻辑
最为前端开发而言，最忌讳之处便是想当然。当拿到后端接口文档的那个时刻，我便发觉此次的数据结构颇具趣味，并非单纯只是一个地方的政策那般简单，而是涵盖了“从哪来”以及“到哪去”这两个维度。这也就意味着，必须要让用户把出发地跟目的地都挑选清楚。
鉴于中国存在着三十四个省级行政区以及三百余款地级市情况，假设将全部选项均陈列于页面之上，用户必然会致使鼠标滚轮滚动至冒烟状态情况。因而我把选择划分成为两组四个下拉框，分别是出发省，出发市，到达省，到达市，如此一来界面便会显得清爽，逻辑也会清晰。
基于Vue的省市区三级联动实现
若省市联动这一功能看上去简易，然而实际操作起来却存在诸多细节之处。当用户选择广东省时，在到达市的选项之中难道就不应再呈现广州市了没错？并非如此，而是需要呈现，原因在于广州市本身即为到达目的地。此处的关键要点乃是正确地初始化城市数据。
我省取watch用以监控出发省乃至到达省所产生的变化，一旦出现变化便即刻清空与之对应的市选项，随后从于本地维护的城市JSON文件当中匹配全新的城市列表。于此需留意城市数据的完整性，将港澳台涵盖进去，切不可仅把目光聚焦于内地。
延迟提交的数据绑定技巧
确实v-model很方便，然而有时过于方便反倒催生坏事。用户仍于调整选项之际，页面却已然开始频繁地向后端发送请求，这般情形难道不是在给服务器增添麻烦吗？用户体验亦出现卡顿。
四个用于提交的变量被我声明了，它与和表单绑定的变量是分开的。当用户点击查询按钮之际，表单绑定的数据继而被赋值给提交变量，而后触发向后端发出的请求。如此这般，即便用户进行一百次调整也是可行的，不过唯有在确认之后才会提交。
政策展示页面的信息呈现重点
出发
到
查询
我所设计的查询结果页面，极其讲究克制，对于政策文本，是直接进行展示的，而健康码状态，则借助颜色予以区分，其中红黄绿三种颜色，清晰明了，一目了然，用户所关注在意的并非是那些花哨繁杂的动画，而是诸如“我抵达那里之后到底用不用进行隔离”、“健康码会不会出现变化”之类的问题。
以标签页切换的方式，来切换出发地以及目的地的政策详情，在其两者中间放置一张醒目突出的出行建议卡片，此卡片是依据两地政策综合判别之后生成的，诸如“建议暂缓出行”或者“持48小时核酸通行” ，而这才是用户真正所期望得到的一句话概括总结。
健康码联动展示的必要性
诸多人搞疫情平台仅显政策，却遗漏健康码状态提示，此乃极大失误。政策准许你前往，然而你的健康码到当地是否会转码，这是不同的两回事。
页面右侧固定展示有全国健康码互认状况，展示处用小字提示用户，出发前于当地做核酸检测之时，要记得申领目的地健康码。这些细节虽小，却能帮用户避免到达高速路口后才发觉健康码不被认可的尴尬情形。
watch:{
from_province:function (newval,oldval){
this.citys=[]
for(var i=0;i
组件复用与后续功能扩展
我将这套表单组件设计成了可加以配置的那种。往后要是政策出现调整，又或者平台打算增添铁路、民航出行建议模块，直接去复用这套省市选择逻辑便可以了。watch的用法还预留了扩展接口。
后续计划增添热门城市快捷选项，将北京、上海、广州这类人员流动频繁的城市置于前列。如此一来，用户无需长时间翻找，轻点一下即可完成填写。在数据可视化层面，打算于地图上借助颜色深浅来呈现不同地区的政策严格程度，以使用户具备更强的全局观念。
你的城市出行政策查询这个功能，最期望看到的是哪一种额外的信息呢，是周边城市的政策之间的对比，还是具体到某一个街道的核酸采样点的分布情况呢？