上篇講的是async-validator
的基本要素,那麼,如何使用到element中以及怎樣優雅地使用,就在本篇。
上篇講到async-validator
由3大部分組成
基本驗證流程如下
上面中的validator.validate
對應element中的this.$refs[refname].validate
,只不過被改裝過的。而且在element中定義的
:model='form'
,那個form
就是source
。source
的欄位名,如source.name
就是form.name
,那麼只要在設定和
source
一樣的欄位名name
,就可以匹配中的
rules.name
。
很重要的一點,rules.欄位名
要和source.欄位名
要一樣才會驗證。
export default
}return }},
methods:
// 驗證通過後的處理...})}
}}
上面中validate(callback)
函式已經新增到form元素dom節點上的屬性中。然後上面還有乙個不好的一點。那就是規則的定義方式不夠靈活。
比如我有兩個字段firstname
和lastname
。firstname
是必填的,而lastname
是非必填的;且firstname
長度要求大於1小於4而lastname
要求大於1小於6。那麼就要寫兩個不同的規則,現在只是2個字段而已,沒什麼,如果有很多個不同要求的字段,那要寫很多個不同的規則,也要寫很多個規則?豈不是很煩?能不能復用?
rules三種定義方式
函式的方式很強大,如果需要用到options
可以函式的方式,最常用的是物件和陣列的方式。現在推薦幾種復用的方法。
簡單的封裝一些常用的規則
// 返回乙個規則陣列,必填且字串長度在2~10之間
export const name = (msg, min = 2, max = 10, required = true) => ([
, ~$個字元`, trigger: 'blur' }
])// 郵箱
export const email = (required = true) => ([
, ])/* 自定義驗證規則 */
// 大於等於某個整數
const biggerandnum = num => (rule, v, cb) =>
if (v < num) `))
} return cb()
}export const biggerint = (int, required = true) => ([
, ])
封裝乙個專門建立規則的類,鏈式呼叫export default class createrules
need(msg = '必填', trigger = 'blur') )
return this
} url(message = '不是合法的鏈結', trigger = 'blur') )
return this
} get()
}const createrules = new createrules()
//規則
const needurl = createrules.need().url().get()
const isurl = createrules.url().get()
// imgurl必填且是鏈結;href可選不填,如果填寫必須是鏈結
const rules =
// deep rule 定義
// urls是陣列,長度大於1
// urls的元素是鏈結
const urls = ['', '']
const rules =
}
element有關表單驗證
表單驗證的基礎是官網的api rules 位置放置在el form標籤當中 例如 rules formrules formrules則是放在data當中,其結構為 最後會附上一些相關例項 formrules phone message 請輸入正確的手機號 當然,其中的條件是多種多樣的,根據自己的專案...
element 多個表單同時驗證
做後台管理專案 最常見的就是 的驗證了 簡單的表單是很簡單的 如果涉及到 內部巢狀表單 多表單同時驗證時及其他複雜驗證時 就相對就有些棘手了 下面我們就先講一下 多表單同時驗證的情況 顯然 多表單就是乙個頁面同時使用多個表單 通常不多見 先看下使用場景吧 單獨的每個標籤模組 都是乙個form 並不是...
element表單驗證的封裝
這一篇文章是在用element中的表單的時候,會用到正則來判斷表單的對錯,當然正則的話得自己寫,比如這樣 但是我們開發的時候就會發現如果兩個元件都用到了這個正則那麼就會產生重複性,這還只是兩個,一般的話不止兩個,會有很多,會產生很多的重複的正則,那麼,就很煩,因為我們是要追求優雅,簡介的,誒,碰到我...