js前端設計模式優化50%表單校驗代碼示例

Posted on by

表單校驗

背景

假設我們正在編寫一個註冊頁面，在點擊註冊按鈕之時，有如下幾條校驗邏輯：

  • 用戶名不能為空
  • 密碼長度不能少於6位
  • 手機號碼必須符合格式

常規寫法：

const form = document.getElementById('registerForm');
form.onsubmit = function () {
  if (form.userName.value === '') {
    alert('用戶名不能為空');
    return false;
  }
  if (form.password.value.length < 6) {
    alert('密碼長度不能少於6位');
    return false;
  }
  if (!/^1[3|5|8][0-9]{9}$/.test(form.phoneNumber.value)) {
    alert('手機號碼格式不正確');
    return false;
  }
  ...
}

這是一種很常見的代碼編寫方式，但它有許多缺點：

  • onsubmit 函數比較龐大，包含瞭很多 if-else 語句，這些語句需要覆蓋所有的校驗規則。
  • onsubmit 函數缺乏彈性，如果增加瞭一種新的校驗規則，或者想把密碼的長度從6改成8，我們都必須深入 obsubmit 函數的內部實現，這是違反開放-封閉原則的。
  • 算法的復用性差，如果在項目中增加瞭另外一個表單，這個表單也需要進行一些類似的校驗，我們很可能將這些校驗邏輯復制得漫天遍野。

如何避免上述缺陷，更優雅地實現表單校驗呢？

策略模式介紹

💡 策略模式是一種行為設計模式， 它能讓你定義一系列算法， 把它們一個個封裝起來， 並使它們可以相互替換。

真實世界類比

此圖源自 https://www.jb51.net/article/252304.htm

假如你需要前往機場。 你可以選擇騎自行車、乘坐大巴或搭出租車。這三種出行策略就是廣義上的“算法”，它們都能讓你從傢裡出發到機場。你無需深入它們的內部實現細節，如怎麼開大巴、公路系統如何確保你傢到機場有通路等。你隻需要瞭解這些策略的各自特點：所需要花費的時間與金錢，你就可以根據預算和時間等因素來選擇其中一種策略。

更廣義的“算法”

在實際開發中，我們通常會把算法的含義擴散開來，使策略模式也可以用來封裝一系列的“業務規則”。隻要這些業務規則指向的目標一致，並且可以被替換使用，我們就可以用策略模式來封裝它們。

策略模式的組成

一個策略模式至少由兩部分組成。

第一個部分是一組策略類，策略類封裝瞭具體的算法，並負責具體的計算過程。

第二個部分是環境類 Context，Context 接受客戶的請求，隨後把請求委托給某一個策略類。

利用策略模式改寫

定義規則（策略），封裝表單校驗邏輯：

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

定義環境類 Context，進行表單校驗，調用策略：

form.onsubmit = function () {
	const validator = new Validator();
	validator.add(form.userName, 'isNonEmpty', '用戶名不能為空');
	validator.add(form.password, 'minLength:6', '密碼長度不能少於6位');
	validator.add(form.phoneNumber, 'isMobile', '手機號碼格式不正確');
	const errMsg = validator.start();
	if (errMsg) {
		alert(errMsg);
		return false;
	}
}

Validator 類代碼如下：

class Validator {
	constructor() {
		this.cache = [];
	}
	add(dom, rule, errMsg) {
		const arr = rule.split(':');
		this.cache.push(() => {
			const strategy = arr.shift();
			arr.unshift(dom.value);
			arr.push(errMsg);
			return strategies[strategy].apply(dom, arr);
		})
	}
	start() {
		for (let i = 0; i < this.cache.length; i++) {
			const msg = this.cache[i]();
			if (msg) return msg;
		}
	}
}

使用策略模式重構代碼之後，我們消除瞭原程序中大片的條件分支語句。我們僅僅通過“配置”的方式就可以完成一個表單校驗，這些校驗規則也能在程序中任何地方復用，還能作為插件的形式，方便地移植到其他項目中。

策略模式優缺點

優點：

  • 可以有效地避免多重條件選擇語句。
  • 對開放-封閉原則完美支持，將算法封裝在獨立的 strategy 中，使得它們易於切換，易於理解，易於擴展。
  • 可以使算法復用在系統的其他地方，避免許多重復的復制粘貼工作。

缺點：

  • 使用策略模式會在程序中增加許多策略類或策略對象
  • 要使用策略模式，必須瞭解所有的 strategy，瞭解它們的不同點，我們才能選擇一個合適的 strategy。這是違反最少知識原則的。

策略模式適合應用場景

💡 當你想使用對象中各種不同的算法變體， 並希望能在運行時切換算法時， 可使用策略模式。

策略模式讓你能夠將對象關聯至可以不同方式執行特定子任務的不同子對象， 從而以間接方式在運行時更改對象行為。

💡 當你有許多僅在執行某些行為時略有不同的相似類時， 可使用策略模式。

策略模式讓你能將不同行為抽取到一個獨立類層次結構中， 並將原始類組合成同一個， 從而減少重復代碼。

💡 如果算法在上下文的邏輯中不是特別重要， 使用該模式能將類的業務邏輯與其算法實現細節隔離開來。

策略模式讓你能將各種算法的代碼、 內部數據和依賴關系與其他代碼隔離開來。 不同客戶端可通過一個簡單接口執行算法， 並能在運行時進行切換。

💡 當類中使用瞭復雜條件運算符以在同一算法的不同變體中切換時， 可使用該模式。

策略模式將所有繼承自同樣接口的算法抽取到獨立類中， 因此不再需要條件語句。 原始對象並不實現所有算法的變體， 而是將執行工作委派給其中的一個獨立算法對象。

總結

在上述例子中，使用策略模式雖然使得程序中多瞭許多策略對象和執行策略的代碼。但這些代碼可以在應用中任意位置的表單復用，使得整個程序代碼量大幅減少，且易維護。下次面對多表單校驗的需求時，別再傻傻寫一堆 if-else 邏輯啦，快試試策略模式！

參考

深入設計模式——策略模式

《JavaScript 設計模式與開發實踐》——曾探

更多關於js前端設計模式優化表單校驗的資料請關註WalkonNet其它相關文章！

推薦閱讀：