เคยไหมที่คุณอยากให้คุณทำให้โค้ดฝั่งไคลเอ็นต์อ่านได้และแก้ไขข้อบกพร่องที่สำคัญกว่า แม้จะรวมและลดขนาดลงแล้วก็ตามโดยไม่ส่งผลกระทบต่อประสิทธิภาพ ตอนนี้คุณสามารถผ่านความมหัศจรรย์ของแผนที่แหล่งที่มาได้แล้ว
การแมปแหล่งที่มาคือวิธีแมปไฟล์แบบรวม/แบบย่อกลับไปเป็นสถานะที่ยังไม่ได้สร้าง เมื่อคุณสร้างสำหรับเวอร์ชันที่ใช้งานจริง รวมถึงการลดขนาดและรวมไฟล์ JavaScript คุณจะสร้างแผนที่แหล่งที่มาซึ่งมีข้อมูลเกี่ยวกับไฟล์ต้นฉบับของคุณ เมื่อคุณค้นหาหมายเลขบรรทัดและคอลัมน์ใน JavaScript ที่สร้างขึ้น คุณสามารถทำการค้นหาในแผนที่แหล่งที่มาซึ่งแสดงตำแหน่งเดิมได้ เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ (ในขณะนี้คือ WebKit Nightly เวอร์ชัน, Google Chrome หรือ Firefox 23 ขึ้นไป) สามารถแยกวิเคราะห์แผนที่แหล่งที่มาโดยอัตโนมัติและทำให้ดูเหมือนว่าคุณกำลังเรียกใช้ไฟล์ที่ไม่มีการบีบอัดและไม่ได้รวมเข้าด้วยกัน
การสาธิตจะให้คุณคลิกขวาที่ใดก็ได้ในพื้นที่ข้อความที่มีแหล่งที่มาที่สร้างขึ้น เลือก "รับตำแหน่งเดิม" จะค้นหาการแมปแหล่งที่มาโดยการส่งผ่านในบรรทัดและหมายเลขคอลัมน์ที่สร้างขึ้น แล้วส่งกลับตำแหน่งในโค้ดเดิม ตรวจสอบว่าคอนโซลเปิดอยู่เพื่อให้เห็นผลลัพธ์
โลกแห่งความเป็นจริง
ก่อนที่คุณจะดูการใช้งานแผนที่แหล่งที่มาในการใช้งานจริงต่อไปนี้ โปรดตรวจสอบว่าคุณได้เปิดใช้งานคุณลักษณะแผนที่แหล่งที่มาใน Chrome Canary หรือ WebKit ทุกคืนโดยคลิกเฟืองการตั้งค่าในแผงเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ และเลือกตัวเลือก "เปิดใช้แผนที่แหล่งที่มา"
Firefox 23+ มีแผนที่ต้นฉบับที่เปิดใช้งานโดยค่าเริ่มต้นในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ในตัว
เหตุใดฉันจึงควรสนใจการแมปแหล่งที่มา
ขณะนี้การแมปแหล่งที่มาจะทำงานได้ระหว่าง 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 ที่เทียบเท่ากัน
การสาธิต: เขียน ES6, แก้ไขข้อบกพร่อง, ดูการแมปแหล่งที่มาในการใช้งานจริง
การแมปแหล่งที่มาทำงานอย่างไร
คอมไพเลอร์/ตัวจำกัด JavaScript เพียงตัวเดียวที่มีการสนับสนุนสำหรับการสร้างแผนที่แหล่งที่มาคือคอมไพเลอร์ Closure (ฉันจะอธิบายวิธีการใช้งานในภายหลัง) เมื่อคุณได้รวมและลดขนาด JavaScript แล้ว ไฟล์การแมปแหล่งที่มาจะมีไฟล์การแมปแหล่งที่มาอยู่
ปัจจุบันคอมไพเลอร์ Closure ไม่ได้เพิ่มความคิดเห็นพิเศษในตอนท้ายที่จำเป็น เพื่อแสดงถึงเครื่องมือสำหรับนักพัฒนาเบราว์เซอร์ที่มีการแมปแหล่งที่มาให้ใช้งาน
//# sourceMappingURL=/path/to/file.js.map
ซึ่งทำให้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์แมปการเรียกกลับไปยังตำแหน่งของตนในไฟล์ต้นฉบับต้นฉบับได้ ก่อนหน้านี้ Pragma สำหรับความคิดเห็นคือ //@
แต่เนื่องจากปัญหาบางอย่างเกี่ยวกับเรื่องนี้และการรวบรวมความคิดเห็นแบบมีเงื่อนไขของ IE จึงได้ตัดสินใจให้เปลี่ยนเป็น //#
ปัจจุบัน Chrome Canary, WebKit Nightly และ Firefox 24+ รองรับการทำงานของความคิดเห็นแบบใหม่ การเปลี่ยนแปลงไวยากรณ์นี้ยังมีผลกับ sourceURL ด้วย
หากไม่ชอบความคิดเห็นแปลกๆ นี้ คุณสามารถเลือกกำหนดส่วนหัวพิเศษในไฟล์ JavaScript ที่คอมไพล์ได้ โดยทำดังนี้
X-SourceMap: /path/to/file.js.map
เช่นเดียวกับความคิดเห็น ข้อมูลนี้จะเป็นตัวบอกให้ผู้บริโภคการแมปแหล่งที่มาทราบว่าจะค้นหาการแมปแหล่งที่มาที่เชื่อมโยงกับไฟล์ JavaScript ได้จากที่ใด ส่วนหัวนี้ยังช่วยแก้ปัญหาการอ้างอิงการแมปแหล่งที่มาในภาษาที่ไม่รองรับความคิดเห็นบรรทัดเดียวได้อีกด้วย
ระบบจะดาวน์โหลดไฟล์แผนที่ต้นฉบับต่อเมื่อคุณเปิดใช้แผนที่แหล่งที่มาและเปิดเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ไว้ นอกจากนี้คุณจะต้องอัปโหลดไฟล์ต้นฉบับเพื่อให้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์อ้างอิงและแสดงไฟล์ดังกล่าวได้เมื่อจำเป็น
ฉันจะสร้างการแมปแหล่งที่มาได้อย่างไร
คุณจะต้องใช้คอมไพเลอร์การปิดเพื่อลดขนาด เชื่อมต่อ และสร้างการแมปแหล่งที่มาสำหรับไฟล์ 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
ซึ่งจำเป็นเนื่องจากเวอร์ชันเริ่มต้นคือเวอร์ชัน 2 และเราต้องการใช้เวอร์ชัน 3 เท่านั้น
โครงสร้างของการแมปแหล่งที่มา
เพื่อให้เข้าใจการแมปแหล่งที่มามากขึ้น เราจะยกตัวอย่างเล็กๆ ของไฟล์แผนที่แหล่งที่มาที่คอมไพเลอร์ 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% ดังนั้นสำหรับไฟล์ขนาด 133 KB คุณจะได้รับการแมปแหล่งที่มาขนาดประมาณ 300 KB
พวกเขาลดขนาดในขณะที่ยังคงรักษาการแมปที่ซับซ้อนได้อย่างไร
ระบบจะใช้ VLQ (จำนวนตัวแปรความยาว) พร้อมกับการเข้ารหัสค่าเป็นค่า Base64 พร็อพเพอร์ตี้การแมปเป็นสตริงขนาดใหญ่มาก สตริงนี้มีเครื่องหมายเซมิโคลอน (;) ที่แสดงหมายเลขบรรทัดภายในไฟล์ที่สร้างขึ้น แต่ละบรรทัดจะมีเครื่องหมายจุลภาค (,) ที่ใช้แทนแต่ละเซกเมนต์ภายในบรรทัดนั้นๆ แต่ละกลุ่มเหล่านี้เป็น 1, 4 หรือ 5 ในฟิลด์ที่มีความยาวแปรผันได้ URL บางรายการอาจปรากฏยาวกว่านี้ แต่ยังมีบิตความต่อเนื่อง แต่ละส่วนสร้างขึ้นจากส่วนก่อนหน้า ซึ่งช่วยลดขนาดไฟล์เนื่องจากแต่ละบิตสัมพันธ์กับส่วนก่อนหน้า
ดังที่กล่าวไว้ข้างต้น แต่ละกลุ่มสามารถมีความยาวแปรผันได้ 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) ไปทางขวาหนึ่งจุด
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 ข้อต่อไปนี้จะช่วยให้คุณทำให้การพัฒนาง่ายขึ้นมากเมื่อใช้กับฟังก์ชัน EV และไม่ระบุตัวตน
ผู้ช่วยคนแรกดูคล้ายกับพร็อพเพอร์ตี้ //# sourceMappingURL
มากและมีการกล่าวถึงในข้อกำหนดของแผนที่แหล่งที่มา V3 การใส่ความคิดเห็นพิเศษต่อไปนี้ในโค้ดของคุณ ซึ่งจะถูก การประเมิน คุณสามารถตั้งชื่อ evael ให้ปรากฏเป็นชื่อที่สมเหตุสมผลในเครื่องมือการพัฒนาของคุณ ดูตัวอย่างง่ายๆ โดยใช้คอมไพเลอร์ CoffeeScript:
สาธิต: ดูโค้ดของ eval()
ที่แสดงเป็นสคริปต์ผ่าน URL ที่มา
//# sourceURL=sqrt.coffee
ผู้ช่วยอีกตัวหนึ่งจะให้คุณตั้งชื่อฟังก์ชันที่ไม่ระบุตัวตนโดยใช้พร็อพเพอร์ตี้ 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
จะแสดงขึ้นแทนรายการอย่างเช่น (anonymous)
แต่ displayName ค่อนข้างตายในน้ำและจะไม่อยู่ใน Chrome แต่ความหวังทั้งหมดไม่ได้หายไป เราแนะนำข้อเสนอที่ดีกว่าเดิมให้คุณที่ชื่อว่า debugName
ขณะที่เขียนการตั้งชื่อ eval จะใช้ได้เฉพาะในเบราว์เซอร์ Firefox และ WebKit เท่านั้น พร็อพเพอร์ตี้ displayName
อยู่ใน WebKit ต่อคืนเท่านั้น
มารวมตัวกัน
ขณะนี้มีการพูดคุยที่ใช้เวลานานมากเกี่ยวกับการสนับสนุนการแมปแหล่งที่มาซึ่งเพิ่มลงใน CoffeeScript ตรวจสอบปัญหานี้และเพิ่มการสนับสนุนของคุณสำหรับการสร้างการแมปแหล่งที่มาลงในคอมไพเลอร์ CoffeeScript นี่จะเป็นชัยชนะครั้งใหญ่สำหรับ CoffeeScript และผู้ติดตามที่ทุ่มเท
UglifyJS ยังมีปัญหาการแมปแหล่งที่มาที่คุณควรตรวจสอบด้วยเช่นกัน
มีtoolsจำนวนมากที่ใช้สร้างแผนที่ต้นฉบับ รวมถึงคอมไพเลอร์ Coffeescript ผมถือว่านี่เป็นประเด็นหลักในขณะนี้
ยิ่งเรามีเครื่องมือที่สามารถสร้างแผนที่แหล่งที่มาได้มากเท่าไร เราก็จะยิ่งเก่งขึ้นมากเท่านั้น ขอให้คุณถามหรือเพิ่มการสนับสนุนแผนที่แหล่งที่มาให้กับโครงการโอเพนซอร์สที่คุณชื่นชอบ
ยังไม่สมบูรณ์แบบ
สิ่งหนึ่งที่แผนที่แหล่งที่มายังใช้งานไม่ได้ในตอนนี้คือนิพจน์การดู ปัญหาคือการพยายามตรวจสอบอาร์กิวเมนต์หรือชื่อตัวแปรภายในบริบทการดำเนินการปัจจุบัน ผลลัพธ์ที่ได้จะไม่มีอยู่จริง ซึ่งจำเป็นต้องใช้การแมปแบบย้อนกลับบางอย่างเพื่อค้นหาชื่อจริงของอาร์กิวเมนต์/ตัวแปรที่คุณต้องการตรวจสอบ โดยเทียบกับชื่ออาร์กิวเมนต์/ตัวแปรจริงใน JavaScript ที่คอมไพล์ของคุณ
แน่นอนว่านี่เป็นปัญหาที่สามารถแก้ไขได้ และเมื่อให้ความสนใจกับแผนที่แหล่งที่มามากขึ้น เราก็จะเริ่มเห็นคุณลักษณะที่น่าทึ่งบางอย่างและความเสถียรที่ดีขึ้น
ปัญหา
เมื่อเร็วๆ นี้ jQuery 1.9 ได้เพิ่มการรองรับแผนที่แหล่งที่มาเมื่อแสดงผลนอก CDN อย่างเป็นทางการ และยังชี้ให้เห็นข้อบกพร่องที่ผิดปกติเมื่อมีการใช้ความคิดเห็นการคอมไพล์แบบมีเงื่อนไขของ IE (//@cc_on) ก่อนโหลด jQuery ด้วย นับแต่นั้นมาได้มีการคอมมิตเพื่อลดปัญหานี้โดยการรวม sourceMappingURL ไว้ในความคิดเห็นแบบหลายบรรทัด บทเรียนที่ต้องเรียนรู้ไม่ใช้ความคิดเห็นแบบมีเงื่อนไข
ซึ่งได้รับการแก้ไขแล้วโดยเปลี่ยนไวยากรณ์เป็น //#
แล้ว
เครื่องมือและแหล่งข้อมูล
ต่อไปนี้เป็นแหล่งข้อมูลและเครื่องมือเพิ่มเติมที่คุณควรลองใช้
- Nick Fitzgerald มีส้อม UglifyJS พร้อมการรองรับการแมปแหล่งที่มา
- Paul Ireland มีการสาธิตเล็กๆ น้อยๆ ที่มีประโยชน์ซึ่งแสดงแผนที่แหล่งที่มา
- ลองดูชุดเปลี่ยน WebKit เพื่อดูว่าเมื่อใดที่ลดลง
- ชุดการเปลี่ยนแปลงยังมีการทดสอบเลย์เอาต์ซึ่งเป็นการเริ่มต้นของบทความทั้งหมด
- Mozilla มีข้อบกพร่องที่คุณควรปฏิบัติตามเกี่ยวกับสถานะของแผนที่แหล่งที่มาในคอนโซลในตัว
- Conrad Irwin ได้เขียนแหล่งข้อมูลแผนที่แหล่งที่มาที่มีประโยชน์อย่างยิ่งสำหรับผู้ใช้ Ruby ทุกคน
- อ่านเพิ่มเติมเกี่ยวกับการตั้งชื่อการประเมินและพร็อพเพอร์ตี้ displayName
- คุณดูแหล่งที่มาของคอมไพเลอร์การปิดเพื่อสร้างการแมปแหล่งที่มาได้
- มีภาพหน้าจอและการพูดคุยเกี่ยวกับการรองรับแผนที่แหล่งที่มาของ GWT
แผนที่แหล่งที่มาเป็นยูทิลิตีที่ทรงประสิทธิภาพมากในชุดเครื่องมือของนักพัฒนา การทำให้เว็บแอปมีขนาดเล็กแต่แก้ไขข้อบกพร่องได้ง่ายจะเป็นประโยชน์อย่างยิ่ง และยังเป็นเครื่องมือการเรียนรู้ที่มีประสิทธิภาพมากสำหรับนักพัฒนาซอฟต์แวร์รุ่นใหม่ คุณจะได้เห็นว่านักพัฒนาซอฟต์แวร์ที่มีประสบการณ์วางโครงสร้างอย่างไร และเขียนแอปได้โดยไม่ต้องลุยกับโค้ดที่ลดขนาดที่อ่านไม่ได้
อย่ามัวรอช้า เริ่มสร้างการแมปแหล่งที่มาสำหรับทุกโปรเจ็กต์เลย