เผยแพร่: 22 กรกฎาคม 2021
การกำหนดเส้นทางเป็นส่วนสำคัญของเว็บแอปพลิเคชันทุกรายการ โดยหลักการแล้ว การกำหนดเส้นทางจะใช้ URL แล้วใช้การจับคู่รูปแบบหรือตรรกะอื่นๆ ที่เฉพาะเจาะจงกับแอป จากนั้นโดยปกติจะแสดงเนื้อหาเว็บตามผลลัพธ์ การกำหนดเส้นทางอาจ ติดตั้งใช้งานได้หลายวิธี ดังนี้
- โค้ดเซิร์ฟเวอร์ที่แมปเส้นทางไปยังไฟล์ในดิสก์
- ตรรกะในแอปหน้าเดียวที่รอการเปลี่ยนแปลงตำแหน่งปัจจุบัน จากนั้นสร้างและแสดง DOM ที่เกี่ยวข้อง
แม้ว่าจะไม่มีมาตรฐานที่แน่นอน แต่เว็บดีเวลอปเปอร์ก็หันมาใช้ไวยากรณ์ทั่วไปในการแสดงรูปแบบการกำหนดเส้นทาง URL ซึ่งมีหลายอย่างที่เหมือนกับ regular expressions
แต่มีการเพิ่มเฉพาะโดเมนบางอย่าง เช่น โทเค็นสำหรับการจับคู่กลุ่มเส้นทาง
เฟรมเวิร์กฝั่งเซิร์ฟเวอร์ยอดนิยม เช่น Express และ Ruby on Rails ใช้ไวยากรณ์นี้ (หรือไวยากรณ์ที่คล้ายกันมาก) และนักพัฒนา JavaScript สามารถใช้โมดูล เช่น path-to-regexp หรือ regexpparam เพื่อเพิ่มตรรกะดังกล่าวลงในโค้ดของตนเองได้
URLPattern
เป็นส่วนเสริมของแพลตฟอร์มเว็บที่สร้างขึ้นบนรากฐานที่สร้างขึ้น
โดยเฟรมเวิร์กเหล่านี้ โดยมีเป้าหมายเพื่อกำหนดรูปแบบไวยากรณ์การกำหนดเส้นทางให้เป็นมาตรฐาน
รวมถึงการรองรับอักขระไวด์การ์ด กลุ่มโทเค็นที่มีชื่อ กลุ่มนิพจน์ทั่วไป
และตัวแก้ไขกลุ่ม URLPatternอินสแตนซ์ที่สร้างด้วยไวยากรณ์นี้
สามารถทำงานด้านการกำหนดเส้นทางทั่วไปได้ เช่น การจับคู่กับ URL แบบเต็มหรือ URL
pathname
และการแสดงข้อมูลเกี่ยวกับการจับคู่โทเค็นและกลุ่ม
อีกข้อดีของการระบุการจับคู่ URL โดยตรงในแพลตฟอร์มเว็บคือ คุณจะแชร์ไวยากรณ์ทั่วไปกับ API อื่นๆ ที่ต้องจับคู่กับ URL ได้ด้วย
การรองรับเบราว์เซอร์และ Polyfill
URLPattern จะเปิดใช้โดยค่าเริ่มต้นใน Chrome และ Edge เวอร์ชัน 95 ขึ้นไป
ไลบรารี
urlpattern-polyfill
มีวิธีใช้URLPatternอินเทอร์เฟซในเบราว์เซอร์
หรือสภาพแวดล้อมอย่าง Node ที่ไม่มีการรองรับในตัว หากใช้ Polyfill ให้ตรวจสอบว่าคุณใช้การตรวจหาฟีเจอร์เพื่อให้แน่ใจว่าคุณจะโหลด Polyfill ก็ต่อเมื่อสภาพแวดล้อมปัจจุบันไม่รองรับ ไม่เช่นนั้น
คุณจะเสียสิทธิประโยชน์หลักอย่างหนึ่งของ URLPattern นั่นคือ
สภาพแวดล้อมที่รองรับไม่จำเป็นต้องดาวน์โหลดและแยกวิเคราะห์โค้ดเพิ่มเติมเพื่อ
ใช้งาน
if (!(globalThis && 'URLPattern' in globalThis)) {
// URLPattern is not available, so the polyfill is needed.
}
ความเข้ากันได้ของไวยากรณ์
ปรัชญาที่ชี้นำสำหรับ URLPattern คือการหลีกเลี่ยงการประดิษฐ์ซ้ำ หากคุณคุ้นเคยกับไวยากรณ์การกำหนดเส้นทางที่ใช้ใน Express หรือ Ruby on Rails อยู่แล้ว คุณก็ไม่จำเป็นต้องเรียนรู้สิ่งใหม่ๆ แต่เนื่องจากไวยากรณ์ในไลบรารีการกำหนดเส้นทางยอดนิยมมีความแตกต่างกันเล็กน้อย
จึงต้องเลือกไวยากรณ์หนึ่งเป็นไวยากรณ์พื้นฐาน
และผู้ออกแบบ URLPattern ตัดสินใจใช้ไวยากรณ์รูปแบบ
จาก path-to-regexp (แม้ว่าจะไม่ใช่พื้นผิว API) เป็นจุดเริ่มต้น
การตัดสินใจนี้เกิดขึ้นหลังจากที่ได้ปรึกษาหารืออย่างใกล้ชิดกับผู้ดูแลปัจจุบันของ
path-to-regexp
วิธีที่ดีที่สุดในการทำความคุ้นเคยกับแกนหลักของไวยากรณ์ที่รองรับคือการดูเอกสารประกอบสำหรับ
path-to-regexp คุณสามารถ
อ่านเอกสารประกอบ
ที่ตั้งใจจะเผยแพร่ใน MDN ได้ในที่อยู่ปัจจุบัน
บน GitHub
ฟีเจอร์เพิ่มเติม
ไวยากรณ์ของ URLPattern เป็นซูเปอร์เซ็ตของสิ่งที่ path-to-regexp รองรับ เนื่องจาก URLPattern รองรับฟีเจอร์ที่ไม่ค่อยพบในไลบรารีการกำหนดเส้นทาง นั่นคือ การจับคู่ต้นทาง รวมถึงไวลด์การ์ดในชื่อโฮสต์ ไลบรารีการกำหนดเส้นทางอื่นๆ ส่วนใหญ่จะจัดการกับpathname
และบางครั้งก็จัดการกับส่วนค้นหาหรือแฮชของ
URL ผู้ใช้ไม่จำเป็นต้องตรวจสอบส่วนต้นทางของ URL เนื่องจากใช้สำหรับการกำหนดเส้นทางแบบต้นทางเดียวกันภายในเว็บแอปแบบสแตนด์อโลนเท่านั้น
การพิจารณาต้นทางจะเปิดโอกาสให้ใช้กรณีการใช้งานเพิ่มเติม เช่น
การกำหนดเส้นทางคำขอข้ามต้นทางภายใน
Service Worker
fetch ตัวแฮนเดิลเหตุการณ์ หากคุณกำหนดเส้นทางเฉพาะ URL ที่มีต้นทางเดียวกัน คุณก็สามารถ
ไม่สนใจฟีเจอร์เพิ่มเติมนี้และใช้ URLPattern เหมือนกับ
ไลบรารีอื่นๆ ได้
ตัวอย่าง
การสร้างรูปแบบ
หากต้องการสร้าง URLPattern ให้ส่งตัวสร้างเป็นสตริงหรือออบเจ็กต์ที่มี
พร็อพเพอร์ตี้ซึ่งมีข้อมูลเกี่ยวกับรูปแบบที่จะใช้จับคู่
การส่งออบเจ็กต์จะให้การควบคุมที่ชัดเจนที่สุดเกี่ยวกับรูปแบบที่จะใช้ในการ จับคู่คอมโพเนนต์ URL แต่ละรายการ ในโหมด Verbose สูงสุด คำสั่งนี้จะมีลักษณะดังนี้
const p = new URLPattern({
protocol: 'https',
username: '',
password: '',
hostname: 'example.com',
port: '',
pathname: '/foo/:image.jpg',
search: '*',
hash: '*',
});
การระบุสตริงว่างสำหรับพร็อพเพอร์ตี้จะตรงกันก็ต่อเมื่อไม่ได้ตั้งค่าส่วนที่เกี่ยวข้องของ URL ไวลด์การ์ด * จะจับคู่กับค่าใดก็ได้สำหรับส่วนที่กำหนดของ URL
ตัวสร้างมีแป้นพิมพ์ลัดหลายรายการเพื่อให้ใช้งานได้ง่ายขึ้น การละเว้น search และ hash หรือพร็อพเพอร์ตี้อื่นๆ ทั้งหมดเทียบเท่ากับการตั้งค่าเป็นไวลด์การ์ด '*' ตัวอย่างนี้สามารถลดความซับซ้อนได้เป็น
const p = new URLPattern({
protocol: 'https',
username: '',
password: '',
hostname: 'example.com',
port: '',
pathname: '/foo/:image.jpg',
});
นอกจากนี้ คุณยังระบุข้อมูลทั้งหมดเกี่ยวกับต้นทางได้ในพร็อพเพอร์ตี้เดียว baseURL ซึ่งจะนำไปสู่
const p = new URLPattern({
pathname: '/foo/:image.jpg',
baseURL: 'https://example.com',
});
ตัวอย่างทั้งหมดนี้ถือว่ากรณีการใช้งานของคุณเกี่ยวข้องกับต้นทางที่ตรงกัน หากคุณสนใจเฉพาะการจับคู่ในส่วนอื่นๆ ของ URL โดยไม่รวมต้นทาง (เช่น ในกรณีของสถานการณ์การกำหนดเส้นทางแบบต้นทางเดียวหลายๆ สถานการณ์) คุณก็ละเว้นข้อมูลต้นทางทั้งหมดได้ และเพียงระบุชุดค่าผสมของพร็อพเพอร์ตี้ pathname, search และ hash เช่นเดียวกับก่อนหน้านี้
ระบบจะถือว่าพร็อพเพอร์ตี้ที่ละเว้นนั้นตั้งค่าเป็นรูปแบบไวลด์การ์ด *
const p = new URLPattern({pathname: '/foo/:image.jpg'});
คุณสามารถระบุสตริง 1 หรือ 2 รายการแทนการส่งออบเจ็กต์ไปยังตัวสร้างได้ หากระบุสตริงเดียว สตริงนั้นควรแสดงรูปแบบ URL แบบเต็ม รวมถึงข้อมูลรูปแบบที่ใช้เพื่อจับคู่ต้นทาง หากคุณ
ระบุสตริง 2 รายการ สตริงที่ 2 จะใช้เป็น baseURL และสตริงแรก
จะถือว่าสัมพันธ์กับฐานนั้น
ไม่ว่าจะระบุสตริง 1 หรือ 2 สตริง คอนสตรัคเตอร์ URLPattern จะแยกวิเคราะห์รูปแบบ URL แบบเต็ม แบ่งออกเป็นคอมโพเนนต์ URL และแมปแต่ละส่วนของรูปแบบที่ใหญ่กว่ากับคอมโพเนนต์ที่เกี่ยวข้อง
ซึ่งหมายความว่าในเบื้องหลัง URLPattern แต่ละรายการที่สร้างด้วยสตริงจะแสดงเหมือนกับ URLPattern ที่เทียบเท่ากันซึ่งสร้างด้วยออบเจ็กต์
ตัวสร้างสตริงเป็นเพียงทางลัดสำหรับผู้ที่ต้องการอินเทอร์เฟซที่
ไม่ยาวมาก
const p = new URLPattern('https://example.com/foo/:image.jpg?*#*');
เมื่อใช้สตริงเพื่อสร้าง URLPattern โปรดคำนึงถึงข้อควรระวังต่อไปนี้
การเว้นพร็อพเพอร์ตี้ไว้เมื่อใช้ออบเจ็กต์เพื่อสร้าง URLPattern จะเทียบเท่ากับการระบุไวลด์การ์ด * สำหรับพร็อพเพอร์ตี้นั้น เมื่อมีการแยกวิเคราะห์รูปแบบสตริง URL แบบเต็ม หากส่วนประกอบ URL ใดไม่มีค่า ระบบจะถือว่ามีการตั้งค่าพร็อพเพอร์ตี้ของส่วนประกอบเป็น '' ซึ่งจะตรงกันก็ต่อเมื่อส่วนประกอบนั้นว่างเปล่า
เมื่อใช้สตริง คุณต้องระบุไวลด์การ์ดอย่างชัดเจนหากต้องการให้ใช้ใน URLPattern ที่สร้างขึ้น
// p1 and p2 are equivalent.
const p1 = new URLPattern('/foo', location.origin);
const p2 = new URLPattern({
protocol: location.protocol,
hostname: location.hostname,
pathname: '/foo',
search: '',
hash: '',
});
// p3 and p4 are equivalent.
const p3 = new URLPattern('/foo?*#*', location.origin);
const p4 = new URLPattern({
protocol: location.protocol,
hostname: location.hostname,
pathname: '/foo',
});
นอกจากนี้ คุณควรทราบว่าการแยกวิเคราะห์รูปแบบสตริงเป็นคอมโพเนนต์ต่างๆ อาจ
ไม่ชัดเจน มีอักขระ เช่น : ที่พบใน URL
แต่ก็มีความหมายพิเศษในไวยากรณ์การจับคู่รูปแบบด้วย เพื่อหลีกเลี่ยงความคลุมเครือนี้ ตัวสร้าง URLPattern จะถือว่าอักขระพิเศษเหล่านั้นเป็นส่วนหนึ่งของรูปแบบ ไม่ใช่ส่วนหนึ่งของ URL หากต้องการให้ระบบตีความอักขระที่ไม่ชัดเจน
เป็นส่วนหนึ่งของ URL โปรดตรวจสอบว่าได้หลีกเลี่ยงอักขระดังกล่าวด้วย
\` character. For example, the literal URLabout:blankshould be escaped as'about\:blank'` เมื่อระบุเป็นสตริง
ใช้รูปแบบ
หลังจากสร้าง URLPattern แล้ว คุณจะมีตัวเลือกในการใช้งาน 2 ตัวเลือก ทั้งเมธอด
test()และexec()รับอินพุตเดียวกันและใช้อัลกอริทึมเดียวกัน
เพื่อตรวจสอบรายการที่ตรงกัน และแตกต่างกันเฉพาะค่าที่ส่งคืน test()
จะแสดงผล true เมื่ออินพุตที่ระบุตรงกัน และแสดงผล false ในกรณีอื่นๆ
exec() จะแสดงข้อมูลโดยละเอียดเกี่ยวกับการจับคู่พร้อมกับกลุ่มการจับคู่
หรือ null หากไม่มีการจับคู่ ตัวอย่างต่อไปนี้แสดงการใช้ exec() แต่คุณสามารถแทนที่ด้วย test() สำหรับตัวอย่างใดก็ได้หากต้องการค่าบูลีนที่แสดงผลเท่านั้น
วิธีหนึ่งในการใช้วิธี test() และ exec() คือการส่งสตริง
เช่นเดียวกับที่ตัวสร้างรองรับ หากมีการระบุสตริงเดียว สตริงนั้นควรเป็น URL แบบเต็ม รวมถึงต้นทาง หากระบุสตริง 2 รายการ สตริงที่ 2 จะถือเป็นค่า baseURL และสตริงแรกจะได้รับการประเมิน
โดยอิงตามฐานนั้น
const p = new URLPattern({
pathname: '/foo/:image.jpg',
baseURL: 'https://example.com',
});
const result = p.exec('https://example.com/foo/cat.jpg');
// result will contain info about the successful match.
// const result = p.exec('/foo/cat.jpg', 'https://example.com')
// is equivalent, using the baseURL syntax.
const noMatchResult = p.exec('https://example.com/bar');
// noMatchResult will be null.
หรือจะส่งออบเจ็กต์ประเภทเดียวกันกับที่ตัวสร้าง รองรับ โดยมีพร็อพเพอร์ตี้ที่ตั้งค่าเป็นเฉพาะส่วนของ URL ที่คุณสนใจ ในการจับคู่ก็ได้
const p = new URLPattern({pathname: '/foo/:image.jpg'});
const result = p.exec({pathname: '/foo/:image.jpg'});
// result will contain info about the successful match.
เมื่อใช้ exec() ใน URLPattern ที่มีอักขระไวด์การ์ดหรือโทเค็น ค่าที่ส่งคืนจะให้ข้อมูลเกี่ยวกับค่าที่สอดคล้องกันใน URL อินพุต ซึ่งจะช่วยให้คุณไม่ต้องเสียเวลาแยกวิเคราะห์ค่าเหล่านั้นด้วยตนเอง
const p = new URLPattern({
hostname: ':subdomain.example.com',
pathname: '/*/:image.jpg'
});
const result = p.exec('https://imagecdn1.example.com/foo/cat.jpg');
// result.hostname.groups.subdomain will be 'imagecdn1'
// result.pathname.groups[0] will be 'foo', corresponding to *
// result.pathname.groups.image will be 'cat'
กลุ่มที่ไม่ระบุชื่อและกลุ่มที่มีชื่อ
เมื่อส่งสตริง URL ไปยัง exec() คุณจะได้รับค่าที่บอกว่าส่วนใดที่ตรงกับกลุ่มทั้งหมดของรูปแบบ
ค่าที่ส่งคืนมีพร็อพเพอร์ตี้ที่สอดคล้องกับคอมโพเนนต์ของ
URLPattern เช่น pathname ดังนั้นหากกำหนดกลุ่มเป็นส่วนหนึ่งของส่วน pathname ของ URLPattern คุณจะพบการจับคู่ใน pathname.groups ของค่าที่ส่งคืน การจับคู่จะแสดงแตกต่างกัน
โดยขึ้นอยู่กับว่ารูปแบบที่เกี่ยวข้องเป็นกลุ่มที่ไม่ระบุชื่อหรือกลุ่มที่มีชื่อ
คุณสามารถใช้ดัชนีอาร์เรย์เพื่อเข้าถึงค่าสำหรับการจับคู่รูปแบบที่ไม่ระบุตัวตน
หากมีรูปแบบที่ไม่ระบุชื่อหลายรูปแบบ ดัชนี 0 จะแสดงค่าที่ตรงกัน
สำหรับรูปแบบทางซ้ายสุด โดยใช้ 1 และดัชนีอื่นๆ สำหรับรูปแบบที่ตามมา
เมื่อใช้กลุ่มที่มีชื่อในรูปแบบ การจับคู่จะแสดงเป็นพร็อพเพอร์ตี้ ซึ่งมีชื่อที่สอดคล้องกับชื่อกลุ่มแต่ละชื่อ
การรองรับและการแปลง Unicode
URLPattern รองรับอักขระ Unicode ในหลายวิธี
กลุ่มที่มีชื่อ เช่น
:caféสามารถมีอักขระ Unicode ได้ กฎที่ใช้สำหรับตัวระบุ JavaScript ที่ถูกต้อง จะมีผลกับกลุ่มที่มีชื่อระบบจะเข้ารหัสข้อความภายในรูปแบบโดยอัตโนมัติตามกฎเดียวกันกับที่ใช้สำหรับการเข้ารหัส URL ของคอมโพเนนต์นั้นๆ อักขระ Unicode ภายใน
pathnameจะเข้ารหัสด้วยเครื่องหมายเปอร์เซ็นต์ ดังนั้นรูปแบบpathnameเช่น/caféจะได้รับการแปลงเป็นรูปแบบมาตรฐานเป็น/caf%C3%A9โดยอัตโนมัติ ระบบจะเข้ารหัสอักขระ Unicode ในhostnameโดยอัตโนมัติ โดยใช้ Punycode แทน การเข้ารหัสเปอร์เซ็นต์กลุ่มนิพจน์ทั่วไปต้องมีเฉพาะอักขระ ASCII เท่านั้น ไวยากรณ์นิพจน์ทั่วไปทำให้การเข้ารหัสอักขระ Unicode ในกลุ่มเหล่านี้โดยอัตโนมัติเป็นเรื่องยากและไม่ปลอดภัย หากต้องการจับคู่อักขระ Unicode ในกลุ่มนิพจน์ทั่วไป คุณต้องเข้ารหัสเปอร์เซ็นต์ด้วยตนเอง เช่น
(caf%C3%A9)เพื่อให้ตรงกับcafé
นอกเหนือจากการเข้ารหัสอักขระ Unicode แล้ว URLPattern ยังดำเนินการทำให้ URL เป็นรูปแบบมาตรฐานด้วย
เช่น /foo/./bar ในคอมโพเนนต์ pathname จะ
ยุบเป็น /foo/bar ที่เทียบเท่า
หากไม่แน่ใจว่ารูปแบบอินพุตที่ระบุได้รับการแปลงเป็นรูปแบบมาตรฐานอย่างไร ให้ตรวจสอบอินสแตนซ์ URLPattern ที่สร้างขึ้นโดยใช้DevToolsของเบราว์เซอร์
นำข้อมูลทุกอย่างมารวมกัน
การสาธิต Glitch แสดงให้เห็น Use Case หลักของ URLPattern
ภายใน fetch event handler ของ Service Worker
โดยการแมปรูปแบบที่เฉพาะเจาะจงกับฟังก์ชันแบบอะซิงโครนัสที่อาจสร้างการตอบกลับคำขอเครือข่าย แนวคิดในตัวอย่างนี้สามารถนำไปใช้กับ
สถานการณ์การกำหนดเส้นทางอื่นๆ ได้เช่นกัน ไม่ว่าจะเป็นฝั่งเซิร์ฟเวอร์หรือฝั่งไคลเอ็นต์
ความคิดเห็นและแผนในอนาคต
แม้ว่าฟังก์ชันการทำงานพื้นฐานสำหรับ URLPattern จะพร้อมใช้งานใน Chrome และ Edge แล้ว
แต่เราก็วางแผนที่จะเพิ่มฟีเจอร์ต่างๆ เข้ามาด้วย URLPattern บางด้านยังอยู่ระหว่างการพัฒนา
และยังมีคำถามที่ยังไม่มีคำตอบ
เกี่ยวกับลักษณะการทำงานที่เฉพาะเจาะจงซึ่งอาจยังต้องปรับปรุง เราขอแนะนำให้คุณลองใช้
URLPatternและแสดงความคิดเห็นผ่านปัญหาใน GitHub
การรองรับการใช้เทมเพลต
path-to-regexp ไลบรารีมี
compile() function
ที่เปลี่ยนลักษณะการกำหนดเส้นทางได้อย่างมีประสิทธิภาพ compile() รับรูปแบบและค่าสำหรับตัวยึดตำแหน่งโทเค็น แล้วแสดงผลสตริงสำหรับเส้นทาง URL
ที่มีการแทนที่ค่าเหล่านั้น
เราหวังว่าจะได้ เพิ่มสิ่งนี้ลงใน URLPattern ใน อนาคต แต่ยังไม่อยู่ในขอบเขตของการเปิดตัวครั้งแรก
เปิดใช้ฟีเจอร์แพลตฟอร์มเว็บในอนาคต
หาก URLPattern กลายเป็นส่วนหนึ่งของแพลตฟอร์มเว็บแล้ว ฟีเจอร์อื่นๆ
ที่อาจได้รับประโยชน์จากการกำหนดเส้นทางหรือการจับคู่รูปแบบก็จะสามารถสร้างขึ้นบน
ฟีเจอร์นี้เป็นองค์ประกอบพื้นฐานได้
ขณะนี้มีการพูดคุยอย่างต่อเนื่องเกี่ยวกับการใช้ URLPattern สำหรับฟีเจอร์ที่เสนอ
เช่น
การจับคู่รูปแบบขอบเขตของ Service Worker
PWA เป็นตัวแฮนเดิลไฟล์
และ
การดึงข้อมูลล่วงหน้าแบบคาดการณ์
ดูรายการการรับทราบทั้งหมดได้ในเอกสารอธิบายต้นฉบับ