フォームチェックから見たJavaScriptポリシーモードの使用

周知のように、フォームは確かにフロントエンドにあり、うーん、あるいはホームページの中で大きな比重を占めています.実際、ほとんどの中大規模なサイトには、ユーザー情報を検証し、名状できない危険を防ぐための「ログイン登録」があります.の
フォームの優劣は,フロントエンド開発者が急いで解決しなければならない問題となっている.実は私は「コードの可読性」や「多重性」、「冗長性があるかどうか」と呼ぶことを望んでいます.
フォームにも「優劣」はありますか?冗談を言ってるの?次のコードをよく見て、「新しい知識」を使ったと思います.

<form action="xxx" id="registerForm">
	      ：<input type="text" name="userName" id="name" />
	     ：<input type="text" name="password" id="pass" />
	      ：<input type="text" name="phoneNumber" id="phone" />
	<button>  </button>
</form>

ユーザー名、パスワード、携帯電話番号はフォームの中で最もよく見られるはずです.はい、分析します.

<script>
	var registerForm=document.getElementById('registerForm')
	registerForm.onsubmit=function(){
		if(registerForm.userName.value==''){
			document.getElementById("name").setCustomValidity('       ');
			return false;
		}
		if(registerForm.password.value.length<6){
			document.getElementById("pass").setCustomValidity('        6 ');
			return false;
		}
		if(!/(^1[3|5|8][0-9]{9}$)/.test(registerForm.phoneNumber.value)){
			document.getElementById("phone").setCustomValidity('         ');
			return false;
		}
	}
</script>

これらは簡単なプレゼンテーション効果で、cssのvalid/invalid、HTML 5のrequired/patternで完全に協力することができます.
しかし、それでも完璧だとは思いません.今はフォームが3つしかありません.ある日N本に増えたら、「コピー&ペースト」でもあなたを救うことはできません.
その時、あなたは戦略モード(見て、JSはいつもあなたに“霊光が現れます”)を考えて、戦略モードといえば、自然に、インタフェースを暴露して論理の分離を実現する原則に従います.
ポリシーモードとは、一連のアルゴリズムを定義し、それらを一つ一つカプセル化することを意味します.不変の部分と変化の部分を区切るのは各設計モードのテーマであり、ポリシーモードも例外ではなく、ポリシーモードの目的はアルゴリズムの使用とアルゴリズムの実現を分離することである.1つのポリシー・モードに基づくプログラムは、少なくとも2つの部分から構成される.最初の部分は、特定のアルゴリズムをカプセル化し、特定の計算プロセスを担当するポリシークラスのセットです.第2部は環境クラスContextであり、Contextは顧客の要求を受け入れ、その後、あるポリシークラスに要求を依頼する.これを行うには、Contextでポリシーオブジェクトへの参照を維持することを説明します.「JavaScript設計モードと開発実践」
では、最初のステップでは、これらの検証ロジックを「ポリシー・オブジェクト」にカプセル化することは明らかです.

var strategies={
	isNoneEmpty:function(value,errorMsg){
		if(value===''){
			return errorMsg;
		}
	},
	minLength:function(value,length,errorMsg){
		if(value.length<length){
			return errorMsg;
		}
	},
	isMobile:function(value,errorMsg){
		if(!/(^1[3|5|8][0-9]{9}$)/.test(value)){
			return errorMsg;
		}
	}
};

次に、context(コンテキスト)として、ユーザーのリクエストを受信し、検証オブジェクトstratrgiesに委任する「露出」、「呼び出し」メソッドクラスを実装します.

var Validator=function(){
	this.cache=[];   //            
};
Validator.prototype.add=function(dom,rule,errorMsg){
	var ary=rule.split(':');
	this.cache.push(function(){
		var strategy=ary.shift();
		ary.unshift(dom.value);
		ary.push(errorMsg);
		return strategies[strategy].apply(dom,ary);   //  strategies         ，          this  dom  ，ary      
	});
};
Validator.prototype.start=function(){
	for(var i=0,validatorFunc;validatorFunc=this.cache[i++];){
		var msg=validatorFunc();
		if(msg){
			return msg;
		}
	}
}

次の操作を行います.

var validataFunc=function(){
	var validator=new Validator();
	
	//      
	validator.add(registerForm.userName,'isNoneEmpty','       ');
	validator.add(registerForm.password,'minLength:6','        6 ');
	validator.add(registerForm.phoneNumber,'isMobile','         ');
	
	var errMsg=validator.start();   //      
	return errorMsg;   //  
}

var registerForm=document.getElementById('registerForm')
registerForm.onsubmit=function(){
	var errorMsg=validataFunc();
	if(errorMsg){
		//      
		return false;   //       
	}
}

validatorオブジェクトに一連の検証ルールを追加すると、validator.start()メソッドが呼び出されて検証が開始されます.validator.start()が正確なerrorMsg文字列を戻り値として返した場合、このチェックが通過しなかったことを示します.この場合、registerForm.onsubmitメソッドにfalseを返してフォームのコミットを阻止する必要があります.
これは確かに以前よりずっと良いです.少なくとも検証ルールを変更するときは苦労しません.

validator.add(registerForm.userName,'minLength:2','       2 ')

しかし、問題は、ユーザー名に対する検証ルール「空にできない」を「2桁以上」に変更すると、「空かどうか」は検証できません.
element-uiのように複数の検証ルールをカスタマイズできますか?このように:

validator.add(registerForm.userName,[{
	strategy:'isNoneEmpty',
	errorMsg:'       '
},{
	strategy:'minLength:2',
	errorMsg:'         2 '
}])

「rule」は配列-オブジェクトの形式です.add関数を変更する必要があります.

Validator.prototype.add=function(dom,rules){
	var self=this;
	for(var i=0,rule;rule=rules[i++];){
		(function(rule){
			var strategyAry=rule.strategy.split(':');
			var errorMsg=rule.errorMsg;
			self.cache.push(function(){
				var strategy=strategyAry.shift();
				strategyAry.unshift(dom.value);
				return strategies[strategy].apply(dom,strategyAry);
			});
		})(rule)
	}
}

ポリシー・モードの利点:

組合せ、委託、多態などの技術と思想を利用して、多重条件選択文を効果的に回避することができる(この点について、筆者はこの文章で詳細に説明した).

は設計モデルが持つべき「対外開放-閉鎖」の原則を完璧に実現し、戦略モデルに基づいて実現される規則の多くは拡張しやすく、

を使用しやすい.

大量のCVを回避した