ब्राउज़र में इस्तेमाल होने वाली डिबगिंग तकनीकें

(alan.norbauer.com)

5 पॉइंट द्वारा GN⁺ 2023-11-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें

अगर आप ब्राउज़र Developer Tools को मध्यम स्तर से ऊपर तक इस्तेमाल कर सकते हैं, तो conditional breakpoints को सिर्फ stop condition नहीं बल्कि log, trace, state change और time measurement tools तक विस्तार दे सकते हैं
अगर console.log, console.count, console.trace, console.time जैसे console API को breakpoint या Watch Pane में रखें, तो execution रोके बिना flow और state को रिकॉर्ड किया जा सकता है
function argument count, time, CSS computed values, execution count, random sampling और global boolean को मिलाकर कब रुकना है इसे कहीं ज़्यादा सटीक ढंग से नियंत्रित किया जा सकता है
Chrome के monitor, debug, copy, $0, getEventListeners, monitorEvents से function calls, DOM, events और clipboard operations को console से तेज़ी से संभाला जा सकता है
जिन स्क्रीन पर DOM, JS या user events की वजह से लगातार बदलता रहता है, वहाँ JS pause, setTimeout(debugger), DOM snapshots और focus monitoring HTML/CSS debugging में खास तौर पर उपयोगी हैं

conditional breakpoints को debugging tool के रूप में बढ़ाना

conditional breakpoint में सिर्फ true/false condition ही नहीं, बल्कि side effects वाले JavaScript expressions भी डाले जा सकते हैं
इसका उपयोग करके basic breakpoint को log, trace, state change और time measurement tool की तरह इस्तेमाल किया जा सकता है
logpoint और tracepoint
- conditional breakpoint में console.log कॉल करने पर वह execution रोके बिना console में value छोड़ने वाले logpoint की तरह काम करता है
- console.count इस्तेमाल करने पर यह भी गिना जा सकता है कि वह line कितनी बार execute हुई
- मई 2020 के update के अनुसार प्रमुख browsers logpoint/tracepoint को सीधे support करते हैं
Watch Pane में console API का उपयोग
- Watch Pane में भी console.log जैसे expressions डाले जा सकते हैं
- application जब भी debugger में रुकता है, तब console.table(localStorage) से localStorage snapshot लिया जा सकता है
- DOM change breakpoint और Watch expressions को साथ में इस्तेमाल करने पर DOM subtree change के बाद snapshot को array में store किया जा सकता है
```
(window.doms = window.doms || []).push(document.documentElement.outerHTML)
```
- DOM change breakpoint को execution रोके बिना काम करने के लिए सेट नहीं किया जा सकता
call stack trace करना
- जब loading spinner दिखाने वाली function और छिपाने वाली function हों, और समस्या यह हो कि सिर्फ show call बच रहा हो, तब console.trace को conditional breakpoint में डाल सकते हैं
- show function की आख़िरी stack trace में caller पर click करके उस call location पर जा सकते हैं
runtime में program behavior बदलना
- conditional breakpoint expression में function arguments को overwrite करके ब्राउज़र के अंदर program behavior को तुरंत बदला जा सकता है
- उदाहरण के लिए getPerson function के id value को बदला जा सकता है
- id=1 जैसे truthy expression debugger को रोक देंगे, इसलिए अगर रुकना नहीं हो तो , false जोड़ सकते हैं
तेज़ performance measurement
- क्योंकि conditional breakpoint evaluation time भी इसमें मिल जाता है, इसलिए यह precise performance profiling के लिए उपयुक्त नहीं है
- जब तेज़ measurement चाहिए, तब start point condition में console.time('label') और end point condition में console.timeEnd('label') डालकर execution time console में छोड़ा जा सकता है

break condition को और सटीक बनाना

function argument count का उपयोग
- अगर current function सिर्फ 3 arguments के साथ call होने पर ही रुकना चाहिए, तो यह condition इस्तेमाल की जा सकती है
```
arguments.callee.length === 3
```
- optional arguments वाले overloaded function में यह उपयोगी है
- अगर defined argument count और actual passed argument count अलग हों तभी रुकना हो, तो यह condition इस्तेमाल की जा सकती है
```
(arguments.callee.length) != arguments.length
```
- यह function call location की bug ढूँढने में मदद करता है
time-based conditions
- अगर page load के 5 सेकंड बाद ही रुकना हो, उससे पहले नहीं, तो यह condition इस्तेमाल की जा सकती है
```
performance.now() > 5000
```
- जब breakpoint सिर्फ initial page load के बाद ही महत्वपूर्ण हो, तब यह उपयुक्त है
- अगर breakpoint सेट होने के बाद अगले 5 सेकंड तक न रुके और उसके बाद रुकने लगे, तो baseline time को global variable में store किया जा सकता है
```
window.baseline = window.baseline || Date.now(),
(Date.now() - window.baseline) > 5000
```
- console में window.baseline = Date.now() चलाकर counter को फिर से शुरू किया जा सकता है
CSS state-based conditions
- computed CSS values को भी condition बनाकर रोका जा सकता है
- उदाहरण के लिए, अगर document.body का background color लाल होने पर ही रुकना हो, तो यह condition इस्तेमाल की जा सकती है
```
window.getComputedStyle(document.body).backgroundColor === "rgb(255,0,0)"
```
execution count और sampling
- line हर बार execute होने पर counter बढ़ाकर हर दूसरी बार रुकना संभव है
```
window.counter = (window.counter || 0) + 1, window.counter % 2 === 0
```
- random sampling के लिए 10 में से 1 बार ही रुकना हो, तो यह condition इस्तेमाल की जा सकती है
```
Math.random() < 0.1
```
कुछ locations पर कभी न रुकना
- Chrome में gutter पर right-click करके “Never Pause Here” चुनने पर हमेशा false रहने वाला conditional breakpoint बनता है, जिससे उस line पर रुकना बंद हो जाता है
- इसे XHR breakpoint में किसी खास line को exclude करने या कुछ exceptions को ignore करने के लिए इस्तेमाल किया जा सकता है
instance ID अपने-आप देना
- class constructor में conditional breakpoint डालकर हर instance को array में store किया जा सकता है
```
(window.instances = window.instances || []).push(this)
```
- किसी specific instance की unique ID को array index से जाना जा सकता है
```
window.instances.indexOf(instance)
```
breakpoint global toggle
- एक या एक से ज़्यादा conditional breakpoints को global boolean से control किया जा सकता है
- इसे console से सीधे, किसी दूसरे breakpoint से, या timer के ज़रिए बदला जा सकता है
```
window.enableBreakpoints = true
setTimeout(() => (window.enableBreakpoints = true), 5000)
```

function और class calls का trace करना

class method calls की निगरानी
- Chrome के monitor command-line method का उपयोग करके class method calls को आसानी से trace किया जा सकता है
- अगर Dog class के सभी instances के method calls देखना हो, तो prototype की सभी properties पर monitor apply किया जा सकता है
```
var p = Dog.prototype;
Object.getOwnPropertyNames(p).forEach((k) => monitor(p[k]));
```
- console में function bark called with arguments: 2 जैसी call information दिखाई देगी
- अगर सिर्फ log छोड़ने के बजाय call पर execution रोकना हो, तो monitor की जगह debug इस्तेमाल किया जा सकता है
किसी specific instance से class trace करना
- अगर class name नहीं पता लेकिन instance मौजूद है, तो constructor के prototype के ज़रिए इसी तरह monitoring की जा सकती है
```
var p = instance.constructor.prototype;
Object.getOwnPropertyNames(p).forEach((k) => monitor(p[k]));
```
- यह किसी specific class तक सीमित हुए बिना arbitrary instance पर काम करने वाले function बनाने में उपयोगी है
console से function call से ठीक पहले debugging
- जिस function को debug करना है, उसे console से call करने से पहले debugger चलाएँ, फिर अगले function call पर Step into करें, तो function implementation के अंदर जा सकते हैं
```
debugger; fn(1);
```
- जब function definition location ढूँढना झंझट भरा हो, या fn dynamically bind हुआ हो और source location पता न हो, तब यह उपयोगी है
- Chrome में debug(fn) कॉल करके भी fn के हर call पर function के अंदर रुकवाया जा सकता है

URL change और property read debugging

SPA routing से पहले रुकना
- अगर single-page application के URL बदलने से ठीक पहले रुकना हो, तो history.pushState, history.replaceState, window.onhashchange, window.onpopstate पर debugger वाली function जोड़ सकते हैं
```
const dbg = () => {
  debugger;
};
history.pushState = dbg;
history.replaceState = dbg;
window.onhashchange = dbg;
window.onpopstate = dbg;
```
- dbg का यह version navigation को तोड़े बिना pause करने वाला implementation शामिल नहीं करता
- अगर window.location.replace या window.location.assign को सीधे call किया जाता है, तो assignment के तुरंत बाद page unload हो जाता है, इसलिए यह तरीका वहाँ काम नहीं करेगा
- Chrome में संबंधित methods पर debug लगाकर redirect source और उस समय की state देखी जा सकती है
```
debug(window.location.replace);
debug(window.location.assign);
```
property read होने की जगह ढूँढना
- अगर जानना हो कि object की किसी specific property को कब read किया जा रहा है, तो getter के अंदर debugger रखा जा सकता है
```
{ get configOption() { debugger; return true; } }
```
- यह देखने में उपयोगी है कि कोई code configuration option को कैसे और कहाँ इस्तेमाल करता है
- इसे original source में बदलकर या conditional breakpoint के ज़रिए लागू किया जा सकता है

console से data copy करना

copy() console API का उपयोग करके browser की जानकारी को string truncation के बिना clipboard में कॉपी किया जा सकता है
current DOM snapshot, image जैसी resources की metadata, बड़े JSON blob, और localStorage dump कॉपी करने में यह उपयोगी है

copy(document.documentElement.outerHTML)
copy(performance.getEntriesByType("resource"))
copy(JSON.parse(blob))
copy(localStorage)

HTML/CSS debugging

JS execution रुकी हुई अवस्था में DOM inspect करना
- DOM inspector में Chrome/Windows के आधार पर ctrl+\ दबाकर कभी भी JS execution रोकी जा सकती है
- जब JS DOM बदल रहा हो, या mouseover जैसे events DOM बदलते हों, तब भी current DOM snapshot को स्थिर रूप से inspect किया जा सकता है
गायब हो जाने वाले elements inspect करना
- mouse हिलाने पर गायब हो जाने वाले conditional DOM elements को inspect करने के लिए console में 5 सेकंड का timer लगाकर debugger चलाया जा सकता है
```
setTimeout(function() { debugger; }, 5000);
```
- 5 सेकंड तक UI खोलने के बाद जब JS execution रुकती है, तो element गायब नहीं होगा, इसलिए Developer Tools में जाकर उसे inspect किया जा सकता है
- JS execution रुकी रहने के दौरान element inspection, CSS editing और JS console commands चलाना संभव है
- यह cursor position या focus पर निर्भर DOM को inspect करने में प्रभावी है
DOM snapshots रिकॉर्ड करना
- current DOM कॉपी करने के लिए यह command इस्तेमाल की जा सकती है
```
copy(document.documentElement.outerHTML);
```
- अगर हर 1 सेकंड पर DOM string को array में store करना हो, तो setInterval इस तरह इस्तेमाल किया जा सकता है
```
doms = [];
setInterval(() => {
  const domStr = document.documentElement.outerHTML;
  doms.push(domStr);
}, 1000);
```
- array में store किए बिना इसे लगातार console में print भी किया जा सकता है

focused element की निगरानी

document.activeElement को समय-समय पर compare करके focus change को console में print किया जा सकता है

(function () {
  let last = document.activeElement;
  setInterval(() => {
    if (document.activeElement !== last) {
      last = document.activeElement;
      console.log("Focus changed to: ", last);
    }
  }, 100);
})();

bold दिखने वाले elements ढूँढना
- सभी elements में computed fontWeight का मान "bold" या "700" होने वाले elements ढूँढे जा सकते हैं
```
const isBold = (e) => {
  let w = window.getComputedStyle(e).fontWeight;
  return w === "bold" || w === "700";
};
Array.from(document.querySelectorAll("*")).filter(isBold);
```
- अगर अभी inspector में चुने गए element के descendants में ही ढूँढना हो, तो $0 के आधार पर search किया जा सकता है
```
Array.from($0.querySelectorAll("*")).filter(isBold);
```
चुने गए element और events को संभालना
- console का $0, Element Inspector में currently selected element का auto-reference है
- Chrome और Edge में पहले inspect किए गए elements को $1, और उससे पहले वाले को $2 की तरह access किया जा सकता है
- Chrome में currently selected element के event listeners देखे जा सकते हैं
```
getEventListeners($0)
```
- selected element के सभी events को debug करने के लिए monitorEvents($0) इस्तेमाल किया जा सकता है
- अगर सिर्फ specific event groups देखने हों, तो array pass किया जा सकता है
```
monitorEvents($0, ["control", "key"])
```

1 टिप्पणियां

GN⁺ 2023-11-12

Hacker News की राय

पिछले कई दशकों में ब्राउज़र में बने हुए debugging tools सच में बहुत आगे बढ़े हैं
JS को लंबे समय से इस्तेमाल करने वाले के नाते, मैं उन लोगों का गहराई से आभारी हूँ जिन्होंने ब्राउज़र के अंदर code debugging को इतना सहज बना दिया
जब backend या दूसरी languages जैसे अन्य development क्षेत्रों में जाते हैं, तो modern browser जो debugging tools ecosystem by default देता है उसकी कमी खलती है
- browser developer tools को सच में ऊँचाई पर ले जाने वाले Firebug extension बनाने वालों के लिए भी तालियाँ बनती हैं
- यह जानने की जिज्ञासा है कि JS debugging experience में आखिर ऐसा क्या खास लगता है
  मैंने Python, Java, C++ में भी कई वर्षों तक खूब debugging की है, लेकिन tools की कमी कभी महसूस नहीं हुई
  हाँ, इस क्षेत्र में उपलब्ध विकल्पों को न जानने वाले लोग काफी देखे हैं
- यह perfect नहीं है, लेकिन एक सहकर्मी developer जिस VS Code में Node.js debugging पर ज़ोर देता था, उस अनुभव से तो बहुत बेहतर है
  उस नरक से तो मैं console चुनूँगा
setTimeout(function() { debugger; }, 5000); काफ़ी चतुर है
आखिरकार Chrome debugger के खुद को ही debug करने वाले recursive turtle stack पर जीत पाने का एकमात्र तरीका debugger statement ही है
बदनाम Myspace Sammy worm के sam.pl ने भी visitors को obfuscated HTML homepage खंगालने से रोकने के लिए debugging trap का इस्तेमाल किया था
- यह मेरे अक्सर इस्तेमाल होने वाले bookmarklets में से एक है: https://darekkay.com/blog/debugging-dynamic-content/
- यह तब होता है जब कोई website खुली हुई Console/DevTools side panel को ब्लॉक करती है
  वह main loop चलाती है, इधर-उधर परेशान करने वाले debugger; statements डालती है, और 30FPS / 32ms interval पर execute करती है ताकि DevTools बेकार हो जाए
  क्योंकि debugger statement को “ignore” करने का कोई तरीका नहीं है
- अगर 5 सेकंड इंतज़ार नहीं करना है, तो script execution pause shortcut cmd-\\ इस्तेमाल किया जा सकता है
  page उसी JS line पर रुक जाएगा जो उस समय चल रही थी, और फिर आप सामान्य तरह से problematic element inspect कर सकते हैं
- अच्छा होता अगर browser बनाने वाले DevTools में इसे एक explicit option के रूप में रखते, और default में debugger statement को ignore कर देते
  debugger statement के ज्यादातर वैध उपयोग मामलों को, अगर आप अपने ही code पर काम कर रहे हैं, साधारण breakpoint से बदला जा सकता है
- एक मिनट, बस इतना ही? यह बहुत simple है, और इसलिए बहुत बढ़िया है
यह देखकर हैरानी होती है कि queryObjects गायब है
यह एक काफ़ी पागलपन भरा API है जो किसी खास constructor से बने सभी objects की सूची लौटा देता है
उदाहरण के लिए queryObjects(Function) से heap में मौजूद सभी functions की सूची मिल सकती है
यह किसी module के अंदर की “private” functions तक वापस दे देता है
- सच कहूँ तो इसे ज़्यादा प्रचारित न करना भी जायज़ लगता है
  यह वाकई पागलपन वाली सुविधा है, और शायद Chromium-only होगी
मैं watch variables को ठीक से कभी इस्तेमाल ही नहीं कर पाता
scope और update rules इतने अस्पष्ट हैं कि लगता है शायद सिर्फ global variables ही watch किए जा सकते हैं, लेकिन वह भी उम्मीद के मुताबिक काम नहीं करते, इसलिए test करते समय आखिर में values के logs से console भरना पड़ता है
मैं कई सालों से सोच रहा हूँ कि console में Data.gui [1] स्टाइल का UI होना चाहिए ताकि variables और settings values को देखते हुए test किया जा सके
इस CodePen [2] में इसे सचमुच काम करते देखा जा सकता है
1. https://github.com/dataarts/dat.gui
2. https://codepen.io/russellbeattie/full/kGxaqM
- मुझे भी यही निराशा महसूस हुई
  browser में सिद्धांत रूप से बेहतरीन debugging features बहुत हैं, लेकिन व्यवहार में वे भरोसेमंद ढंग से काम करते नहीं लगते
  breakpoints तक को पूरी तरह स्थिर रूप से लगवाना मुश्किल होता है
  code unbundled हो तो ठीक लगता है, लेकिन bundling होते ही, भले minify न किया गया हो, debugger की बहुत-सी सुविधाएँ टूटती हुई लगीं
  मैं frontend engineer नहीं हूँ, इसलिए हो सकता है मैं ही कुछ गलत कर रहा हूँ
- debugger में source maps बंद करके देखना चाहिए
  शायद वही इस झुंझलाहट की वजह हों, और active debugging के दौरान अनुभव इतना खराब होने के बावजूद वे default में on क्यों हैं, यह आज तक समझ नहीं आया
- Chrome sidebar panel में minified variables सही नाम से दिखते हैं, लेकिन watchpoint में undefined होने की error आती है, जो बेहद खीझ दिलाती है
अगर कोड का execution रोके बिना IIFE के local variables तक पहुँचने का कोई तरीका हो तो अच्छा होगा
क्या debugger को मनाकर ऐसा करवाने का कोई तरीका है?
- IIFE का मतलब Immediately Invoked Function Expression है
  https://en.m.wikipedia.org/wiki/Immediately_invoked_function...
- अगर IIFE द्वारा कॉल किए गए function में breakpoint पर पहुँचे हैं, तो बस stack में ऊपर जाएँ
  अगर आप पूरी तरह IIFE के बाहर हैं, तो यह संभव नहीं लगता
  जिस variable को आप ढूँढ रहे हैं, वह execution से पहले या बाद में memory में मौजूद भी न हो सकता है
  JavaScript में दूसरी भाषाओं की तरह static variables नहीं होते, इसलिए हर बार IIFE कॉल होने पर उसके अंदर के variables हटा दिए जाते हैं
  JavaScript का single-threaded मॉडल काफ़ी मज़बूत है, जब तक आप web worker जैसी चीज़ें नहीं इस्तेमाल कर रहे; इसलिए अगर आप async/await calls से जानबूझकर race condition नहीं बना रहे, तो IIFE scope के बाहर ऐसे variables के memory में बचे रहने की अवधारणा ही मुश्किल से लागू होती है
  अगर आप var का ज़्यादा इस्तेमाल करके IIFE scope के बाहर variables initialize करते हैं, तो आख़िरी IIFE call द्वारा बनाया गया value देख सकते हैं
- लगभग 12 साल पहले मैंने ऐसा काम करने वाला एक tool बनाया था
  उसमें थोड़ा modification चाहिए होगा, लेकिन मेहनत के हिसाब से फ़ायदा बड़ा है
  https://github.com/kristopolous/_inject
  किसी भी मनचाहे समय पर लगभग किसी भी function context में घूमकर देख सकते हैं कि क्या हुआ था
  यह reference counter का दुरुपयोग करके context को नष्ट होने से बचाता है
  जब मैं client-side JS बहुत करता था, तब यह सच में बहुत उपयोगी था
  इसका ठीक से बनाया गया killer app version ऐसा होगा जो किसी भी context में REPL खोल दे
  अभी की हालत में भी इसे अच्छी तरह इस्तेमाल करने के लिए काफ़ी skill चाहिए
- क्या आप logpoint ढूँढ रहे हैं?
  https://firefox-source-docs.mozilla.org/devtools-user/debugg...
  संपादन: अभी समझ आया कि linked post में literally सबसे पहले इसी की बात की गई है
- Chrome में https://news.ycombinator.com/item?id=38226743#38231705 में बताए गए closure को Watch panel में inspect करें, फिर [[Scopes]] pseudo-property देखें
  Firefox में इसका कोई तरीका नहीं लगता
completeness के लिए Werkzeug की सिफारिश की जा सकती है
मैं इसे Django backend development में इस्तेमाल कर रहा हूँ और यह बेहद उपयोगी है
जहाँ भी exception होता है, वहाँ कभी भी browser के अंदर “PDB” shell इस्तेमाल करने देता है
- जहाँ browser में Werkzeug खोलना हो, वहाँ बस 1/0 डालना होता है, इसलिए आसान है
- मैं nose.js और browser समेत हर जगह ऐसा अनुभव चाहता हूँ
  यह बहुत simple और intuitive है
- क्या अभी भी django-extension/runserver_plus की ज़रूरत है?
एक तरकीब जो मैं हमेशा इस्तेमाल करता हूँ, वह है UI strings से loaded scripts को search करके debugging करना
Network panel में जाएँ, network requests की recording शुरू करें, फिर left sidebar खोलकर वह code या UI string खोजें जिसे आप ढूँढ रहे हैं
आमतौर पर यह किसी अजीब bundle JS chunk file के अंदर मिलती है, और result पर क्लिक करने से उस file की network request खुल जाती है
उस file में कहीं भी right-click करके “Open in Sources” जैसा विकल्प चुनें, तो debugger पर पहुँच जाएँगे
अब debugger statement रख सकते हैं, और इस process में source maps भी शायद load हो जाएँगे
लंबे समय तक Python/Elixir programmer के रूप में काम करते हुए मैंने pdb.set_trace() और IEx.pry() का बहुत इस्तेमाल किया है
हाल ही में मुझे एक बेहद गंदा NodeJS backend संभालना पड़ा है, और बिना किसी ढंग के debugging tools के मैं अपने बचे-खुचे बाल नोच रहा हूँ
मैं फिर से console.log debugging पर लौट आया हूँ, लेकिन खुद को आदिमानव जैसा महसूस कर रहा हूँ
यक़ीन नहीं होता कि इतने लोकप्रिय ecosystem में कोई ढंग का debugging REPL नहीं है; क्या कोई बता सकता है कि मुझे कहाँ जाना चाहिए?
- है
  node --inspect-brk इस्तेमाल करें, और VS Code या Chrome DevTools से connect करें
  मुश्किल हिस्सा यह है कि TypeScript transformation जैसे build tools nodejs command से पहले हैं या नहीं
  अगर आप सीधे node चला रहे हैं, तो यह काफ़ी आसान है
  debugging REPL असल में JavaScript console ही है
- VSCode developer tools का इस्तेमाल करें तो NodeJS में भी काफ़ी solid debugging हो जाती है
  debugging options में जोड़ें, फिर breakpoint लगा सकते हैं और functions के अंदर step कर सकते हैं
  ज़्यादातर चीज़ें objects के अंदर encapsulated होती हैं, इसलिए JavaScript debugging के लिए काफ़ी अच्छी है
- जैसा दूसरे लोगों ने कहा, आपको --inspect या --inspect-brk चाहिए
  VSCode में “open JavaScript debug terminal” command भी इस्तेमाल कर सकते हैं
  यह command ऐसा terminal खोलती है जिसमें कोई भी node command अपने-आप debugger attached होकर शुरू होता है
- शायद यह काफ़ी न हो, लेकिन अभी-अभी मुझे python snoop के बारे में पता चला
  https://pypi.org/project/snoop/
  यह deep tracing के लिए decorator है
- Elixir REPL की एक अच्छी बात, जो Erlang REPL जैसी लगती है, यह है कि आप running process से attach कर सकते हैं
  Node JS ecosystem में मैंने ऐसी capability नहीं देखी है
“Debugging Property Reads” सेक्शन में मुझे यह जानना है कि conditional breakpoint का इस्तेमाल करके {configOption: true} को {get configOption() { debugger; return true; }} में कैसे बदला जाता है
- वह conditional breakpoint शीर्षक के नीचे वाली बात नहीं है
  console में value को getter से override कर सकते हैं, और अगर write permission हो तो source code में सीधे भी बदल सकते हैं
यह ऐसी चीज़ लगती है जो ज़रूर सीखनी चाहिए, लेकिन सोच रहा हूँ कि क्या इसके लिए कोई खास किताब या सीखने की सामग्री है
या फिर बस वेब डेवलपमेंट और फ्रंटएंड में लगातार और गहराई तक जाते रहने के अलावा कोई रास्ता नहीं है?
- Chrome टीम की What’s new in DevTools सीरीज़ को फॉलो करने की मैं सच में सिफारिश करूँगा
  जब आप किसी काम के बीच में हों, तो release notes पढ़ने के लिए लिंक पर क्लिक करने का मन शायद न करे, लेकिन नया version आने पर सिर्फ 5 मिनट भी सरसरी नज़र डालना पूरी तरह काबिल-ए-गौर है
  कुछ ही मिनटों के आसान वीडियो भी हैं, जिनसे जल्दी एक साधारण overview मिल जाता है
  मकसद भले नए फीचर्स का परिचय देना हो, लेकिन मेरे अनुभव में इससे अक्सर टूल की मौजूदा सीमाएँ भी समझ में आती हैं

ब्राउज़र में इस्तेमाल होने वाली डिबगिंग तकनीकें

conditional breakpoints को debugging tool के रूप में बढ़ाना

logpoint और tracepoint

Watch Pane में console API का उपयोग

call stack trace करना

runtime में program behavior बदलना

तेज़ performance measurement

break condition को और सटीक बनाना

function argument count का उपयोग

time-based conditions

CSS state-based conditions

execution count और sampling

कुछ locations पर कभी न रुकना

instance ID अपने-आप देना

breakpoint global toggle

function और class calls का trace करना

class method calls की निगरानी

किसी specific instance से class trace करना

console से function call से ठीक पहले debugging

URL change और property read debugging

SPA routing से पहले रुकना

property read होने की जगह ढूँढना

console से data copy करना

HTML/CSS debugging

JS execution रुकी हुई अवस्था में DOM inspect करना

गायब हो जाने वाले elements inspect करना

DOM snapshots रिकॉर्ड करना

focused element की निगरानी

bold दिखने वाले elements ढूँढना

चुने गए element और events को संभालना

संबंधित पढ़ाई

1 टिप्पणियां

Hacker News की राय