js前端設計模式如何優化50%表單

本篇內容主要講解“js前端設計模式如何優化50%表單”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“js前端設計模式如何優化50%表單”吧!

表單校驗

背景

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

• 用戶名不能為空

• 密碼長度不能少于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 函數的內部實現，這是違反開放-封閉原則的。

• 算法的復用性差，如果在項目中增加了另外一個表單，這個表單也需要進行一些類似的校驗，我們很可能將這些校驗邏輯復制得漫天遍野。

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

策略模式介紹

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

真實世界類比

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

更廣義的“算法”

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

策略模式的組成

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

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

第二個部分是環境類 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。這是違反最少知識原則的。

策略模式適合應用場景

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

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

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

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

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

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

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

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

到此，相信大家對“js前端設計模式如何優化50%表單”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！