最近呢做了一个后台管理系统,对字段的过程可是艰辛啊.也发现了一些以前没有考虑清楚的问题.在此做个记录
时间选择的限制,结束时间不能大于开始时间
这里使用的是element-ui
<el-form-item label="营业时间" prop="disneylandShopOpenTime">
<el-row style="width: 550px">
<el-col :span="11">
<el-time-picker
v-model="form.disneylandShopOpenTime" //开始时间
format="HH:mm"
value-format="HH:mm"
placeholder="选择开始时间"
style="width: 100%;"
@change="changeTime" //选择事件
/>
</el-col>
<el-col class="line" :span="2">-</el-col>
<el-col :span="11">
<el-time-picker
v-model="form.disneylandShopCloseTime"
:disabled="form.disneylandShopOpenTime===''?true:false" //是否禁用
format="HH:mm"
value-format="HH:mm"
placeholder="选择结束时间"
style="width: 100%;"
:picker-options="{
selectableRange: `${form.disneylandShopOpenTime}:00 - 23:59:00`//限制方法
}"
/>
</el-col>
</el-row>
</el-form-item>
这里的核心思路就是先把结束时间给禁用了,然后使用配置项去限制结束时间的取值范围.每次呢修改开始时间就会把结束时间给清空.优化好一点的话可以判断一下结束时间是否大于开始时间在考虑要不要清空和限制.
级联选择器
需求是根据第一级id发请求获取后续数据
//模板
<el-form-item label="所属人物:" prop="disneylandRoleId">
<el-cascader v-model="searchForm.disneylandRoleId" :props="props" class="input" />
</el-form-item>
//配置
props: {
lazy: true,
emitPath: false,
lazyLoad: this.lazyLoad
},
methods: {
// 坑爹级联
lazyLoad(node, resolve) {
const { value, level } = node
if (level === 0) {
findDisneylandSeries().then(res => {
const nodes = res.data.s.map(item => {
// console.log(item)
return {
value: item.disneylandSeriesId,
label: item.disneylandSeriesName
}
})
resolve(nodes)
})
}
if (level === 1) {
getDisneylandRoleList(value).then(res => {
const nodes = res.data.map(item => {
return {
value: item.disneylandRoleId,
label: item.disneylandRoleChineseName,
leaf: level >= 1
}
})
resolve(nodes)
})
}
},
核心思路还是根据配置项传入的函数,level这个参数呢是级联的层级,等于0的时候是第一级,这里面可以放一个请求函数,return的数据如果有leaf:条件false就不会往下个级别继续迭代了.
关于新增编辑的数据回显和处理的思考
第一次写项目就有这种困惑,怎么在编辑回显数据之后处理数据达到后端的要求呢?以前也想过拿到数据直接深拷贝然后对这个数据处理返回给后台,但是好像没有一个完整的思路.这两天的需求后端对轮播图还有一些选择器选中的值传回后台的要求比较特别,需要传回一个键值对的数组.这就需要我们的数据表单在点击确定按钮的时候对数据进行处理.那么我们需要做什么呢?
1:请求这个人的详细信息或者直接取这行数据
2:把这行数据回显到表单上面
3:点击后处理数据格式然后传回后台
还要考虑万一数据格式不符合要求,后台传回错误信息我们怎么处理呢?首先我们要拷贝请求回来的数据或者需要编辑的这个栏目的数据,避免污然源数据.因为我们可能在被告知数据错误后继续修改表单然后继续处理.为了防止重复对这个数据处理就要保证这个值是干净的.那么核心的思路就是给一个函数,返回处理后的一个提交数据.
借用老哥的一段话:前端表单的状态 跟接口要的状态不一致 这种很正常 我这边做表单 都首先定两个方法 一个洗前端入参 一个洗后端返参.格式化 只为接口服务 不应该影响到前端的状态.
回过头来看
现在是2023年的12/28日了,现在看见这个帖子我可以很好的回答自己的问题.这种情况就应该借助纯函数的思想,渲染在ui上面的数据我们不会去改变而是将其作为参数传递给处理函数.由处理函数处理成后端需要的样子.接受有时候也是这样,好处就是报错不会影响原本的UI,数据不管多少次处理都是一样的而不是产生副作用.业务上面也只需要关心这个处理参数.