Chrome DevTools में वेब को डीबग करने के लिए आधुनिक तरीके की सुविधा

Bramus

Victor Porof

परिचय

आज, लेखक अपने वेब ऐप्लिकेशन बनाने के लिए कई अमूर्तों का उपयोग कर सकते हैं. वेब प्लैटफ़ॉर्म से मिलने वाले निचले लेवल के एपीआई के साथ सीधे तौर पर इंटरैक्ट करने के बजाय, कई लेखक फ़्रेमवर्क का फ़ायदा लेते हैं, टूल बनाते हैं, और अपने ऐप्लिकेशन को उच्च-लेवल के नज़रिए से लिखने के लिए कंपाइलर बनाते हैं.

उदाहरण के लिए, ऐंग्युलर फ़्रेमवर्क पर आधारित कॉम्पोनेंट, HTML टेंप्लेट के साथ TypeScript में लिखे जाते हैं. हुड के नीचे, Angular CLI और Webpack सभी कॉन्टेंट को JavaScript में और एक तथाकथित बंडल में कंपाइल कर देते हैं. इसके बाद, उन्हें ब्राउज़र पर भेज दिया जाता है.

DevTools में वेब ऐप्लिकेशन को डीबग या प्रोफ़ाइल करते समय, आपने जो कोड लिखा है उसके बजाय फ़िलहाल आपको अपने कोड के कंपाइल किए गए वर्शन को देखने और डीबग करने की सुविधा मिलती है. लेखक के तौर पर, आपको इस बात की उम्मीद नहीं है:

• आपको छोटे किए गए JavaScript कोड को डीबग नहीं करना है. आपको अपने मूल JavaScript कोड को डीबग करना है.
• TypeScript का इस्तेमाल करते समय, आप JavaScript को डीबग नहीं करना चाहते, तो आप अपने मूल TypeScript कोड को डीबग करना चाहते हैं.
• अगर आपको Angular, Lit या JSX जैसे टेंप्लेट का इस्तेमाल करना है, तो ज़रूरी नहीं है कि आप उनसे मिलने वाले DOM को हमेशा डीबग करें. कॉम्पोनेंट को खुद ही डीबग करना चाहिए.

कुल मिलाकर, हो सकता है कि आप अपना कोड खुद ही डीबग करना चाहें जैसे आपने उसे लिखा था.

हालांकि, सोर्स मैप पहले ही इस अंतर को काफ़ी हद तक कम कर देते हैं, लेकिन इस क्षेत्र में Chrome DevTools और नेटवर्क की और भी चीज़ें की जा सकती हैं.

चलिए, इस पर एक नज़र डालते हैं!

ध्यान दें: GitHub पर Angular प्रोजेक्ट का यह नमूना, Chrome DevTools में हुए सुधारों के बारे में बताता है. ये सुधार, Angular तक ही सीमित नहीं हैं, बल्कि किसी भी फ़्रेमवर्क पर लागू होते हैं.

लिखा गया कोड बनाम डिप्लॉय किया गया कोड

फ़िलहाल, सोर्स पैनल में फ़ाइल ट्री पर नेविगेट करते समय, आपको कंपाइल किए गए और अक्सर छोटे किए गए बंडल का कॉन्टेंट दिखता है. ये वे वास्तविक फ़ाइलें हैं जिन्हें ब्राउज़र डाउनलोड करता है और चलाता है. DevTools इसे डिप्लॉय किया गया कोड कहते हैं.

यह बहुत आसान नहीं होता और इसे समझना अक्सर मुश्किल होता है. लेखक के तौर पर, आपको डिप्लॉय किया गया कोड नहीं, बल्कि वह कोड देखना और डीबग करना है जिसे आपने लिखा है.

इसे ठीक करने के लिए, अब ट्री को लेखक कोड दिखाने की अनुमति दें. इससे ट्री, अपने आईडीई में दिखने वाली सोर्स फ़ाइलों से काफ़ी मिलता-जुलता हो जाता है और ये फ़ाइलें अब डिप्लॉय किए गए कोड से अलग हो जाती हैं.

Chrome DevTools में यह विकल्प चालू करने के लिए, सेटिंग > पर जाएं एक्सपेरिमेंट और सोर्स किए गए और डिप्लॉय किए गए ट्री में ग्रुप के सोर्स को चुनें.

ध्यान दें: Chrome DevTools की टीम जल्द ही इस एक्सपेरिमेंट को डिफ़ॉल्ट रूप से चालू करने की योजना बना रही है. हमें यहां सुझाव, शिकायत या राय भेजें.

“सिर्फ़ मेरा कोड”

ध्यान दें: यह सुविधा झलक देखने के लिए है. यह Chrome कैनरी के वर्शन 106 में उपलब्ध है.

डिपेंडेंसी का इस्तेमाल करते समय या फ़्रेमवर्क का इस्तेमाल करते समय, तीसरे पक्ष की फ़ाइलें आपके काम आ सकती हैं. कई बार आपको सिर्फ़ अपना कोड देखना होता है, न कि node_modules फ़ोल्डर में मौजूद कुछ तीसरे पक्ष की लाइब्रेरी का कोड.

इसे ठीक करने के लिए, DevTools में एक और सेटिंग डिफ़ॉल्ट रूप से चालू होती है: जानकारी को अनदेखा करने की सूची में, तीसरे पक्ष की स्क्रिप्ट अपने-आप जोड़ें. इसे DevTools > में देखा जा सकता है सेटिंग > सूची को अनदेखा करें.

यह सेटिंग चालू होने पर, DevTools ऐसी किसी भी फ़ाइल या फ़ोल्डर को छिपा देता है जिसे किसी फ़्रेमवर्क या बिल्ड टूल ने अनदेखे करने के लिए के तौर पर मार्क किया है.

Angular v14.1.0 के बाद से, इसके node_modules और webpack फ़ोल्डर के कॉन्टेंट को इस तरह मार्क किया गया है. इसलिए, ये फ़ोल्डर, उनमें मौजूद फ़ाइलें, और तीसरे पक्ष के अन्य आर्टफ़ैक्ट, DevTools में अलग-अलग जगहों पर नहीं दिखते हैं.

लेखक के रूप में, आपको इस नए व्यवहार को चालू करने के लिए कुछ भी करने की ज़रूरत नहीं है. इस बदलाव को लागू करने का काम फ़्रेमवर्क पर निर्भर करता है.

ध्यान दें: अनदेखा करने की सूची को सोर्स मैप में एक और x_google_ignoreList फ़ील्ड भरकर चालू किया जाता है, जिसे प्रोजेक्ट को कंपाइल करते समय Angular जनरेट करता है. Chrome DevTools की टीम, फ़्रेमवर्क के अन्य लेखकों को इसी तरह के बदलाव करने की सलाह देती है. ज़्यादा जानकारी के लिए, केस स्टडी: DevTools की मदद से बेहतर ऐंग्युलर डीबगिंग करना पोस्ट पढ़ें.

स्टैक ट्रेस में अनदेखा किया गया कोड

स्टैक ट्रेस में एक ऐसी जगह होती है जहां अनदेखा करने की सूची में दी गई फ़ाइलें अब नहीं दिखतीं. लेखक के तौर पर, अब आपको ज़्यादा काम के स्टैक ट्रेस देखने को मिले हैं.

अगर आपको स्टैक ट्रेस के सभी कॉल फ़्रेम देखने हैं, तो कभी भी ज़्यादा फ़्रेम दिखाएं लिंक पर क्लिक किया जा सकता है.

डीबग करने और अपने कोड का इस्तेमाल करने के दौरान आपको दिखने वाले कॉल स्टैक पर भी यही लागू होता है. जब फ़्रेमवर्क या बंडलर, DevTools को तीसरे पक्ष की स्क्रिप्ट के बारे में बताते हैं, तो DevTools सभी ऐसे कॉल फ़्रेम को अपने-आप छिपा देता है जो काम के नहीं हैं. साथ ही, स्टेप-डीबग करते समय, अनदेखा किए गए किसी भी कोड पर सीधे आगे बढ़ जाते हैं.

फ़ाइल ट्री में अनदेखा किया गया कोड

सोर्स पैनल में, ऑथर कोड फ़ाइल ट्री से अनदेखा की गई फ़ाइलों और फ़ोल्डर को छिपाने के लिए, सेटिंग में जाकर, सोर्स ट्री व्यू में, अनदेखा किए गए कोड की सूची में शामिल कोड को छिपाएं को चुनें > DevTools में एक्सपेरिमेंट.

Angular प्रोजेक्ट के सैंपल में, अब node_modules और webpack फ़ोल्डर छिपा दिए गए हैं.

“क्विक ओपन” मेन्यू में नज़रअंदाज़ किए गए कोड की सूची

अनदेखा किया गया कोड न सिर्फ़ फ़ाइल ट्री से छिपा होता है, बल्कि “क्विक ओपन” मेन्यू (Control+P (Linux/Windows) या Command+P (Mac)) से भी छिपा होता है.

स्टैक ट्रेस को बेहतर बनाया गया

Chrome DevTools पहले से ही काम के स्टैक ट्रेस को कवर कर चुका है. इसकी मदद से, स्टैक ट्रेस को बेहतर बनाया गया है.

लिंक किए गए स्टैक ट्रेस

जब कुछ कार्रवाइयां एसिंक्रोनस रूप से शेड्यूल होती हैं, तो 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() कॉल के बारे में कोई जानकारी नहीं दिखती जो इस कार्रवाई की “मुख्य वजह” थी.

इसके बजाय, आपको सिर्फ़ वह फ़्रेमवर्क शेड्यूलिंग लॉजिक दिखता है जिसकी मदद से टास्क पूरा किया जाता है. स्टैक ट्रेस में कोई ब्रेडक्रंब नहीं होता. इससे आपको टास्क तक ले जाने वाले इवेंट के बीच के लिंक का पता लगाने में मदद मिलती है.

“एसिंक स्टैक टैगिंग” नाम की एक नई सुविधा की मदद से, एसिंक कोड के दोनों हिस्सों को एक साथ लिंक करके पूरी कहानी बताई जा सकती है.

एसिंक्रोनस स्टैक टैगिंग एपीआई में console.createTask() नाम का एक नया console तरीका जोड़ा गया है. एपीआई सिग्नेचर ऐसा होता है:

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);

टास्क, उस कॉन्टेक्स्ट के बीच लिंक बनाता है जहां उसे बनाया गया था और उस एसिंक फ़ंक्शन के कॉन्टेक्स्ट के बीच लिंक बनाता है जो एक्ज़ीक्यूट किया जा रहा है.

ध्यान दें: एक साथ काम न करने वाला स्टैक टैगिंग एपीआई, Chrome 106 में उपलब्ध है.

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 DevTools अब बेहतर स्टैक ट्रेस दिखा पा रहा है.

ध्यान दें कि अब businessLogic() को स्टैक ट्रेस में किस तरह शामिल किया गया है! सिर्फ़ इतना ही नहीं, बल्कि इस टास्क को पहले से ही सामान्य requestAnimationFrame के बजाय, जाना-पहचाना नाम someTask मिला है.

ध्यान दें: ज़्यादातर मामलों में आपको एसिंक्रोनस स्टैक टैगिंग एपीआई को लेकर परेशान होने की ज़रूरत नहीं होती है, क्योंकि इस्तेमाल किए जा रहे फ़्रेमवर्क से शेड्यूल करने और एसिंक्रोनस एक्ज़ीक्यूशन को मैनेज किया जा सकता है. ऐसे मामले में, एपीआई को लागू करने का काम फ़्रेमवर्क पर निर्भर करता है.

फ़्रेंडली कॉल फ़्रेम

प्रोजेक्ट तैयार करते समय, फ़्रेमवर्क अक्सर सभी तरह की टेंप्लेट वाली भाषाओं से कोड जनरेट करते हैं. उदाहरण के लिए, Angular या JSX टेंप्लेट. ये टेंप्लेट, एचटीएमएल दिखने वाले कोड को सामान्य JavaScript में बदल देते हैं, जो आखिर में ब्राउज़र में चलता है. कभी-कभी, इस तरह के जनरेट किए गए फ़ंक्शन को ऐसे नाम दिए जाते हैं जो बहुत अच्छे नहीं होते — छोटा कर दिए जाने के बाद या तो एक अक्षर वाले नाम या कुछ ऐसे नाम जो समझ में नहीं आते हैं या अनजान नाम से जुड़े होते हैं, भले ही वे ऐसा न हों.

सैंपल प्रोजेक्ट में, इसका एक उदाहरण AppComponent_Template_app_button_handleClick_1_listener है. यह आपको स्टैक ट्रेस में दिखता है.

इसे ठीक करने के लिए, Chrome DevTools में अब सोर्स मैप की मदद से इन फ़ंक्शन के नाम बदले जा सकते हैं. अगर किसी सोर्स मैप में फ़ंक्शन के स्कोप की शुरुआत के लिए कोई नाम डाला गया है, तो कॉल फ़्रेम में स्टैक ट्रेस में वह नाम दिखना चाहिए.

लेखक के रूप में, आपको इस नए व्यवहार को चालू करने के लिए कुछ भी करने की ज़रूरत नहीं है. इस बदलाव को लागू करने का काम फ़्रेमवर्क पर निर्भर करता है.

आगे की योजनाएं

इस पोस्ट में दी गई जानकारी के लिए धन्यवाद. Chrome DevTools आपको डीबग करने का बेहतर अनुभव दे सकता है. टीम अन्य क्षेत्रों को एक्सप्लोर करना चाहती है. खास तौर पर, DevTools में प्रोफ़ाइलिंग के अनुभव को बेहतर बनाने का तरीका.

Chrome DevTools टीम, फ़्रेमवर्क के लेखकों को इन नई सुविधाओं का इस्तेमाल करने के लिए बढ़ावा देती है. केस स्टडी: DevTools की मदद से बेहतर ऐंग्युलर डीबगिंग का इस्तेमाल करके, इसे लागू करने के बारे में दिशा-निर्देश दिए गए हैं.