Jquery表单校验—思考测试提出的优化建议：如何设计灵活的软件

最新推荐文章于 2024-07-21 14:25:34 发布

既过不念，未来不继

最新推荐文章于 2024-07-21 14:25:34 发布

阅读量550

点赞数

分类专栏： ------【前端】 ◆知识探究

本文链接：https://blog.csdn.net/hhx0626/article/details/79113502

版权

◆知识探究同时被 2 个专栏收录

40 篇文章 0 订阅

订阅专栏

------【前端】

9 篇文章 0 订阅

订阅专栏

前言：老实交待，我确实好久没写过前端表单校验了。　这不，这回一写，测试那么就懵了，哈哈哈！　其实很简单，就是我写了个校验手机号码格式的东西，结果：首先是校验的范围不合适，然后是提示的时机不合适。　建议的范围是：以１开头的１１位数字，时机是：失去焦点时！

一、案例经过

话说，本姑娘那会儿写前端的时候，妈蛋的，还是easyUI+JQ啊，然后那时候也是中了Js的毒，不对，应该是中了源码和框架，结果源码落败的毒，有了JQ和easy UI，本宝宝也是（不只是我，好像那会儿同事们大都这么干的）拼了老命的写JS进行各种校验操作。 PS：犹记得那会儿自己实现JQ的那个分页表的操作，呆萌！

后来吧，我好像没怎么写前端了，在入职这家公司前，我最后一次写前端，应该是Angular4+bootstrap4，但好像也没有写校验表单这种的，印象中似乎是直接用的一个bootstrap的东东。所以，话说，当第一次看到有用一个JQ的插件时，心情时很澎湃的。 OK，不瞎扯了，先上个例子，然后再分析、思考！

首先：说说那个手机号码格式规则的事儿，我最开始的正则校验是11位，13、15这种类型开头的号码，后来测试跟我说，建议校验以1开头，11位数字就OK。后来想了想，也不是没道理。但是，11位，这么多类型（我说是13、15、18这种的），感觉也会用很久啊。而且，万一有一天11位都不够用了怎么办，哈哈哈，纯属恶补。这一点嘛，确实是我没考虑周全，接收建议，立马修改。毕竟，当发布的手机号不够用时，还真有可能搞出个12、19啥的手机号呢。

其次，是校验的时机，看了看校验的代码，是keyup。代码里面将keyup校验关闭的代码段，并没有什么卵用。后来，想了想确实不对，校验嘛，应该是校验用户输入完成的结果，而不是用户正在输入的过程中。像什么手机号呀，验证码呀，反正就是在我们项目的场景下，用keyup事件校验确实不对。

如下：粘贴代码（代码完了之后，本宝宝可能会吐槽）

注意了哈：onkeyup的值设置为false后，就可以关闭其事件校验。然而，这段配置，在最开始，是这样的：

onfocusout:function(element) { $(element).valid(); },
onkeyup: function(element) { $(element).valid(); },

var addFormValidate = $("#addForm").validate({
    onkeyup: false,
    rules: {
        mobilePhone: {
            required: true,
            isMobile: true,
            minlength: 11,
            remote: {
                type: "GET",
                url: "/userCenter/isExistPhoneNum",
                data: {
                    mobilePhone: function () {
                        return $("#mobilePhone").val();
                    }
                }
            }
        },
        imageCode: {
            required: true,
            minlength: 4
        },
        smsCode: {
            required: true,
            minlength: 6

        }
    },
    messages: {
        mobilePhone: {
            required: icon + "请输入手机号码",
            minlength: icon + "请输入11位手机号码",
            remote: icon + "当前手机号码已存在，请重新输入",
            isMobile: icon + "手机号码格式错误"
        },
        imageCode: {
            required: icon + "请输入图型验证码",
            minlength: icon + "请输入4位图型验证码"
        },
        smsCode: {
            required: icon + "请输入短信验证码",
            minlength: icon + "请输入6位短信验证码"
        }
    },
    submitHandler: function (form) {
        $("#submit").attr("disabled", true);
        form.submit();
    },
    invalidHandler: function (form, validator) {
        $("#submit").attr("disabled", false);
        return false;
    }
});

$.validator.addMethod("isMobile", function (value, element) {
    var length = value.length;
    var mobile=/^1[0-9]{10}$/;
    return this.optional(element) || (length == 11 && mobile.test(value));
}, "手机号码格式错误");

    onkeyup: false,
    rules: {
        mobilePhone: {
            required: true,
            isMobile: true,
            minlength: 11,
            remote: {
                type: "GET",
                url: "/userCenter/isExistPhoneNum",
                data: {
                    mobilePhone: function () {
                        return $("#mobilePhone").val();
                    }
                }
            }
        },
        imageCode: {
            required: true,
            minlength: 4
        },
        smsCode: {
            required: true,
            minlength: 6

        }
    },
    messages: {
        mobilePhone: {
            required: icon + "请输入手机号码",
            minlength: icon + "请输入11位手机号码",
            remote: icon + "当前手机号码已存在，请重新输入",
            isMobile: icon + "手机号码格式错误"
        },
        imageCode: {
            required: icon + "请输入图型验证码",
            minlength: icon + "请输入4位图型验证码"
        },
        smsCode: {
            required: icon + "请输入短信验证码",
            minlength: icon + "请输入6位短信验证码"
        }
    },
    submitHandler: function (form) {
        $("#submit").attr("disabled", true);
        form.submit();
    },
    invalidHandler: function (form, validator) {
        $("#submit").attr("disabled", false);
        return false;
    }
});

$.validator.addMethod("isMobile", function (value, element) {
    var length = value.length;
    var mobile=/^1[0-9]{10}$/;
    return this.optional(element) || (length == 11 && mobile.test(value));
}, "手机号码格式错误");

附：jQuery校验插件API说明：jQuery validate 对了，bootstrap有个类似的插件，自己找吧！

二、案例思考

1，插件扩展

在上面的代码中，最开始没有手机号码校验的内容，可是通过自定义扩展的方式，就可以添加一个新的校验规则。很不错的想法，就想到之前做的一个平台，虽说不是这种自定义，但是我们做到了将每一个资源（当时的基础单位是：每一个页面）都收集起来，用户通过付费的方式，在基础服务上，添加其扩展资源。跟插件的自定义扩展，虽说好像是两回事儿，但我总觉得思想是一样的，都是：给定基础服务，通过自定义，可扩展其服务！

2，事件触发启动—关闭设置

这一点的控制权，移交给用户，说实在的，我不能说这个设计好，因为要一些其他场景中，用户的权限是被限制的，给用户更多的选择，并不能一概而论的都是好的方案。但是，至少在当前的表单校验场景中，首先keyup的校验事件，确实是有需要，而默认设置为true，在某些场景中也是合理的，何况，他提供了一种非常简单的方式去控制这个配置。

对于这一点，可能是在后台的授权管理中用的会比较多一点吧（我瞎说的哈）之前有做过一个云平台，当时就做了一个后台的权限控制服务，以角色划分，默认的是某一个角色下的所有人会为其开启符合角色的权限（呃，其实就是在前面说到的，允许其访问相应的网页资源和操作），但是，还记得，当时除了统一分配，还有个别化的就某一权限的配置管理。 PS：其实，我也不知道为什么，反正这次这个表单校验的插件问题，我就想起了当时做的那个云平台，好吧，也算是宝宝有幸，跟随了权限系统3个版本。不过现在嘛，我靠，还记得思路和思想，具体实现嘛，忘得差不多了。

3，近期项目中的团单定制

最近公司有做一个团单定制的项目，就是将每个可配置的参数，就都交给用户去配置，曰——定制！想想当年那个便宜前男友送我的第一款私人定制手机，好吧，我那时候就没感觉出来我订制了个啥。后来才知道，是因为我喜欢看网络小说，很喜欢植物大战僵尸的游戏，而且还比较喜欢网购，所以直接给我买了个内存比较打，内置了一些我比较常用的软件。

但是，我觉得，提供更多的选择，这是很好的。给用户更多的选择权和支配权，这也是很好的。但是，在众多的选择中，我们并没有提供一种默认方案，这就是不太好的。细想这个插件默认配置keyup事件为true，像tomcat的默认启动方式，都有一个默认的方案存在，用户在使用的时候，不至于懵逼。

PS：满满的都是回忆，想当年本宝宝也做个类似的产品，当时为了给出默认的配置，我靠，需要收集其他用户的配置使用习惯，包括当前用户的历史使用习惯，然后通过算法，得出默认值。妈蛋的，都是泪。现在嘛，都忘了！

4，成就别人—成就自我

这一点，也不想批评啥，然而更没有什么可吐槽的，但是，写下几点，鞭策自己：1，当我在让其他人去做一件事的时候，如果时间紧急，刚好我也知道解决方案，希望我能直接告诉他；2，当我在让其他人去做一个事的时候，如果时间不紧急，那我希望我能够和他交流他最终得出的解决方案；3，如果有一天，我手下有兵了，刚好他犯错了，那我希望，我能够去安慰他，帮忙一起解决问题，对上扛住所有的责任；4，如果有一天，有一个活儿，我自己什么都会，可能需要1天就能完成，但有的人不熟悉，他可能需要2天，甚至3天才能完成，那我希望我能将这个机会给他，并帮助他在2天内完成。