ข้อมูลเบื้องต้นเกี่ยวกับการแมปแหล่งที่มา JavaScript

คุณเคยคิดอยากอัปเดตโค้ดฝั่งไคลเอ็นต์ให้อ่านง่ายและแก้ไขข้อบกพร่องที่สำคัญกว่าได้หลังจากผสานรวมและลดขนาดโค้ดแล้ว โดยไม่ส่งผลต่อประสิทธิภาพ ตอนนี้คุณสามารถสัมผัสความมหัศจรรย์ของแผนที่แหล่งที่มาได้แล้ว

การแมปแหล่งที่มาเป็นวิธีการแมปไฟล์ที่รวม/ลดขนาดกลับไปยังสถานะที่ไม่ได้สร้าง เมื่อคุณสร้างแผนที่สำหรับเวอร์ชันที่ใช้งานจริง ตลอดจนการลดขนาดและการรวมไฟล์ JavaScript คุณจะสร้างแผนที่แหล่งที่มาซึ่งมีข้อมูลเกี่ยวกับไฟล์ต้นฉบับ เมื่อคุณค้นหาหมายเลขบรรทัดและหมายเลขคอลัมน์ใน JavaScript ที่สร้างขึ้น คุณจะทำการค้นหาในแผนที่แหล่งที่มาซึ่งจะแสดงตำแหน่งเดิมได้ เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ (ขณะนี้คือ WebKit รุ่น Nightly, Google Chrome หรือ Firefox 23 ขึ้นไป) สามารถแยกวิเคราะห์แผนที่แหล่งที่มาโดยอัตโนมัติและทำให้ดูเหมือนว่าคุณกำลังเรียกใช้ไฟล์ที่ยังไม่ได้ย่อและไม่ได้อยู่รวมกัน

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

ตัวอย่างไลบรารีการแมปแหล่งที่มา Mozilla JavaScript ในสถานการณ์จริง

โลกแห่งความเป็นจริง

ก่อนที่คุณจะดูการใช้งานแผนที่แหล่งที่มาในชีวิตจริงต่อไปนี้ โปรดเปิดใช้งานฟีเจอร์แผนที่แหล่งที่มาใน Chrome Canary หรือ WebKit ตอนกลางคืนโดยคลิกเฟืองการตั้งค่าในแผงเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ แล้วทำเครื่องหมายที่ "เปิดใช้แผนที่แหล่งที่มา" ตัวเลือก

วิธีเปิดใช้การแมปแหล่งที่มาในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ WebKit

Firefox 23+ ได้เปิดใช้แผนที่ที่มาโดยค่าเริ่มต้นในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ภายใน

วิธีเปิดใช้งานการแมปแหล่งที่มาในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Firefox

เหตุใดฉันจึงควรสนใจการแมปแหล่งที่มา

ตอนนี้การแมปแหล่งที่มาจะทำงานระหว่าง JavaScript ที่ไม่ได้บีบอัด/แบบรวมกับ JavaScript ที่บีบอัด/ไม่รวมกันเท่านั้น แต่อนาคตที่สดใสด้วยการพูดถึงภาษาที่คอมไพล์เป็น JavaScript เช่น CoffeeScript และแม้แต่ความเป็นไปได้ในการเพิ่มการรองรับตัวประมวลผล CSS ล่วงหน้า เช่น SASS หรือ LESS

ในอนาคต เราใช้ภาษาเกือบทุกภาษาได้โดยง่าย เสมือนว่าภาษานั้นได้รับการรองรับในเบราว์เซอร์พร้อมกับการแมปแหล่งที่มาอยู่แล้ว

  • CoffeeScript
  • ECMAScript 6 ขึ้นไป
  • SASS/LESS และอื่นๆ
  • คอมไพล์ไปยัง JavaScript ได้เกือบทุกภาษา

ดู Screencast ของ CoffeeScript ที่ได้รับการแก้ไขข้อบกพร่องในบิลด์ทดลองของคอนโซล Firefox

เมื่อเร็วๆ นี้ Google Web Toolkit (GWT) ได้เพิ่มการรองรับแผนที่แหล่งที่มา Ray Cromwell จากทีม GWT จัดทำ Screencast ที่ยอดเยี่ยม ซึ่งแสดงให้เห็นการสนับสนุนแผนที่ต้นทางในการใช้งานจริง

อีกตัวอย่างหนึ่งที่เราได้สร้างขึ้นมาใช้ไลบรารี Traceur ของ Google ซึ่งให้คุณเขียน ES6 (ECMAScript 6 หรือ Next) และคอมไพล์เป็นโค้ดที่เข้ากันได้กับ ES3 นอกจากนี้คอมไพเลอร์ Traceur ยังสร้างแผนที่แหล่งที่มาอีกด้วย ลองดูการสาธิตลักษณะและคลาส ES6 นี้เหมือนกับได้รับการรองรับในเบราว์เซอร์แบบดั้งเดิม ด้วยแผนที่แหล่งที่มา

พื้นที่ข้อความในเดโมยังช่วยให้คุณเขียน ES6 ได้ ซึ่งจะคอมไพล์ในทันที และสร้างแผนที่แหล่งที่มาพร้อมโค้ด ES3 ที่เทียบเท่า

การแก้ไขข้อบกพร่องของ Traceur ES6 โดยใช้การแมปแหล่งที่มา

การสาธิต: เขียน ES6, แก้ไขข้อบกพร่อง และดูการทำงานของการแมปแหล่งที่มา

การแมปแหล่งที่มาทำงานอย่างไร

คอมไพเลอร์/ตัวแทรก JavaScript เพียงตัวเดียวที่รองรับสำหรับการสร้างการแมปแหล่งที่มาในขณะนี้คือคอมไพเลอร์ Closure (เราจะอธิบายวิธีใช้ในภายหลัง) เมื่อคุณได้รวมและลดขนาด JavaScript แล้ว JavaScript นั้นจะมีไฟล์การแมปแหล่งที่มาอยู่

ปัจจุบัน คอมไพเลอร์ Closure ไม่ได้ใส่ข้อคิดเห็นพิเศษในตอนท้ายซึ่งจำเป็นเพื่อแสดงถึงเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของเบราว์เซอร์ที่มีแผนที่แหล่งที่มา

//# sourceMappingURL=/path/to/file.js.map

ซึ่งจะทำให้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์จับคู่การโทรกลับไปยังตำแหน่งของตนในไฟล์ต้นทางได้ ก่อนหน้านี้ เครื่องมือแสดงความคิดเห็นคือ //@ แต่เนื่องจากปัญหาบางอย่างเกี่ยวกับความคิดเห็นดังกล่าวและความคิดเห็นของ IE เกี่ยวกับการรวบรวมแบบมีเงื่อนไขทำให้มีการตัดสินใจในการเปลี่ยนเป็น //# ปัจจุบันมี Chrome Canary, WebKit Nightly และ Firefox 24 ขึ้นไปรองรับโปรแกรมแก้ไขความคิดเห็นใหม่ การเปลี่ยนแปลงไวยากรณ์นี้จะส่งผลต่อ sourceURL ด้วย

หากคุณไม่ชอบความคิดเห็นแปลกๆ คุณสามารถตั้งค่าส่วนหัวพิเศษในไฟล์ JavaScript ที่คอมไพล์ได้ โดยทำดังนี้

X-SourceMap: /path/to/file.js.map

เช่นเดียวกับความคิดเห็น วิธีนี้จะช่วยให้ผู้บริโภคแผนที่ต้นทางมองหาการแมปแหล่งที่มาที่เชื่อมโยงกับไฟล์ JavaScript ได้ที่ใด ส่วนหัวนี้ยังช่วยแก้ปัญหาการอ้างอิงแผนที่แหล่งที่มาในภาษาที่ไม่รองรับความคิดเห็นบรรทัดเดียวด้วย

ตัวอย่าง WebKit Devtools ของการแมปแหล่งที่มาในและปิดการแมปแหล่งที่มา

ระบบจะดาวน์โหลดไฟล์การแมปแหล่งที่มาก็ต่อเมื่อคุณเปิดใช้การแมปแหล่งที่มาและเปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ไว้ นอกจากนี้ คุณจะต้องอัปโหลดไฟล์ต้นฉบับเพื่อให้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์อ้างอิงและแสดงไฟล์ดังกล่าวได้เมื่อจำเป็น

ฉันจะสร้างแผนที่แหล่งที่มาได้อย่างไร

คุณจะต้องใช้คอมไพเลอร์การปิดเพื่อลดขนาด เชื่อมต่อ และสร้างการแมปแหล่งที่มาสำหรับไฟล์ JavaScript ของคุณ คำสั่งมีดังนี้

java -jar compiler.jar \
--js script.js \
--create_source_map ./script-min.js.map \
--source_map_format=V3 \
--js_output_file script-min.js

แฟล็กคำสั่งที่สำคัญ 2 แบบคือ --create_source_map และ --source_map_format ซึ่งจำเป็นเนื่องจากเวอร์ชันเริ่มต้นคือ V2 และเราต้องการใช้งานกับ V3 เท่านั้น

โครงสร้างของแผนที่แหล่งที่มา

เพื่อให้เข้าใจการแมปแหล่งที่มาได้ดียิ่งขึ้น เราจะยกตัวอย่างเล็กๆ ของไฟล์การแมปแหล่งที่มาที่คอมไพเลอร์ Closure สร้างขึ้น และเจาะลึกรายละเอียดเพิ่มเติมเกี่ยวกับวิธีที่ "การแมป" ใช้งานได้ ตัวอย่างต่อไปนี้มีความแตกต่างกันเล็กน้อยจากตัวอย่างข้อมูลจำเพาะ V3

{
    version : 3,
    file: "out.js",
    sourceRoot : "",
    sources: ["foo.js", "bar.js"],
    names: ["src", "maps", "are", "fun"],
    mappings: "AAgBC,SAAQ,CAAEA"
}

ด้านบนคุณจะเห็นว่าแผนที่แหล่งที่มาเป็นออบเจ็กต์ตามตัวอักษรที่มีข้อมูลที่ฉูดฉาดจำนวนมาก ดังนี้

  • หมายเลขเวอร์ชันที่การแมปแหล่งที่มาใช้งานอยู่
  • ชื่อไฟล์ของโค้ดที่สร้างขึ้น (ไฟล์ที่ใช้งานจริงทั้งขนาดเล็กและรวมกัน)
  • sourceRoot ทำให้คุณสามารถแทรกแหล่งที่มาไว้ด้านหน้าด้วยโครงสร้างโฟลเดอร์ ซึ่งเป็นเทคนิคการประหยัดพื้นที่ด้วย
  • แหล่งที่มาจะมีชื่อไฟล์ทั้งหมดที่รวมกัน
  • ประกอบด้วยชื่อตัวแปร/เมธอดทั้งหมดที่ปรากฏตลอดทั้งโค้ดของคุณ
  • สุดท้าย พร็อพเพอร์ตี้การแมปคือจุดที่ความมหัศจรรย์เกิดขึ้นโดยใช้ค่า Base64 VLQ การบันทึกพื้นที่จริงทำได้ที่นี่

Base64 VLQ และการทำให้แผนที่ต้นทางมีขนาดเล็ก

เริ่มแรก ข้อกำหนดของการแมปแหล่งที่มามีเอาต์พุตแบบละเอียดมากสำหรับการแมปทั้งหมด และส่งผลให้การแมปแหล่งที่มามีขนาดใหญ่กว่าโค้ดที่สร้างขึ้นประมาณ 10 เท่า เวอร์ชัน 2 ลดลงประมาณ 50% และเวอร์ชัน 3 ลดการทำงานลงอีกประมาณ 50% ดังนั้นสำหรับไฟล์ 133kB คุณจะได้รับแผนที่ต้นฉบับประมาณ 300 kB

แล้วพวกเขาลดขนาดอย่างไรในขณะที่ยังคงรักษาการแมปที่ซับซ้อนไว้ได้

VLQ (Variable Length Quantity) จะใช้ร่วมกับการเข้ารหัสค่าเป็นค่า Base64 พร็อพเพอร์ตี้การแมปเป็นสตริงขนาดใหญ่มาก ภายในสตริงนี้มีเครื่องหมายเซมิโคลอน (;) ซึ่งแสดงหมายเลขบรรทัดภายในไฟล์ที่สร้างขึ้น ภายในแต่ละบรรทัดจะมีเครื่องหมายจุลภาค (,) ซึ่งแสดงแต่ละส่วนภายในบรรทัดนั้น แต่ละกลุ่มคือ 1, 4 หรือ 5 ในช่องความยาวตัวแปร บางลิงก์อาจยาวกว่านี้ แต่จะมีบิตต่อเนื่อง แต่ละกลุ่มสร้างขึ้นจากส่วนก่อนหน้า ซึ่งช่วยลดขนาดของไฟล์เนื่องจากแต่ละบิตจะสัมพันธ์กับส่วนก่อนหน้า

รายละเอียดกลุ่มภายในไฟล์ JSON ของการแมปแหล่งที่มา

ดังที่กล่าวไว้ข้างต้น แต่ละส่วนจะมีความยาวตัวแปรได้เป็น 1, 4 หรือ 5 แผนภาพนี้ถือว่าเป็นความยาวของตัวแปร 4 ที่มีบิตต่อเนื่อง 1 บิต (g) เราจะแบ่งส่วนนี้ออกและแสดงให้คุณเห็นว่าแผนที่แหล่งที่มาทำงานอย่างไรจากตำแหน่งเดิม

ค่าที่แสดงด้านบนจะเป็นค่าที่ถอดรหัสแบบ Base64 เท่านั้น และยังมีการประมวลผลเพิ่มเติมเพื่อให้ได้ค่าจริง แต่ละส่วนมักจะประกอบด้วย 5 สิ่งดังนี้

  • คอลัมน์ที่สร้าง
  • ไฟล์ต้นฉบับที่ปรากฏนี้
  • หมายเลขบรรทัดเดิม
  • คอลัมน์เดิม
  • และชื่อเดิม (หากมี)

บางกลุ่มไม่ได้มีชื่อ ชื่อเมธอด หรืออาร์กิวเมนต์ ดังนั้นกลุ่มทั้งหมดจะสลับระหว่างความยาวตัวแปร 4-5 รายการ ค่า g ในแผนภาพกลุ่มด้านบนคือสิ่งที่เรียกว่าดอกสว่านต่อเนื่องจากช่วยให้เพิ่มประสิทธิภาพได้มากขึ้นในขั้นตอนถอดรหัส Base64 VLQ บิตต่อเนื่องช่วยให้คุณสร้างค่ากลุ่มได้เพื่อให้จัดเก็บตัวเลขจำนวนมากได้โดยไม่ต้องเก็บตัวเลขจำนวนมาก ซึ่งเป็นเทคนิคการประหยัดพื้นที่ที่ชาญฉลาดซึ่งมีรากอยู่ในรูปแบบ MIDI

เมื่อแผนภาพด้านบน AAgBC ประมวลผลเพิ่มเติม จะแสดงผล 0, 0, 32, 16, 1 โดย 32 เป็นบิตต่อที่ช่วยสร้างค่าต่อไปนี้เป็น 16 B ที่ถอดรหัสเท่านั้นใน Base64 คือ 1 ดังนั้นค่าสําคัญที่ใช้คือ 0, 0, 16, 1 ซึ่งทำให้เราทราบว่าบรรทัดที่ 1 (ระบบจะนับบรรทัดตามเครื่องหมายเซมิโคลอน) คอลัมน์ 0 ของไฟล์ที่สร้างขึ้นจะจับคู่กับไฟล์ 0 (อาร์เรย์ของไฟล์ 0 คือ foo.js) บรรทัดที่ 16 ที่คอลัมน์ 1

ฉันจะอ้างอิงไลบรารี JavaScript การแมปแหล่งที่มาของ Mozilla เพื่อแสดงให้เห็นว่ากลุ่มได้รับการถอดรหัสอย่างไร คุณอาจดูโค้ดการแมปแหล่งที่มาของ WebKit สำหรับเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ที่เขียนด้วย JavaScript

เพื่อให้เข้าใจถึงวิธีที่เราได้ค่า 16 จาก B ได้อย่างถูกต้อง เราต้องมีความเข้าใจขั้นพื้นฐานเกี่ยวกับโอเปอเรเตอร์บิตไวส์และวิธีการทำงานของข้อมูลจำเพาะสำหรับการแมปแหล่งที่มา ตัวเลข g ที่อยู่นำหน้าจะเป็นบิตต่อเนื่องโดยการเปรียบเทียบตัวเลข (32) กับ VLQ_CONTINUATION_BIT (ไบนารี 100000 หรือ 32) โดยใช้โอเปอเรเตอร์บิตไวส์ AND (&)

32 & 32 = 32
// or
100000
|
|
V
100000

ซึ่งจะแสดง 1 ในแต่ละตำแหน่งบิตที่ทั้ง 2 ตำแหน่งปรากฏ ดังนั้น ค่าที่ถอดรหัสของ Base64 ของ 33 & 32 จะแสดงผลเป็น 32 เนื่องจากจะแชร์ตำแหน่งแบบ 32 บิตเท่านั้นตามที่คุณเห็นในแผนภาพด้านบน จากนั้นจะเพิ่มค่า Shift ของบิตขึ้น 5 สำหรับบิตต่อเนื่องก่อนหน้าแต่ละบิต ในกรณีข้างต้น มีการขยับเพียง 5 ครั้ง ดังนั้นเลื่อนไปทางซ้าย 1 (B) ด้วย 5

1 <<../ 5 // 32

// Shift the bit by 5 spots
______
|    |
V    V
100001 = 100000 = 32

ระบบจะแปลงค่าดังกล่าวจากค่าที่มีการลงชื่อของ VLQ โดยเลื่อนตัวเลข (32) ไปทางขวา 1 จุด

32 >> 1 // 16
//or
100000
|
 |
 V
010000 = 16

เพียงเท่านี้คุณก็พร้อมแปลงเลข 1 เป็น 16 แล้ว กระบวนการนี้อาจดูซับซ้อนกว่าปกติ แต่หากเริ่มมีจำนวนมากขึ้น ก็น่าจะเหมาะสมกว่า

ปัญหา XSSI ที่อาจเกิดขึ้น

ข้อกำหนดกล่าวถึงปัญหาการรวมสคริปต์ข้ามไซต์ที่อาจเกิดขึ้นจากการใช้งานการแมปแหล่งที่มา เพื่อลดปัญหานี้ เราขอแนะนำให้คุณใส่ ")]}" ไว้หน้าบรรทัดแรกของการแมปแหล่งที่มา เพื่อจงใจทำให้ JavaScript ใช้งานไม่ได้ จึงจะเกิดข้อผิดพลาดทางไวยากรณ์ ซึ่งเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ WebKit ช่วยจัดการเรื่องนี้ได้

if (response.slice(0, 3) === ")]}") {
    response = response.substring(response.indexOf('\n'));
}

ดังที่แสดงด้านบน อักขระ 3 ตัวแรกจะถูกแบ่งเป็นส่วนๆ เพื่อตรวจสอบว่าตรงกับข้อผิดพลาดทางไวยากรณ์ในข้อกำหนดหรือไม่ และหากเป็นเช่นนั้น ให้นำอักขระทั้งหมดที่ขึ้นต้นเอนทิตีบรรทัดแรกใหม่ออก (\n)

การใช้งาน sourceURL และ displayName: ฟังก์ชัน Eval และที่ไม่ระบุตัวตน

แม้ว่ากฎ 2 แบบต่อไปนี้จะไม่ได้เป็นส่วนหนึ่งของข้อกำหนดของแผนที่แหล่งที่มา แต่จะช่วยให้คุณพัฒนาได้ง่ายขึ้นมากเมื่อทำงานกับ Eval และฟังก์ชันที่ไม่ระบุตัวตน

ตัวช่วยแรกดูคล้ายกับพร็อพเพอร์ตี้ //# sourceMappingURL มากและจริงๆ แล้วมีการกล่าวถึงในข้อกำหนดของการแมปแหล่งที่มา V3 คุณตั้งชื่อการประเมินเพื่อให้ปรากฏเป็นชื่อเชิงตรรกะมากขึ้นในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ ด้วยการใส่ความคิดเห็นพิเศษต่อไปนี้ในโค้ดของคุณ ดูการสาธิตง่ายๆ ที่ใช้คอมไพเลอร์ CoffeeScript:

การสาธิต: ดูการแสดงโค้ดของ eval() เป็นสคริปต์ผ่าน sourceURL

//# sourceURL=sqrt.coffee
ความคิดเห็นพิเศษของ sourceURL มีลักษณะอย่างไรในเครื่องมือสำหรับนักพัฒนา

ผู้ช่วยอีกตัวช่วยให้คุณตั้งชื่อฟังก์ชันที่ไม่ระบุชื่อโดยใช้พร็อพเพอร์ตี้ displayName ที่มีอยู่ในบริบทปัจจุบันของฟังก์ชันที่ไม่ระบุตัวตน สร้างโปรไฟล์การสาธิตต่อไปนี้เพื่อดูการทำงานของพร็อพเพอร์ตี้ displayName

btns[0].addEventListener("click", function(e) {
    var fn = function() {
        console.log("You clicked button number: 1");
    };

    fn.displayName = "Anonymous function of button 1";

    return fn();
}, false);
แสดงการทำงานของพร็อพเพอร์ตี้ displayName

เมื่อทำการสร้างโปรไฟล์โค้ดภายในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ พร็อพเพอร์ตี้ displayName จะแสดงขึ้นแทนที่จะเป็นรูปแบบ (anonymous) อย่างไรก็ตาม displayName นั้นจมอยู่ในน้ำแล้ว และจะไม่มีการนำเข้ามาไว้ใน Chrome แต่ความหวังก็ไม่ได้หายไป และมีการเสนอข้อเสนอที่ดีกว่าเดิมมากว่า debugName

เมื่อเขียนชื่อการประเมินแล้วจะใช้ได้กับเบราว์เซอร์ Firefox และ WebKit เท่านั้น พร็อพเพอร์ตี้ displayName มีอยู่ใน WebKit เท่านั้น

มารวมตัวกัน

ขณะนี้มีการพูดคุยกันอย่างยาวมากเกี่ยวกับการสนับสนุนแผนที่ต้นทางที่เพิ่มลงใน CoffeeScript ตรวจสอบปัญหาและเพิ่มการสนับสนุนสำหรับการเพิ่มการสร้างแผนที่ต้นทางลงในคอมไพเลอร์ CoffeeScript นี่จะเป็นความสำเร็จครั้งใหญ่สำหรับ CoffeeScript และผู้ติดตามที่อุทิศตน

UglifyJS ยังมีปัญหาเกี่ยวกับแผนที่ต้นทางที่คุณควรตรวจสอบด้วยเช่นกัน

เครื่องมือจำนวนมากสำหรับสร้างแผนที่แหล่งที่มา รวมถึงคอมไพเลอร์ Coffeescript ฉันถือว่านี่เป็นประเด็นหลักตอนนี้

ยิ่งเรามีเครื่องมือที่สามารถสร้างการแมปแหล่งที่มาได้มากเท่าไร เราก็จะยิ่งทำได้ดียิ่งขึ้นเท่านั้น ดังนั้น ถามหรือเพิ่มการสนับสนุนแผนที่แหล่งที่มาให้กับโปรเจ็กต์โอเพนซอร์สที่คุณชื่นชอบ

ยังไม่สมบูรณ์แบบ

สิ่งหนึ่งที่การแมปแหล่งที่มาใช้ไม่ได้กับตอนนี้คือการแสดงนิพจน์การดู ปัญหาคือการพยายามตรวจสอบชื่ออาร์กิวเมนต์หรือชื่อตัวแปรภายในบริบทการดำเนินการปัจจุบันจะไม่แสดงผลลัพธ์เนื่องจากไม่มีอยู่จริง ซึ่งจำเป็นต้องใช้การแมปแบบย้อนกลับเพื่อค้นหาชื่อจริงของอาร์กิวเมนต์/ตัวแปรที่คุณต้องการตรวจสอบ เมื่อเทียบกับชื่ออาร์กิวเมนต์/ตัวแปรจริงใน JavaScript ที่คอมไพล์

แน่นอนว่านี่เป็นปัญหาที่แก้ไขได้และเมื่อมีความสนใจมากขึ้นเกี่ยวกับการแมปแหล่งที่มา เราเริ่มเห็นคุณลักษณะที่น่าทึ่งบางอย่างและมีความเสถียรที่ดีขึ้น

ปัญหา

เมื่อเร็วๆ นี้ jQuery 1.9 ได้เพิ่มการรองรับการแมปแหล่งที่มาเมื่อแสดงผลนอก CDN อย่างเป็นทางการ และยังชี้ข้อบกพร่องที่แปลกไปเมื่อมีการใช้ความคิดเห็นคอมไพล์แบบมีเงื่อนไขของ IE (//@cc_on) ก่อนโหลด jQuery อีกด้วย ต่อมาได้มีการคอมมิตเพื่อลดปัญหานี้โดยการรวม sourceMappingURL ไว้ในความคิดเห็นแบบหลายบรรทัด บทเรียนที่ควรศึกษาไม่ใช้ความคิดเห็นแบบมีเงื่อนไข

จากนี้ได้รับการแก้ไขแล้วโดยเปลี่ยนไวยากรณ์เป็น //#

เครื่องมือและแหล่งข้อมูล

แหล่งข้อมูลและเครื่องมือเพิ่มเติมที่คุณควรพิจารณามีดังนี้

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

อย่ามัวรอช้า เริ่มสร้างแผนที่แหล่งที่มาสำหรับทุกโปรเจ็กต์เลย