【前端基礎】為什麼前端要檢核表單內容?低成本優化前端使用者體驗

閱讀時間約 6 分鐘

在前端的開發中,除了切版與串 API 外,大部分的時間都在針對表單內容進行檢核、驗證、阻擋,一方面是讓使用者在操作頁面的過程中有良好的使用者體驗,不會因為一些例外狀況(Edge Case),例如:莫名其妙的 4xx 錯誤,導致使用者卡在某個操作流程中逃不出來,另一方面是讓傳遞到後端的資料更加正確,避免浪費不必要的網路請求與運算成本。

即便前端資料檢核可以說是非常重要的步驟,越嚴謹的驗證規則越會讓工程師額外多花一些時間進行開發與測試,因此常常會聽到怕麻煩的前端工程師說:「後端有做檢核,為什麼前端還要再做一次?」

以前剛接觸前端的時候我也會困惑這個問題,隨著自己經手過幾個大型的電子商務平台後,才慢慢意識到前端表單檢核、驗證的好處,由於表單驗證的好處多過於壞處,我們就來聊聊前端偷懶不做表單驗證可能會發生的危機吧:

缺乏表單驗證可能會出現的網頁危機

  • SQL 注入:資料庫乘載著網路服務中最寶貴的財產:「資料」,假設今天前端在打 API 不驗證傳遞過去的資料格式,而後端工程師也沒經過額外的處理就把這串資料直接丟到資料庫裡,萬一這串挾帶的資料中有任何程式碼片段,都有可能直接性的侵入資料庫進行程式碼的執行,嚴重還會出現資料庫整個被打包加密勒索、使用者資料外洩的狀況。雖然 SQL 注入的安全性檢核後端可能需要負更大的責任,但對前端而言,擋住一些不正確的輸入值,可以大大減輕後端在檢核這一塊的負擔。
  • XSS 攻擊:假設前端工程師沒有針對一些特殊符號做過濾,惡意攻擊軟體、駭客有機會往輸入框塞一些可被執行的腳本,造成光是在網頁使用服務,就有可能造成使用者資料的外洩。
  • 不必要的伺服器成本:前端如果一直丟錯誤的資料格式到後端,可能會出現過多無效請求,直接影響到伺服器的維運成本,在一些以運算量為計價單位的雲服務,前端工程師的小偷懶,可能就會造成一些不必要的伺服器支出。
  • 干擾使用者體驗:如果前端一直丟不符合後端 API 規範的參數打 API ,可以預期回傳錯誤情境的狀況會大大提高,在好一點的狀況中,前端可能會用一些彈窗、提示訊息捕捉例外錯誤情境,告訴使用者目前有些錯誤,需要調整表單內容,但不經驗證的內容,就會造成這些錯誤訊息一直在頁面上瘋狂跳出,干擾使用者體驗。最不好的狀況就是:既不做表單驗證,也不使用一些頁面彈窗、提示訊息讓使用者知道當前的頁面狀況,網站很容易因此流失使用者。
  • 程式碼易出錯:姑且不論使用者的使用感受,不經驗證的欄位內容不僅難以從使用者介面上看出來,在程式碼的除錯也需要花額外的時間,也比較難在第一時間知道問題點:是資料沒有成功更新?事件沒有綁好? API 有成功打出去嗎?是 API 的參數不符合規範嗎?程式碼出錯的原因百百種,不寫表單驗證就是其中一種。

前端的驗證手段

經過上述的說明,大概可以理解前端的表單驗證除了在開發上會比較花時間外,基本上能稱得上百利無一害,接著就來聊聊前端一些針對格式的檢核方式:

  • 判斷是否為空值:在一個固定需要有值的欄位上,我們可以簡單寫一個 Util 函式來進行驗證,每當需要進行空值的檢核時就呼叫這個方法:
    const isEmpty = (value) => {
    return value === null || value === undefined || value === '';
    };
  • 判斷是否符合特殊規則:在一些電子信箱、電話、發票等,有固定格式的欄位上,可以透過 Regex(正則表達式)來進行檢核,個人覺得除了刷題的需求外,在一般實務開發中不太需要去背 Regex 的一些規則,有在使用一些 AI 工具(chatGPT、copilot)的話,也能快速產生一些規範:
    const basicFormValidator = {
    validateEmail: function(email) {
    const emailRegex = /^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,4}$/;
    return emailRegex.test(email);
    },
    validatePhone: function(phone) {
    const phoneRegex = /^\\d{10}$/;
    return phoneRegex.test(phone);
    },
    validateLandline: function(landline) {
    const landlineRegex = /^\\d{8}$/;
    return landlineRegex.test(landline);
    },
    validatePassword: function(password) {
    // 設定你的密碼驗證規則,這只是一個範例
    const passwordRegex = /^(?=.*[A-Za-z])(?=.*\\d)[A-Za-z\\d]{8,}$/;
    return passwordRegex.test(password);
    }
    };

    // 使用範例
    const email = '[email protected]';
    const phone = '1234567890';
    const landline = '23456789';
    const password = 'P@ssw0rd';

    console.log(basicFormValidator.validateEmail(email)); // true
    console.log(basicFormValidator.validatePhone(phone)); // true
    console.log(basicFormValidator.validateLandline(landline)); // true
    console.log(basicFormValidator.validatePassword(password)); // true

以上只能檢核最基本的資料正確性,避免在打 API 時,出現不必要的請求錯誤,至於一些避免攻擊手段的方式,目前還沒有理解到很多,也許之後有機會可以再跟大家分享。

希望今天的文章可以讓大家更加理解前端做表單檢核的重要性與必要性,如果有任何問題都歡迎在下方留言跟我說,我是 Vivian,我們下次見!

為了追求可以窩在座位上、可以心無旁騖思考問題、座位可以亂七八糟沒關係、不需要到處哈腰點頭跑客戶,不用腳踩十公分、連妝都可以不用化的職場人生,文組少女毅然決然踏上RD的養成日常。
留言0
查看全部
發表第一個留言支持創作者!
在 2021 年的剛轉職成為前端工程師的時候,我在面試時滿常會被詢問到 JavaScript 中閉包的議題,當時候自己回答的滿差的,於是在 2022 年時,我寫了一系列的有關於函式程式設計鐵人賽的文章, 裡頭就有簡單提到有關於閉包的議題。
在之前的文章當中曾經提到過 JavaScript 中的物件有一個特別的機制:傳參考(Called by reference),如果正確性再高一點的話,則可以稱之為傳共享(Called by sharing)。
在先前的型別文章中,我們曾經聊過 JavaScript 常用的一些型別,但針對布林這個型別,我們沒有做太多的解釋,原因在於布林值在 JavaScript 會有一個特殊的規則:自動轉型 。 自動轉型可說是讓 JavaScript 為弱型別、且難以管理的最重要的要素,接著就來讓我們來聊聊什麼是自動轉型
在剛開始寫 JavaScript 可能大多數的人不會特別意識到 JavaScript 的型別系統有什麼特別之處,我是在看完 Youtube 上 CS50 的課程,才理解到在不同的程式語言中,會因為語言的特性而有不同的系統,JavaScript 就是偏向比較特別的那一種。
在前端開發中,很常會有需要轉址的需求,且處理的手法滿因人而異的,所以今天就想要來整理一些常見的 JavaScript 頁面轉址方式,以及各自的差異。
Functional Programming 中文譯作函式程式設計,或是功能性程式設計,常簡稱為:FP,是一種透過使用純函式(Pure Funciton)進行軟體開發,且避免副作用的程式設計典範,比起宣告式的流程控制,在 FP 採用主要以表達式的方式撰寫程式碼。
在 2021 年的剛轉職成為前端工程師的時候,我在面試時滿常會被詢問到 JavaScript 中閉包的議題,當時候自己回答的滿差的,於是在 2022 年時,我寫了一系列的有關於函式程式設計鐵人賽的文章, 裡頭就有簡單提到有關於閉包的議題。
在之前的文章當中曾經提到過 JavaScript 中的物件有一個特別的機制:傳參考(Called by reference),如果正確性再高一點的話,則可以稱之為傳共享(Called by sharing)。
在先前的型別文章中,我們曾經聊過 JavaScript 常用的一些型別,但針對布林這個型別,我們沒有做太多的解釋,原因在於布林值在 JavaScript 會有一個特殊的規則:自動轉型 。 自動轉型可說是讓 JavaScript 為弱型別、且難以管理的最重要的要素,接著就來讓我們來聊聊什麼是自動轉型
在剛開始寫 JavaScript 可能大多數的人不會特別意識到 JavaScript 的型別系統有什麼特別之處,我是在看完 Youtube 上 CS50 的課程,才理解到在不同的程式語言中,會因為語言的特性而有不同的系統,JavaScript 就是偏向比較特別的那一種。
在前端開發中,很常會有需要轉址的需求,且處理的手法滿因人而異的,所以今天就想要來整理一些常見的 JavaScript 頁面轉址方式,以及各自的差異。
Functional Programming 中文譯作函式程式設計,或是功能性程式設計,常簡稱為:FP,是一種透過使用純函式(Pure Funciton)進行軟體開發,且避免副作用的程式設計典範,比起宣告式的流程控制,在 FP 採用主要以表達式的方式撰寫程式碼。
你可能也想看
Google News 追蹤
Thumbnail
接下來第二部分我們持續討論美國總統大選如何佈局, 以及選前一週到年底的操作策略建議 分析兩位候選人政策利多/ 利空的板塊和股票
Thumbnail
🤔為什麼團長的能力是死亡筆記本? 🤔為什麼像是死亡筆記本呢? 🤨作者巧思-讓妮翁死亡合理的幾個伏筆
發送表單用get跟post看起來好像都無所謂,然而事實並非如此,使用GET的風險如下: 安全性問題 機密資訊為何不宜用GET,是因為由GET方法提交的表單會將欄位的key,value顯示於URL上,想像一下如果小明借用你的電腦,查看你的網頁歷史紀錄時就可以看到你的帳密了,多可怕! 再來就是如果
Thumbnail
這篇文章更偏向純紀錄性質,方便日後有需要時直接複製相同指令來完成 Bootstrap 與 Sass 的引入,也會做成一個專案起手式的模板放在 Github ,未來在建置新專案時可以透過直接複製專案,來省去前面重複的這過程。
Thumbnail
在參加 2022 年六角學院舉辦的公益程式體驗營之後,我認知到一個專業具有就職水準的切版能力不是只是會 html、css 以及一些 css framework 就足夠,魔鬼藏在細節裡,而我想要朝專業級前進。 文章節錄當時的檢核點,作為日後開發的 check list。
Thumbnail
微前端是一種現代前端架構,旨在將大型前端應用拆分為獨立、可獨立部署的小模組。這與微服務在後端的策略相似。 本文將探討微前端的基本概念,以及如何在基於Gin的後端系統中實施它,從而實現真正的全棧模組化。
Thumbnail
JavaScript 的命名規則相當重要,它有些特定的慣例和限制。例如,變數和函式通常使用小駝峰式(firstName)命名。然後 JavaScript 對大小寫敏感,所以lastName和lastname是不同的變數。
Thumbnail
npm 是一個套件管理工具,開發中經常需要使用第三方套件,npm 是可以用來管理很多套件的工具,這邊指的套件可能是 Library, 框架, 工具等,例如 Bootstrap, jQuery, Vue.js, babel 都可以統一由它管理。
Thumbnail
本文題目來自網站codesignal,它是個可依自己選取的程式語言進行測驗,測驗難易程度會逐題增加,可透過解題來獲得分數以及徽章,相當有趣味性。在sumbit後可在左欄看到票選最高的解法,這些解法來自不同語言,當然你可以在上面篩選自己撰寫的程式語言。沒有所謂的最好的解法,只有最適合的方式。
Thumbnail
在一個風和日麗的下午,又一個JS模組/框架誕生了! 我為這個議題準備了大概兩天時間,我憑著記憶回溯過去十年到底前端圈發生什麼事,再花了不少時間去求證和紀錄分類,然而這個議題是在太大,我最後選擇了一個方向來撰寫這篇文章,不過有興趣的人,可以看看我的筆記- TLDR -
Thumbnail
接下來第二部分我們持續討論美國總統大選如何佈局, 以及選前一週到年底的操作策略建議 分析兩位候選人政策利多/ 利空的板塊和股票
Thumbnail
🤔為什麼團長的能力是死亡筆記本? 🤔為什麼像是死亡筆記本呢? 🤨作者巧思-讓妮翁死亡合理的幾個伏筆
發送表單用get跟post看起來好像都無所謂,然而事實並非如此,使用GET的風險如下: 安全性問題 機密資訊為何不宜用GET,是因為由GET方法提交的表單會將欄位的key,value顯示於URL上,想像一下如果小明借用你的電腦,查看你的網頁歷史紀錄時就可以看到你的帳密了,多可怕! 再來就是如果
Thumbnail
這篇文章更偏向純紀錄性質,方便日後有需要時直接複製相同指令來完成 Bootstrap 與 Sass 的引入,也會做成一個專案起手式的模板放在 Github ,未來在建置新專案時可以透過直接複製專案,來省去前面重複的這過程。
Thumbnail
在參加 2022 年六角學院舉辦的公益程式體驗營之後,我認知到一個專業具有就職水準的切版能力不是只是會 html、css 以及一些 css framework 就足夠,魔鬼藏在細節裡,而我想要朝專業級前進。 文章節錄當時的檢核點,作為日後開發的 check list。
Thumbnail
微前端是一種現代前端架構,旨在將大型前端應用拆分為獨立、可獨立部署的小模組。這與微服務在後端的策略相似。 本文將探討微前端的基本概念,以及如何在基於Gin的後端系統中實施它,從而實現真正的全棧模組化。
Thumbnail
JavaScript 的命名規則相當重要,它有些特定的慣例和限制。例如,變數和函式通常使用小駝峰式(firstName)命名。然後 JavaScript 對大小寫敏感,所以lastName和lastname是不同的變數。
Thumbnail
npm 是一個套件管理工具,開發中經常需要使用第三方套件,npm 是可以用來管理很多套件的工具,這邊指的套件可能是 Library, 框架, 工具等,例如 Bootstrap, jQuery, Vue.js, babel 都可以統一由它管理。
Thumbnail
本文題目來自網站codesignal,它是個可依自己選取的程式語言進行測驗,測驗難易程度會逐題增加,可透過解題來獲得分數以及徽章,相當有趣味性。在sumbit後可在左欄看到票選最高的解法,這些解法來自不同語言,當然你可以在上面篩選自己撰寫的程式語言。沒有所謂的最好的解法,只有最適合的方式。
Thumbnail
在一個風和日麗的下午,又一個JS模組/框架誕生了! 我為這個議題準備了大概兩天時間,我憑著記憶回溯過去十年到底前端圈發生什麼事,再花了不少時間去求證和紀錄分類,然而這個議題是在太大,我最後選擇了一個方向來撰寫這篇文章,不過有興趣的人,可以看看我的筆記- TLDR -