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

Bramus

Victor Porof

शुरुआती जानकारी

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

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

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

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

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

हालांकि, सोर्स मैप इस अंतर को कुछ हद तक कम कर रहे हैं, लेकिन इस क्षेत्र में Chrome DevTools और नेटवर्क बहुत कुछ कर सकते हैं.

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

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

लिखे गए कोड बनाम डिप्लॉय किए गए कोड की तुलना

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

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

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

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

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

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

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

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

इसे ठीक करने के लिए, DevTools में डिफ़ॉल्ट रूप से एक अन्य सेटिंग चालू होती है: तीसरे पक्ष की स्क्रिप्ट को अनदेखा करने की सूची में अपने-आप जोड़ना. इसे DevTools > 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() कॉल के बारे में कोई जानकारी नहीं दिखती.

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

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

Async Stack Tagging API एक नया console तरीका उपलब्ध कराता है, जिसका नाम console.createTask() है. एपीआई सिग्नेचर इस तरह का होता है:

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() को अब स्टैक ट्रेस में कैसे शामिल किया गया है! सिर्फ़ इतना ही नहीं, टास्क का एक जाना-पहचाना नाम someTask है, जो पहले की तरह सामान्य requestAnimationFrame की जगह पर है.

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

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

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

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

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

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

आगे की जानकारी

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

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