前端在项目中经常会遇到各种表单校验以及输入框有各种限制,有些前端做了校验,后端也会再校验。 这里也涉及到很多正则,以往面试中也遇到一些公司面试题包括了一些手写正则
我个人觉得,正则当我们刚开始学习前端的时候,要会手写,到后续真正写业务代码,大部分还是cv居多
今天来说说当前项目中遇到的一些input限制(当然也是为了给后续项目开发备个份,有能用的,大家也可以去cv)
1. 常见的输入长度限制(最大最小),不限制输入格式
maxlength="8"
minlength="8"
2.数值格式,最大 2 位数字,带两位小数点
oninput="if(isNaN(value)) { value = ''} if(value.indexOf('.')>0){value=value.slice(0,value.indexOf('.')+3)}" maxlength="5"
在这里如果对小数点要有其它位数限制,更改最后的+number即可
3.身份证正则
/^[1-9]{1}[0-9]{14}$|^[1-9]{1}[0-9]{16}([0-9]|[xX])$/
这个是目前常用的身份证校验处理,因为当前身份证有些是尾数带X的,另外有些表单还会涉及到在校验身份证是否合法后还要自动带出填充出生年月日以及性别(后续填坑)
4.0-100 的整数或者保留两位小数
/^(((\d|[1-9]\d)(\.\d{1,2})?)|100|100.0|100.00)$/
这个正则当初是完全不会写,度娘找了好多博客才翻出来,忘记原来的博客连接了,要不就挂出来了。
5.只允许输入数字,不限制字符数
:onkeyup="(value =vaule.replace(/[^\d]/g, ''))"
有些人可能会问为什么不用type="number"或者v-model.number="value",因为这两种处理方式都导致一些新的问题,影响样式,影响maxlengt属性,e是可以输入的。
onkeyup处理是可以避免这些问题的
6.只允许输入数字以及大写字母,不限制字符数
:onkeyup=(value =value.replace(/[^\A-\Z0-9]/g, ''))"
同理包含小写字母
:onkeyup=(value =value.replace(/[^\a-\z\A-\Z0-9]/g, ''))"
7.input做了正常校验后导致双向绑定失效的问题
@blur="value = $event.target.value"
8.手机号码校验
原文来源:blog.csdn.net/TristerD/ar…
有时候我们需要根据多个变量去判断输入框的正则是否触发,也是用这种方式,声明一个函数,然后在rules中使用,validator:fun
data() {
const checkTel = (rule, value, callback) =>{
if (!value) {
return callback(new Error('手机号不能为空'));
} else {
const reg = /^1[3|4|5|7|8][0-9]\d{8}$/
if (reg.test(value)) {
callback();
} else {
return callback(new Error('请输入正确的手机号'));
}
}
};
return {
ruleForm: {
tel:'',
},
rules: {
tel:[
{
validator: checkTel,
trigger: 'blur'
}
],
}
}
}
9.搜索框禁止输入空格
没错这也是一个在我看来要做正则处理的,一般表单中可能根据多种条件搜索过滤数据,一般我们认为的去空格都是v-model.tirm=value,但是在当前的项目中,甲方测试提了一个,他们在复制的字符串中间还可以插入空格,要求不能插入。
看到这里你是否也像我一样
但是,他们的业务人员以及开发人员确实会有这样的骚操作,然后把问题甩给开发就完事了。 所以解决这个问题的思路很明确,我直接给你整个正则,禁止输入空格就完事了,其实也不行,因为它还是可以复制,最好的方法还是直接给当前的value,replace掉空格
:onkeyup="(value = value.replace(/\s+/g, '' )) "
10.前端转千分符
在金融类项目的时候,有些甲方会要求对一些金额的输入框做千分符处理。
一开始年少无知的我感觉不就是做个正则或者调个API处理嘛,想都没想就答应下来了,当时还是项目的收尾阶段,我感觉顶多就小半天时间能加完,结果踩了个巨坑。
刚开始找到的API是Number.prototype.toLocaleString()使用这个可以实现需求。
但是在某些已经被历史遗忘的浏览器中会出现自动补两位小数的问题,这在金融类项目是肯定不允许的。
再到后面自己去定义对应的函数传入参数去动态改变值
function micrometerOperator(val){
if (val) {
let str = val.replace(/[^0-9.]/g, "");
str = str.replace(",", "");
this.xxx =
str.lastIndexOf(".") === str.length - 1
? str
: Number(str).toLocaleString();
}
}
然后再在watch中去监听xxx的值,如果newVal存在则去调用micrometerOperator这个函数
"xxx": {
handler(newVal, oldVal) {
console.log(newVal);
if(newVal){
this.micrometerOperator(newVal + "");
}
},
},
本来以为这就结束了,但是噩梦才刚刚开始
因为后端接受的时候是不处理这玩意,就是我们千分符的,后端接收会报异常,所以我们保存表单时候的还得先处理千分符,确保传值给后端的是没带,的字符串。然后又到是定义函数
//金额数据转int
turnInt(val) {
cosnt dataProcessing = "";
if (val != undefined && val != null) {
if (val.constructor == String) {
dataProcessing = val.replace(/\,/g, "");
}
}
return dataProcessing;
},
这里一定要注意到val.constructor == String这个条件判断,因为要确保数据类型问题。
提交表单的时候:
this.xxx=this.turnInt(this.xxx)
因为表单中可能存在可编辑的表格数据,那list中的千分符就要循环处理。同理就是for循环表单list然后逐一处理完再提交表单。
当时我以为这又结束的时候,我在B站又刷到一个up主更新的视频,发现了一种新的解决方式,直接上代码
"xxx": {
handler(newVal, oldVal) {
if(newVal){
this.xxx=String(newVal).replace(/(\d)(?=(\d{3})+$)/g,"$1,");
}
},
},
这样就可以减少定义上面的函数,减少一部分代码量。但是同样还是要在提交的时候处理,的问题。
看到这里可能有人会疑惑为什么不直接写在input行内去处理,非要写监听呢?因为我们不是还得做数据回显吗。我们传值给后端是字符串,同样我们拿到的也是字符串。所以监听可以同时解决多个情况下的需求。 并且还有一点就是涉及到计算属性的,在处理的时候先要跟产品确定要保留的小数点位数。好避免后续的修改工作量。到这里改完这一堆表单,工作量至少就是2个工作日起步了。有什么办法,加班呗。
而且这里还会涉及到另外一个坑,就是表单校验,如果表单校验失败,或者后端接口返回异常的情况下,但是我们的表单数据又已经在这之前处理了千分符,那么当前页面的数据就会是正常的字符串。这里就有点无解,所以要确保你在表单校验通过后再去处理千分符,至于接口报错后的情况,暂时没有想到办法解决。如果再去定义函数处理就会无形中加大代码工作量。最好的解决方案还是让后端处理千分符,接收跟返回的时候都处理掉。而且是在项目立项前就约定好。这样我们就无需做太多的处理。