บทนำ
ในปัจจุบัน ผู้เขียนสามารถใช้นามธรรมจำนวนมากในการสร้างเว็บแอปพลิเคชันของตน ผู้เขียนจำนวนมากใช้ประโยชน์จากเฟรมเวิร์ก สร้างเครื่องมือและคอมไพเลอร์เพื่อเขียนแอปพลิเคชันของตนจากมุมมองระดับสูงขึ้น แทนที่จะติดต่อโดยตรงด้วย API ระดับล่างที่แพลตฟอร์มเว็บมีให้
ตัวอย่างเช่น คอมโพเนนต์ที่สร้างขึ้นในเฟรมเวิร์ก Angular เขียนขึ้นใน TypeScript โดยใช้เทมเพลต HTML เบื้องหลังการทำงาน Angular CLI และ Webpack จะรวบรวมทุกอย่างลงใน JavaScript และกลายเป็นแพ็กเกจที่เรียกกันว่า ซึ่งจากนั้นจะถูกจัดส่งไปยังเบราว์เซอร์
เมื่อแก้ไขข้อบกพร่องหรือสร้างโปรไฟล์เว็บแอปพลิเคชันในเครื่องมือสำหรับนักพัฒนาเว็บ คุณจะเห็นและแก้ไขข้อบกพร่องของโค้ดเวอร์ชันที่คอมไพล์นี้แทนโค้ดที่คุณเขียนไว้จริงๆ อย่างไรก็ตาม ในฐานะผู้เขียน คุณคงไม่อยากให้คุณมีลักษณะดังนี้
- หากไม่ต้องการแก้ไขข้อบกพร่องของโค้ด JavaScript ที่ลดขนาดลงและต้องการแก้ไขข้อบกพร่องของโค้ด JavaScript ต้นฉบับ
- เมื่อใช้ TypeScript คุณจะไม่ต้องการดีบัก JavaScript และต้องการดีบักโค้ด TypeScript ต้นฉบับของคุณ
- เมื่อคุณใช้การจัดเทมเพลต เช่น Angular, Lit หรือ JSX คุณไม่ต้องการแก้ไขข้อบกพร่องของ DOM ที่ได้ คุณอาจต้องแก้ไขข้อบกพร่องของคอมโพเนนต์เอง
โดยรวมแล้ว คุณอาจต้องการแก้ไขข้อบกพร่องของโค้ดของคุณเองตามที่เขียนไว้
แม้ว่าการแมปแหล่งที่มาปิดช่องว่างนี้ไปแล้วบ้าง แต่ Chrome DevTools และระบบนิเวศจะทำประโยชน์ในส่วนนี้ได้มากขึ้น
เรามาดูรายละเอียดกัน
โค้ดที่เขียนแล้วกับที่ทำให้ใช้งานได้แล้ว
ปัจจุบันเมื่อไปยังโครงสร้างไฟล์ในแผงแหล่งที่มา คุณจะเห็นเนื้อหาของไฟล์ที่คอมไพล์และมักลดขนาดลง ไฟล์เหล่านี้เป็นไฟล์จริงที่เบราว์เซอร์ดาวน์โหลดและเรียกใช้ เครื่องมือสำหรับนักพัฒนาเว็บเรียกสิ่งนี้ว่าโค้ดที่ทำให้ใช้งานได้
วิธีนี้ไม่ค่อยเป็นประโยชน์และมักทำความเข้าใจได้ยาก ในฐานะผู้เขียน คุณต้องการดูและแก้ไขข้อบกพร่องของโค้ดที่เขียนไว้ ไม่ใช่โค้ดที่ทำให้ใช้งานได้
และเพื่อเป็นการชดเชยด้วยได้แล้ว ตอนนี้คุณสามารถให้แผนผังแสดงโค้ดที่เขียนขึ้นแทน ซึ่งจะทำให้โครงสร้างคล้ายกับไฟล์ต้นฉบับที่คุณเห็นใน IDE มากขึ้น และขณะนี้ไฟล์เหล่านี้จะถูกแยกออกจากโค้ดที่ทำให้ใช้งานได้
หากต้องการเปิดใช้ตัวเลือกนี้ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ให้ไปที่การตั้งค่า > การทดสอบ และตรวจสอบจัดกลุ่มแหล่งที่มาเป็นแผนผังที่สร้างขึ้นและทำให้ใช้งานได้แล้ว
"เฉพาะรหัสของฉัน"
เมื่อใช้ทรัพยากร Dependency หรือต่อยอดจากเฟรมเวิร์ก ไฟล์ของบุคคลที่สามก็เข้ามาแทรกให้คุณได้ ส่วนใหญ่คุณแค่ต้องการเห็นเพียงโค้ดเท่านั้น ไม่ใช่ไลบรารีของบุคคลที่สามที่ซ่อนอยู่ในโฟลเดอร์ node_modules
เครื่องมือสำหรับนักพัฒนาเว็บได้เปิดใช้การตั้งค่าเพิ่มเติมโดยค่าเริ่มต้น ได้แก่ เพิ่มสคริปต์ของบุคคลที่สามที่รู้จักลงในรายการละเว้นโดยอัตโนมัติ คุณจะพบเครื่องมือนี้ได้ในDevTools > การตั้งค่า > รายชื่อที่ไม่สนใจ
เมื่อเปิดใช้การตั้งค่านี้ เครื่องมือสำหรับนักพัฒนาเว็บจะซ่อนไฟล์หรือโฟลเดอร์ที่เฟรมเวิร์กหรือเครื่องมือสร้างไว้ทำเครื่องหมายเป็นไม่สนใจ
ใน Angular v14.1.0 เนื้อหาของโฟลเดอร์ node_modules และ webpack จะถูกทำเครื่องหมายไว้เช่นนั้น ดังนั้นโฟลเดอร์เหล่านี้ ไฟล์ในโฟลเดอร์ และอาร์ติแฟกต์อื่นๆ ของบุคคลที่สามดังกล่าวจะไม่แสดงในที่ต่างๆ ในเครื่องมือสำหรับนักพัฒนาเว็บ
ในฐานะผู้เขียน คุณไม่จำเป็นต้องดำเนินการใดๆ เพื่อเปิดใช้ลักษณะการทำงานใหม่นี้ การเปลี่ยนแปลงนี้ขึ้นอยู่กับเฟรมเวิร์ก
โค้ดในรายการที่ละเว้นในสแต็กเทรซ
ไฟล์ที่อยู่ในรายการละเว้นเหล่านี้จะไม่ปรากฏขึ้นมาอีกที่หนึ่งในสแต็กเทรซ ในฐานะผู้เขียน ตอนนี้คุณจะได้ดูสแต็กเทรซที่เกี่ยวข้องมากขึ้น
หากต้องการดูเฟรมการเรียกใช้ทั้งหมดของสแต็กเทรซ คุณก็คลิกลิงก์แสดงเฟรมเพิ่มเติมได้ทุกเมื่อ
เช่นเดียวกันกับสแต็กการเรียกใช้ที่คุณเห็นขณะแก้ไขข้อบกพร่องและเข้าสู่โค้ด เมื่อเฟรมเวิร์กหรือ Bundler แจ้งให้เครื่องมือสำหรับนักพัฒนาเว็บทราบเกี่ยวกับสคริปต์ของบุคคลที่สาม เครื่องมือสำหรับนักพัฒนาเว็บจะซ่อนเฟรมการโทรที่ไม่เกี่ยวข้องทั้งหมดและข้ามโค้ดที่อยู่ในรายการละเว้นทั้งหมดโดยอัตโนมัติขณะแก้ไขข้อบกพร่องในขั้นตอนการแก้ปัญหา
โค้ดที่อยู่ในรายการละเว้นในโครงสร้างไฟล์
หากต้องการซ่อนไฟล์และโฟลเดอร์ที่อยู่ในรายการละเว้นจากโครงสร้างไฟล์โค้ดที่เขียนในแผงแหล่งที่มา ให้เลือกซ่อนโค้ดที่อยู่ในรายการที่ละเว้นในมุมมองแบบต้นไม้ของแหล่งที่มาในการตั้งค่า > การทดสอบในเครื่องมือสำหรับนักพัฒนาเว็บ
ตอนนี้ระบบจะซ่อนโฟลเดอร์ node_modules และ webpack ในโปรเจ็กต์ Angular ตัวอย่าง
รหัสในรายการที่ละเว้นในเมนู "การเปิดด่วน"
โค้ดในรายการที่ละเว้นไม่เพียงแต่จะซ่อนจากแผนผังไฟล์ แต่จะซ่อนจากเมนู "Quick Open" (Control+P (Linux/Windows) หรือ Command+P (Mac))
การปรับปรุงสแต็กเทรซเพิ่มเติม
หลังจากกล่าวถึงสแต็กเทรซที่เกี่ยวข้องแล้ว Chrome DevTools ยังเพิ่มการปรับปรุงเพิ่มเติมให้กับสแต็กเทรซ
สแต็กเทรซที่ลิงก์
เมื่อกำหนดเวลาการดำเนินการบางอย่างให้เกิดขึ้นแบบไม่พร้อมกัน สแต็กเทรซในเครื่องมือสำหรับนักพัฒนาเว็บจะเล่าเรื่องราวเพียงบางส่วนเท่านั้น
ลองดูตัวอย่างการจัดตารางเวลาแบบง่ายๆ ในไฟล์ framework.js สมมติต่อไปนี้
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
tasks.push({ f });
},
work() {
while (tasks.length) {
const { f } = tasks.shift();
f();
}
},
};
}
const scheduler = makeScheduler();
function loop() {
scheduler.work();
requestAnimationFrame(loop);
};
loop();
... และวิธีที่นักพัฒนาซอฟต์แวร์อาจใช้ในโค้ดของตนเองในไฟล์ example.js
function someTask() {
console.trace("done!");
}
function businessLogic() {
scheduler.schedule(someTask);
}
businessLogic();
เมื่อเพิ่มเบรกพอยท์ภายในเมธอด someTask หรือเมื่อตรวจสอบการติดตามที่พิมพ์ในคอนโซล คุณจะไม่เห็นการกล่าวถึงการเรียก businessLogic() ที่เป็น "สาเหตุหลัก" ของการดำเนินการนี้
แต่คุณจะเห็นเฉพาะตรรกะการกำหนดเวลาของเฟรมเวิร์กที่นำไปสู่การดำเนินการงานและไม่มีเบรดครัมบ์ในสแต็กเทรซเพื่อช่วยคุณค้นหาลิงก์ทั่วไประหว่างเหตุการณ์ที่นำไปสู่งานนี้
ด้วยฟีเจอร์ใหม่ที่ชื่อว่า "การติดแท็กสแต็กแบบไม่พร้อมกัน" คุณจึงสามารถบอกเล่าเรื่องราวทั้งหมดได้โดยการลิงก์โค้ดทั้ง 2 ส่วนเข้าด้วยกัน
API การติดแท็กสแต็กแบบไม่พร้อมกันมีเมธอด console ใหม่ชื่อ console.createTask() ลายเซ็น API มีดังนี้
interface Console {
createTask(name: string): Task;
}
interface Task {
run<T>(f: () => T): T;
}
การเรียก console.createTask() จะแสดงผลอินสแตนซ์ Task ที่คุณสามารถใช้เพื่อเรียกใช้เนื้อหาของงาน f ในภายหลัง
// Task Creation
const task = console.createTask(name);
// Task Execution
task.run(f);
งานจะสร้างลิงก์ระหว่างบริบทที่สร้างและบริบทของฟังก์ชันอะซิงโครนัสที่เรียกใช้
โค้ดข้างต้นจะใช้กับฟังก์ชัน makeScheduler จากด้านบนนี้
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
const task = console.createTask(f.name);
tasks.push({ task, f });
},
work() {
while (tasks.length) {
const { task, f } = tasks.shift();
task.run(f); // instead of f();
}
},
};
}
ในตอนนี้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome จึงแสดงสแต็กเทรซที่ดียิ่งขึ้นได้
สังเกตว่าตอนนี้มี businessLogic() รวมอยู่ในสแต็กเทรซอย่างไร ไม่เพียงเท่านั้น งานยังมีชื่อที่คุ้นเคย someTask ซึ่งแทน requestAnimationFrame ทั่วไปเหมือนก่อนหน้านี้
เฟรมการโทรที่เป็นกันเอง
เฟรมเวิร์กมักจะสร้างโค้ดจากภาษาเทมเพลตทุกชนิดเมื่อสร้างโปรเจ็กต์ เช่น เทมเพลต Angular หรือ JSX ที่เปลี่ยนโค้ดแบบ HTML เป็น JavaScript ธรรมดาที่ทำงานในเบราว์เซอร์ในที่สุด บางครั้งฟังก์ชันที่สร้างขึ้นประเภทนี้จะมีชื่อที่ใช้ยาก อาจเป็นชื่อตัวอักษรเดียวหลังจากที่ลดขนาดลง หรืออาจใช้ชื่อที่คลุมเครือหรือไม่คุ้นเคยแม้ว่าจะไม่ได้เป็นเช่นนั้นก็ตาม
ในโปรเจ็กต์ตัวอย่าง ตัวอย่างของสิ่งนี้คือ AppComponent_Template_app_button_handleClick_1_listener ที่คุณเห็นในสแต็กเทรซ
เพื่อจัดการกับปัญหานี้ ขณะนี้ Chrome DevTools รองรับการเปลี่ยนชื่อฟังก์ชันเหล่านี้ผ่านการแมปแหล่งที่มา หากการแมปแหล่งที่มามีรายการชื่อสําหรับจุดเริ่มต้นของขอบเขตฟังก์ชัน เฟรมการเรียกใช้ควรแสดงชื่อนั้นในสแต็กเทรซ
ในฐานะผู้เขียน คุณไม่จำเป็นต้องดำเนินการใดๆ เพื่อเปิดใช้ลักษณะการทำงานใหม่นี้ การเปลี่ยนแปลงนี้ขึ้นอยู่กับเฟรมเวิร์ก
มองไปข้างหน้า
ข้อมูลที่เพิ่มเข้ามาในโพสต์นี้ทำให้ Chrome DevTools สามารถมอบประสบการณ์การแก้ไขข้อบกพร่องที่ดียิ่งขึ้นได้ ยังมีส่วนอื่นๆ ที่ทีมต้องการสำรวจด้วย โดยเฉพาะอย่างยิ่งวิธีปรับปรุงประสบการณ์การทำโปรไฟล์ในเครื่องมือสำหรับนักพัฒนาเว็บ
ทีม Chrome DevTools ส่งเสริมให้ผู้เขียนเฟรมเวิร์กใช้ความสามารถใหม่เหล่านี้ กรณีศึกษา: การแก้ไขข้อบกพร่อง Angular ที่ดีขึ้นด้วยเครื่องมือสำหรับนักพัฒนาเว็บมีคำแนะนำเกี่ยวกับวิธีการนำไปใช้