การใช้การตรวจสอบความถูกต้องของฟอร์ม HTML ยังน้อยเกินไป

 (expressionstatement.com)
2 คะแนน โดย GN⁺ 2024-10-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การใช้งานการตรวจสอบความถูกต้องของฟอร์ม HTML ที่ยังต่ำ

  • ฟอร์ม HTML มีกลไกการตรวจสอบความถูกต้องที่ทรงพลัง แต่กลับไม่ค่อยถูกใช้งาน หลายคนไม่ค่อยรู้เรื่องนี้ ซึ่งอาจเป็นเพราะข้อบกพร่องด้านการออกแบบ

แอตทริบิวต์ เมธอด และพร็อพเพอร์ตี

  • สามารถเพิ่มแอตทริบิวต์ required เพื่อป้องกันการปล่อยอินพุตว่างได้
  • มี 3 วิธีในการเพิ่มข้อจำกัดให้กับอินพุต:
    • ใช้ค่าแอตทริบิวต์ type เฉพาะ: "email", "number", "url"
    • ใช้แอตทริบิวต์อินพุตอื่น เช่น "pattern" หรือ "maxlength"
    • ใช้ DOM method setCustomValidity: เป็นวิธีที่ทรงพลังที่สุดสำหรับสร้างตรรกะการตรวจสอบแบบกำหนดเองและรองรับกรณีที่ซับซ้อน

ความละเอียดอ่อนของ API แบบ imperative

  • API setCustomValidity มีให้ใช้งานในรูปเมธอดเท่านั้น จึงใช้งานได้ไม่สะดวก
  • ตัวอย่างเช่น สามารถทำงานแบบเดียวกับแอตทริบิวต์ required เพื่อป้องกันการส่งฟอร์มเมื่ออินพุตว่างได้
  • หากอินพุตว่างตั้งแต่ตอนเรนเดอร์ครั้งแรก ก็ต้องตั้งค่าให้เป็นสถานะไม่ถูกต้องตั้งแต่ต้น

ปัญหา boilerplate

  • วิธีตรวจสอบค่าเริ่มต้นทำได้ยุ่งยาก
  • ตรรกะการตรวจสอบซ้ำกันทั้งในตัวจัดการ onChange และในขั้นตอนเรนเดอร์ครั้งแรก
  • การใช้ useRef + useLayoutEffect + onChange ร่วมกันมีความซับซ้อน

ส่วนที่ขาดหายไป

  • จำเป็นต้องมีพร็อพเพอร์ตี custom-validity
  • จะช่วยให้สามารถกำหนดการตรวจสอบอินพุตได้อย่างทรงพลังในเฟรมเวิร์กแบบประกาศ

พลังของการตรวจสอบแบบอะซิงก์

  • สามารถรองรับกรณีที่ชื่อผู้ใช้จะถือว่าถูกต้อง ก็ต่อเมื่อยังไม่ถูกใช้งาน
  • ต้องมีการเรียกแบบอะซิงก์ไปยังเซิร์ฟเวอร์ และต้องมีสถานะระหว่างทาง

การนำไปใช้

  • ใช้ฟังก์ชัน verifyUsername เพื่อตรวจสอบความไม่ซ้ำของชื่อผู้ใช้
  • ใช้ useQuery เพื่อจัดการสถานะของคำขอไปยังเซิร์ฟเวอร์
  • ใช้พร็อพเพอร์ตี customValidity เพื่ออธิบายโฟลว์การตรวจสอบแบบอะซิงก์

ฟอร์มยืนยันรหัสผ่าน

  • สร้างฟอร์มที่ต้องกรอกรหัสผ่านเดิมซ้ำอีกครั้ง
  • ตรวจสอบความถูกต้องด้วยการเช็กว่าฟิลด์อินพุตทั้งสองตรงกันหรือไม่

บทสรุป

  • setCustomValidity สามารถตอบโจทย์ความต้องการด้านการตรวจสอบความถูกต้องได้หลากหลาย
  • API ที่ทรงพลังมอบพลังที่แท้จริง
  • หวังว่าความสามารถนี้จะถูกเพิ่มเข้าไปในสเปก HTML

สรุปโดย GN⁺

  • การตรวจสอบความถูกต้องของฟอร์ม HTML ทรงพลัง แต่ยังไม่ค่อยถูกใช้งาน ซึ่งอาจเป็นเพราะความซับซ้อนของ API
  • เมธอด setCustomValidity เป็นเครื่องมือที่ทรงพลังสำหรับจัดการตรรกะการตรวจสอบที่ซับซ้อน
  • มีการนำเสนอวิธีจัดการสถานการณ์ที่ซับซ้อน เช่น การตรวจสอบแบบอะซิงก์
  • บทความนี้ให้ข้อมูลที่มีประโยชน์เพื่อช่วยให้นักพัฒนานำการตรวจสอบความถูกต้องของฟอร์ม HTML ไปใช้ได้ดียิ่งขึ้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-29
ความเห็นจาก Hacker News

  • เว็บเบราว์เซอร์ยังคงไม่สามารถปรับแต่งสไตล์ของข้อความตรวจสอบความถูกต้อง HTML ที่มีมาในตัวได้ และ Chrome กับ Firefox ก็ไม่ทำตามแนวทาง UI ของแพลตฟอร์ม OS ทำให้ขัดกับความสวยงามของโปรเจกต์

    • ก่อนหน้านี้ Chrome เคยให้ปรับแต่งสไตล์ข้อความตรวจสอบความถูกต้องได้ด้วยตัวเลือก pseudo-element ที่มี vendor prefix แต่ความสามารถนี้ถูกลบออกไปแล้ว
    • มีการบ่นถึงการใช้งาน HTML combobox และ <select multiple> ที่ไม่มีประสิทธิภาพ

  • การใช้ค่า type บางแบบ (เช่น "email", "number", "url") สามารถเรียกคีย์บอร์ดที่เหมาะสมที่สุดบนมือถือได้ จึงช่วยยกระดับประสบการณ์ผู้ใช้ได้มาก

  • คนที่เขียนสเปกห่างไกลจากการใช้งานจริง เหมาะกับเรื่องง่าย ๆ แต่ถ้าเป็นฟอร์มซับซ้อน เขียนเองจะดีกว่า

  • รู้สึกเสียดายที่เคยมองข้ามความเรียบง่ายพื้นฐานของฟอร์ม และขอบคุณที่ช่วยแบ่งปันมุมมองของคนอื่น

  • มีข้อขอให้เพิ่มแอตทริบิวต์ "for" ให้ label เมื่อมี label สำหรับ checkbox เพื่อให้คลิกที่ label แล้วสั่งเปิด/ปิด checkbox ได้

  • มีตัวอย่างง่าย ๆ ที่ไม่ใช้ React

  • การตรวจสอบความถูกต้องของฟอร์ม HTML นั้นยอดเยี่ยม แต่มีปัญหาใหญ่คือใช้ไม่ได้บน Firefox for Android

  • มีเฟรมเวิร์กและไลบรารีจำนวนมากที่ให้ฟีเจอร์ตรวจสอบความถูกต้องแบบปรับแต่งสไตล์ได้อยู่แล้ว จึงไม่จำเป็นต้องฝืนลำบาก

  • ควรระวังไม่ใช้การตรวจสอบความถูกต้องมากเกินไป

    • เคยมีประสบการณ์ว่าตอนขอคืนเงินกับ Groupon ต้องมาตรวจ HTML เพราะมีเงื่อนไขว่า "อย่างน้อย 15 คำ"
    • แพตเทิร์นการตรวจสอบไม่ยอมให้มีเครื่องหมายวรรคตอนเลย

  • เว็บไซต์ที่ใช้ type=password ผิดกับช่องกรอก 2FA จะทำให้ตัวจัดการรหัสผ่านและเบราว์เซอร์สับสน