If you have ever refreshed a page and watched your CSS vanish, or reverted a file only to realize you cannot remember wh

നിങ്ങൾ എപ്പോഴെങ്കിലും ഒരു പേജ് റിഫ്രഷ് ചെയ്യുമ്പോൾ നിങ്ങളുടെ CSS അപ്രത്യക്ഷമാകുന്നത് കണ്ടിട്ടുണ്ടെങ്കിൽ, അല്ലെങ്കിൽ ഒരു ഫയൽ പഴയപടിയാക്കിയ ശേഷം നിങ്ങൾ എന്താണ് മാറ്റം വരുത്തിയതെന്ന് ഓർത്തെടുക്കാൻ കഴിയാതെ വന്നിട്ടുണ്ടെങ്കിൽ, കോഡ് എഴുതുന്നതിനും അത് നിയന്ത്രിക്കുന്നതിനും ഇടയിലുള്ള വ്യത്യാസം നിങ്ങൾക്ക് മനസ്സിലാകും. പ്രൊഫഷണൽ വെബ് ഡെവലപ്‌മെന്റിന്റെ അടിസ്ഥാനത്തിൽ രണ്ട് ആശയങ്ങളുണ്ട്: നിങ്ങളുടെ കോഡ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും ഡാറ്റ എങ്ങനെ സംഭരിക്കുന്നുവെന്നും തീരുമാനിക്കുന്ന ബ്രൗസർ എൻവയോൺമെന്റും (browser environment), നിങ്ങളുടെ പരീക്ഷണങ്ങൾ എന്നെന്നേക്കുമായി നഷ്ടപ്പെട്ടുപോകാതിരിക്കാൻ സഹായിക്കുന്ന Git-ഉം. ഇവ രണ്ടും നേരത്തെ തന്നെ പഠിക്കുന്നത് പിന്നീട് ഉണ്ടാകാൻ സാധ്യതയുള്ള നിഗൂഢമായ ബഗുകളിൽ നിന്നും (bugs) തകരാറിലായ ഡിപ്ലോയ്മെന്റുകളിൽ നിന്നും (deployments) നിങ്ങളെ രക്ഷിക്കും.

ഒരു അഡ്രസ് സിസ്റ്റം എന്ന നിലയിൽ URL

നിങ്ങൾ നാവിഗേഷൻ ബാറിൽ ഒരു അഡ്രസ് ടൈപ്പ് ചെയ്യുമ്പോഴെല്ലാം, ബ്രൗസറിന് ഒരു കൂട്ടം കോർഡിനേറ്റുകൾ കൈമാറുകയാണ് ചെയ്യുന്നത്. ഒരു Uniform Resource Locator എന്നത് വെറുമൊരു സ്ട്രിംഗ് (string) മാത്രമല്ല; അത് ആറ് വ്യത്യസ്ത ഭാഗങ്ങളായി തിരിക്കാവുന്ന ഒരു ഘടനാപരമായ നിർദ്ദേശ സഹായിയാണ് (instruction manual).

ആദ്യം വരുന്നത് protocol ആണ്, സാധാരണയായി HTTPS. ഇത് സെർവറുമായി എങ്ങനെ സംസാരിക്കണമെന്നും സംഭാഷണം എൻക്രിപ്റ്റ് (encrypt) ചെയ്യണമോ എന്നും ബ്രൗസറിനോട് പറയുന്നു. തുടർന്ന് domain, DNS വഴി ഒരു IP അഡ്രസ്സായി മാറുന്നു, അങ്ങനെ ബ്രൗസറിന് ഏത് ഫിസിക്കൽ അല്ലെങ്കിൽ വെർച്വൽ മെഷീനിലേക്കാണ് ബന്ധപ്പെടേണ്ടതെന്ന് മനസ്സിലാക്കാൻ സാധിക്കുന്നു.

ആ സെർവറിലെ കൃത്യമായ പ്രവേശന കവാടമാണ് (doorway) port സൂചിപ്പിക്കുന്നത്. വെബ് സെർവറുകൾ HTTPS-ന് വേണ്ടി 443 എന്ന പോർട്ട് ഡിഫോൾട്ട് ആയി ഉപയോഗിക്കുന്നതിനാൽ പ്രൊഡക്ഷൻ സൈറ്റുകളിൽ നിങ്ങൾ ഇത് അപൂർവ്വമായിട്ടേ കാണാറുള്ളൂ, എന്നാൽ ലോക്കൽ ഡെവലപ്‌മെന്റിൽ (local development) നിങ്ങൾ നിരന്തരം പോർട്ടുകൾ കൈകാര്യം ചെയ്യേണ്ടി വരും. localhost:3000 അല്ലെങ്കിൽ localhost:5173 എന്നിവയെക്കുറിച്ച് ചിന്തിക്കുക. പോർട്ട് തെറ്റാണെങ്കിൽ, കണക്ഷൻ ടൈം ഔട്ട് (time out) ആകും.

അടുത്തത് path ആണ്, ഇത് /blog/2024/march പോലെ ഒരു പ്രത്യേക ഫയലിലേക്കോ റൂട്ടിലേക്കോ (route) വിരൽ ചൂണ്ടുന്നു. അതിനുശേഷം query string വരുന്നു, ഇത് ചോദ്യചിഹ്നത്തിന് ശേഷം വരികയും ?category=javascript&sort=date പോലെ ഡാറ്റ സെർവറിലേക്ക് എത്തിക്കുകയും ചെയ്യുന്നു. അവസാനമായി, ഹാഷ് ചിഹ്നത്താൽ അടയാളപ്പെടുത്തിയ fragment, പേജിനുള്ളിലെ ഒരു പ്രത്യേക ഭാഗത്തേക്ക് വിരൽ ചൂണ്ടുന്നു. ഡോക്യുമെന്റേഷൻ ലിങ്കുകൾക്കും അക്സസിബിലിറ്റിക്കും (accessibility) ഫ്രാഗ്മെന്റുകൾ ഉപയോഗപ്രദമാണ്, കാരണം അവ പേജ് റീലോഡ് ചെയ്യാതെ തന്നെ ഉപയോക്താക്കളെ നേരിട്ട് ഒരു ഹെഡിംഗിലേക്ക് എത്തിക്കുന്നു.

ഈ ഘടന മനസ്സിലാക്കുന്നത് റൂട്ടിംഗ് പിശകുകൾ (routing errors) പരിഹരിക്കാനും (debug), കൂടുതൽ വ്യക്തമായ API-കൾ നിർമ്മിക്കാനും, നെറ്റ്‌വർക്ക് ലോഗുകൾ (network logs) എളുപ്പത്തിൽ വായിക്കാനും നിങ്ങളെ സഹായിക്കുന്നു.

DOM ആണ് നിങ്ങളുടെ റൺടൈം (Runtime)

ഒരു കംപൈലർ (compiler) ഒരു .c ഫയൽ ആദ്യം പാഴ്സ് (parse) ചെയ്യാതെ പ്രവർത്തിപ്പിക്കാത്തതുപോലെ, ബ്രൗസറുകളും വെറും HTML ടെക്സ്റ്റ് റെൻഡർ (render) ചെയ്യുന്നില്ല. ഒരു ബ്രൗസർ നിങ്ങളുടെ മാർക്കപ്പ് (markup) ഡൗൺലോഡ് ചെയ്യുമ്പോൾ, അത് ടാഗുകളെയും ടെക്സ്റ്റിനെയും Document Object Model (DOM)-ലേക്ക് മാറ്റുന്നു. ഇത് മെമ്മറിയിലുള്ള ഒരു ട്രീ (tree) ഘടനയാണ്, അവിടെ ഓരോ എലമെന്റും ജാവാസ്ക്രിപ്റ്റിന് (JavaScript) കൈകാര്യം ചെയ്യാവുന്ന ഒരു നോഡ് (node) ആയി മാറുന്നു.

നിങ്ങളുടെ പേജിന്റെ ജീവസ്സുറ്റ രൂപമാണ് DOM. നിങ്ങൾ ഒരു ഹാംബർഗർ ഐക്കണിൽ (hamburger icon) ക്ലിക്ക് ചെയ്യുമ്പോൾ ഒരു സൈഡ് മെനു വരുന്നുണ്ടെങ്കിൽ, ജാവാസ്ക്രിപ്റ്റ് സെർവറിൽ നിന്ന് പുതിയ HTML ആവശ്യപ്പെടുകയല്ല ചെയ്യുന്നത്. അത് DOM ട്രീ പരിശോധിക്കുകയും, ഒരു ക്ലാസ് (class) മാറ്റുകയും, ആ മാറ്റം കൈകാര്യം ചെയ്യാൻ CSS-നെ അനുവദിക്കുകയും ചെയ്യുന്നു. ഫോം വാലിഡേഷൻ (form validation), ലൈവ് കൗണ്ടറുകൾ, ഇൻഫിനിറ്റ് സ്ക്രോൾ (infinite scroll) എന്നിവയ്ക്കും ഇത് തന്നെയാണ് ബാധകം. നിങ്ങൾ ഒരു എലമെന്റ് ഇൻസ്‌പെക്റ്റ് (inspect) ചെയ്ത് അതിന്റെ ബാക്ക്ഗ്രൗണ്ട് കളർ മാറ്റുകയാണെങ്കിൽ, നിങ്ങൾ എഡിറ്റ് ചെയ്യുന്നത് നേരിട്ട് DOM ആണ്, അല്ലാതെ ഡിസ്കിലുള്ള ഫയലല്ല.

ഇത് പ്രധാനമാണ്, കാരണം നിങ്ങളുടെ എഡിറ്ററിൽ നിങ്ങൾ എഴുതുന്ന ഘടനയും ബ്രൗസർ ഉപയോഗിക്കുന്ന ഘടനയും വ്യത്യാസപ്പെടാം. സ്ക്രിപ്റ്റുകൾക്ക് പുതിയ നോഡുകൾ ചേർക്കാൻ കഴിയും. തേർഡ് പാർട്ടി വിഡ്ജറ്റുകൾക്ക് (third-party widgets) മാർക്കപ്പ് കൂട്ടിച്ചേർക്കാൻ കഴിയും. നിങ്ങൾ സ്റ്റൈലിംഗോ ഇവന്റ് ലിസനറുകളോ (event listeners) ഡീബഗ് ചെയ്യുമ്പോൾ, നിങ്ങളുടെ ഒറിജിനൽ സോഴ്സ് കോഡ് മാത്രമല്ല, റെൻഡർ ചെയ്ത DOM കൂടി പരിശോധിക്കേണ്ടതുണ്ട്.

ബ്രൗസറിൽ ഡാറ്റ എവിടെയാണ് സൂക്ഷിക്കുന്നത്?

HTTP ഡിസൈൻ പ്രകാരം സ്റ്റേറ്റ്‌ലെസ്സ് (stateless) ആണ്, അതായത് ഓരോ റിക്വസ്റ്റും സെർവറിലേക്ക് എത്തുന്നത് മുൻപത്തെ സന്ദർശനത്തെക്കുറിച്ച് യാതൊരു ഓർമ്മയുമില്ലാത്ത ഒരു അപരിചിതനെപ്പോലെയാണ്. ഡാറ്റ നിലനിർത്തുന്നതിനായി (persistence), വ്യത്യസ്ത നിയമങ്ങളും കാലാവധിയുമുള്ള മൂന്ന് പ്രധാന സ്റ്റോറേജ് സംവിധാനങ്ങൾ ബ്രൗസർ നിങ്ങൾക്ക് നൽകുന്നു.

LocalStorage ഉപയോക്താവ് ബ്രൗസർ പൂർണ്ണമായും അടച്ചാലും ചെറിയ അളവിലുള്ള ഡാറ്റ ലളിതമായ കീ-വാല്യൂ സ്ട്രിംഗുകളായി (key-value strings) സൂക്ഷിക്കുന്നു. ഡാർക്ക് മോഡ് ടോഗിൾ (dark-mode toggle) അല്ലെങ്കിൽ സൈഡ്ബാർ സ്റ്റേറ്റ് പോലുള്ള കാര്യങ്ങൾ സൂക്ഷിക്കാൻ ഇത് അനുയോജ്യമാണ്. സെൻസിറ്റീവ് ആയ വിവരങ്ങൾ (sensitive credentials) ഇതിൽ സൂക്ഷിക്കരുത്; കാരണം ഡൊമെയ്‌നിലുള്ള ഏത് സ്ക്രിപ്റ്റിനും ഇത് ലഭ്യമാണ്, കൂടാതെ ഇത് തനിയെ എപ്പോഴെങ്കിലും അവസാനിക്കുകയുമില്ല.

SessionStorage അതിന്റെ API ഉപയോഗത്തിൽ സമാനമാണെങ്കിലും പ്രവർത്തിക്കുന്നത് വ്യത്യസ്തമാണ്. ഇത് ഡാറ്റയെ ഒരു ടാബിലേക്ക് മാത്രമായി പരിമിതപ്പെടുത്തുന്നു. നിങ്ങളുടെ ഉപയോക്താവ് ഒരു ചെക്കൗട്ട് പ്രക്രിയ (checkout flow) തുടങ്ങുകയും പകുതി ഫോം പൂരിപ്പിച്ച ശേഷം അബദ്ധത്തിൽ പേജ് റിഫ്രഷ് ചെയ്യുകയും ചെയ്താൽ, ആ ഡാറ്റ സൂക്ഷിക്കാൻ SessionStorage സഹായിക്കും. ടാബ് അടയ്ക്കുന്ന നിമിഷം ഡാറ്റ ഇല്ലാതാകും. താൽക്കാലികമായ, ടാബ് അടിസ്ഥാനമാക്കിയുള്ള പ്രവർത്തനങ്ങൾക്ക് LocalStorage-നേക്കാൾ ഇത് മികച്ചതാണ്.

Cache ചിത്രങ്ങൾ, ഫോണ്ടുകൾ, സ്റ്റൈൽഷീറ്റുകൾ, സ്ക്രിപ്റ്റുകൾ തുടങ്ങിയ വലിയ അസറ്റുകൾ (assets) കൈകാര്യം ചെയ്യുന്നു. ഓരോ തവണ സന്ദർശിക്കുമ്പോഴും രണ്ട് മെഗാബൈറ്റ് വലിപ്പമുള്ള ഒരു ഇമേജ് ഡൗൺലോഡ് ചെയ്യുന്നതിന് പകരം, ബ്രൗസർ അതിന്റെ ഒരു കോപ്പി ലോക്കലായി സൂക്ഷിക്കുകയും സെർവറിൽ പുതിയ പതിപ്പ് ഉണ്ടോ എന്ന് പരിശോധിക്കുകയും ചെയ്യുന്നു. നിങ്ങളുടെ സൈറ്റ് എത്ര വേഗത്തിൽ പ്രവർത്തിക്കുന്നു എന്നത് നേരിട്ട് നിയന്ത്രിക്കുന്നത് ഇതാണ്.

ഡെവ് ടൂൾസ് (DevTools) ഒരു ദിനചര്യയാക്കി മാറ്റുക

മിക്ക ഡെവലപ്പർമാരും ഒരു വേരിയബിൾ ലോഗ് ചെയ്യാൻ ബ്രൗസർ കൺസോൾ തുറക്കുകയും അവിടെ നിൽക്കുകയും ചെയ്യുന്നു. അത് ഒരു വർക്ക്ഷോപ്പ് സ്വന്തമാക്കിയിട്ടും സ്ക്രൂഡ്രൈവർ മാത്രം ഉപയോഗിക്കുന്നത് പോലെയാണ്. ബ്രൗസർ DevTools എന്നത് ഒരു സംയോജിത ഡീബഗ്ഗിംഗ് എൻവയോൺമെന്റാണ് (integrated debugging environment), അതിന്റെ കുറഞ്ഞത് നാല് പാനലുകളെങ്കിലും ബോധപൂർവ്വം ഉപയോഗിക്കാൻ നിങ്ങൾ പഠിക്കണം.

Elements പാനൽ ലൈവ് DOM-ഉം അതിന്റെ കമ്പ്യൂട്ടഡ് സ്റ്റൈലുകളും (computed styles) കാണിക്കുന്നു. ഒരു ലേഔട്ട് തകരുമ്പോൾ, നോഡ് പരിശോധിക്കുകയും കാസ്കേഡ് (cascade) നോക്കുകയും ചെയ്യുക. നിങ്ങളുടെ സോഴ്സ് കോഡിൽ മാറ്റം വരുത്താതെ തന്നെ റിയൽ ടൈമിൽ പ്രോപ്പർട്ടികൾ ഓൺ ചെയ്യാനും ഓഫ് ചെയ്യാനും നിങ്ങൾക്ക് സാധിക്കും, ഇത് എഡിറ്ററിൽ ഊഹിച്ചു നടത്തുന്നതിനേക്കാൾ വേഗത്തിൽ സ്പെസിഫിസിറ്റി പ്രശ്നങ്ങൾ (specificity wars) കണ്ടെത്താൻ സഹായിക്കുന്നു.

Console സ്റ്റാക്ക് ട്രാസുകൾക്കൊപ്പം (stack traces) പിശകുകൾ കാണിക്കുന്നു, എന്നാൽ ഇതൊരു REPL കൂടിയാണ്. നിങ്ങൾക്ക് സെലക്ടറുകൾ ക്വറി ചെയ്യാനും, API റെസ്‌പോൺസുകൾ പരിശോധിക്കാനും, നിലവിലെ പേജ് സ്റ്റേറ്റിന് അനുസൃതമായി എക്സ്പ്രഷനുകൾ വിലയിരുത്താനും സാധിക്കും.

Network പാനൽ ഓരോ റിക്വസ്റ്റിന്റെയും ടൈംലൈൻ വെളിപ്പെടുത്തുന്നു. പരാജയപ്പെടുന്ന എൻഡ്പോയിന്റുകൾ കണ്ടെത്താനും, API ലാറ്റൻസി (latency) അളക്കാനും, ഏത് അസറ്റാണ് നിങ്ങളുടെ ഫസ്റ്റ് പെയിന്റിനെ (first paint) തടയുന്നതെന്ന് തിരിച്ചറിയാനും ഇതിലൂടെ സാധിക്കും. ആപ്പ് പതുക്കെയാണെന്ന് ഒരു ഉപയോക്താവ് പറഞ്ഞാൽ, സെർവർ ആണോ അതോ ഫ്രണ്ട്‌എൻഡ് ആണോ തടസ്സമുണ്ടാക്കുന്നത് എന്ന് തെളിയിക്കാൻ ഇത് സഹായിക്കുന്നു.

Application പാനൽ ഉപയോഗിച്ച് കുക്കികൾ (cookies), LocalStorage, SessionStorage എന്നിവ ഒരിടത്ത് തന്നെ പരിശോധിക്കാം. ഓതന്റിക്കേഷൻ പരിശോധിക്കുമ്പോഴോ സ്റ്റേറ്റ് ബഗ്ഗുകൾ ഡീബഗ് ചെയ്യുമ്പോഴോ, നിങ്ങളുടെ മുഴുവൻ ബ്രൗസിംഗ് ഹിസ്റ്ററിയും നശിപ്പിക്കാതെ തന്നെ ഒരു പുതിയ സന്ദർശകനെപ്പോലെ പ്രവർത്തിപ്പിക്കാൻ സ്റ്റോറേജ് മാനുവലായി ക്ലിയർ ചെയ്യാൻ ഇതിലൂടെ സാധിക്കും.

ഫയലുകളിലല്ല, Git സ്റ്റേജുകളിലാണ് ചിന്തിക്കേണ്ടത്

ഒരു ഫയൽ സേവ് ചെയ്യുന്നത് അത് വേർഷൻ ചെയ്യുന്നതിന് തുല്യമല്ല. മാറ്റങ്ങൾ സ്ഥിരമായി രേഖപ്പെടുത്തുന്നതിന് മുമ്പ് അവയെ മൂന്ന് വ്യത്യസ്ത ഘട്ടങ്ങളായി ചിന്തിക്കാൻ Git നിങ്ങളെ പ്രേരിപ്പിക്കുന്നു.

നിങ്ങളുടെ working tree എന്നത് അലങ്കോലമായ ഒരു ഡെസ്ക് പോലെയാണ്. നിങ്ങൾ ഫയലുകൾ എഡിറ്റ് ചെയ്യുന്നു, കാര്യങ്ങൾ തെറ്റിക്കുന്നു, പരീക്ഷണങ്ങൾ കമന്റ് ചെയ്യുന്നു, വേരിയബിളുകൾ മാറ്റുന്നു. ഇതുവരെ ഒന്നും ട്രാക്ക് ചെയ്യപ്പെട്ടിട്ടില്ല. ഇവിടെ ഒരു ഫയൽ ഡിലീറ്റ് ചെയ്യുകയും നിങ്ങൾ അത് കമിറ്റ് (commit) ചെയ്തിട്ടില്ലെങ്കിൽ, അത് എന്നെന്നേക്കുമായി നഷ്ടപ്പെടും.

ഇൻഡക്സ് (index) എന്നും വിളിക്കപ്പെടുന്ന staging area, ഏതാണ് പ്രസക്തമെന്ന് നിങ്ങൾ തീരുമാനിക്കുന്ന ഇടമാണ്. git add ഉപയോഗിച്ച്, തിരഞ്ഞെടുത്ത മാറ്റങ്ങളെ ഒരു പ്രീ-കമിറ്റ് ഹോൾഡിംഗ് സോണിലേക്ക് നിങ്ങൾ മാറ്റുന്നു. പരസ്പരബന്ധമില്ലാത്ത ജോലികൾ വേർതിരിക്കാനാണ് സ്റ്റേജിംഗ് ഏരിയ ഉപയോഗിക്കുന്നത്. നിങ്ങൾ ഒരു ലോഗിൻ ബഗ് പരിഹരിക്കുകയും ഒപ്പം ഒരു യൂട്ടിലിറ്റി ഫംഗ്ഷൻ റീഫാക്ടർ ചെയ്യുകയും ചെയ്തിട്ടുണ്ടെങ്കിൽ, അവയെ സ്വതന്ത്രമായി സ്റ്റേജ് ചെയ്യാനും അവ്യക്തമായ ഒരു സന്ദേശത്തിന് പകരം രണ്ട് വ്യക്തമായ കമിറ്റ് മെസ്സേജുകൾ എഴുതാനും നിങ്ങൾക്ക് സാധിക്കും.

ഒടുവിൽ, local repository യെ യഥാർത്ഥ ഹിസ്റ്ററി സൂക്ഷിക്കുന്നു. git commit പ്രവർത്തിപ്പിക്കുന്നത് നിങ്ങളുടെ സ്റ്റേജ് ചെയ്ത മാറ്റങ്ങളെ ഒരു യുണീക് ഹാഷ് (unique hash), ഒരു മെസ്സേജ്, ഒരു ടൈംസ്റ്റാമ്പ് എന്നിവയോടെ ഒരു സ്നാപ്പ്ഷറ്റായി ലോക്ക് ചെയ്യുന്നു. നാളെ നിങ്ങൾ ആ ഫയൽ നശിപ്പിച്ചാലും ആ സ്നാപ്പ്ഷറ്റ് വീണ്ടെടുക്കാൻ സാധിക്കും. കമിറ്റുകൾ എളുപ്പമുള്ളതാണ്, അതിനാൽ അവ ചെറുതും യുക്തിസഹവുമാക്കുക. വെള്ളിയാഴ്ച ഉച്ചയ്ക്ക് ശേഷം എഴുതിയ വലിയൊരു കോഡ് ഡംപ് ചെയ്യുന്നതിനേക്കാൾ ഉപകാരപ്രദമാണ് ചെറിയതും വായിക്കാവുന്നതുമായ കമിറ്റുകളുടെ ചരിത്രം.

യഥാർത്ഥ പാഠം

ഈ വിഷയങ്ങൾ വെറും തിയററ്റിക്കൽ കമ്പ്യൂട്ടർ സയൻസ് അല്ല. അവ പ്രായോഗികമായ കൺട്രോൾ സിസ്റ്റങ്ങളാണ്. ഒരു URL എങ്ങനെ വിഭജിക്കപ്പെടുന്നു എന്ന് നിങ്ങൾ മനസ്സിലാക്കുമ്പോൾ, നിങ്ങൾക്ക് ലോഗുകൾ മികച്ച രീതിയിൽ വായിക്കാൻ കഴിയും. DOM-നെ ഒരു സ്റ്റാറ്റിക് മാർക്ക്അപ്പിന് പകരം ഒരു ലിവിംഗ് റൺടൈം (living runtime) ആയി കാണുമ്പോൾ, നിങ്ങളുടെ JavaScript കൂടുതൽ പ്രവചനാതീതമല്ലാതാകുന്നു (predictable). LocalStorage-ഉം SessionStorage-ഉം ശരിയായി ഉപയോഗിക്കുമ്പോൾ, ടാബുകൾക്കിടയിൽ സ്റ്റേറ്റ് ചോരുന്നത് (leaking state) നിങ്ങൾ ഒഴിവാക്കുന്നു. ഒരു ലക്ഷ്യത്തോടെ DevTools തുറക്കുമ്പോൾ, ഒരു ബട്ടൺ നീലയ്ക്ക് പകരം പച്ചയാകുന്നത് എന്തുകൊണ്ടാണെന്ന് ഊഹിച്ചു നടക്കുന്നത് നിങ്ങൾ നിർത്തുന്നു. Git-ന്റെ മൂന്ന് ഘട്ടങ്ങളുള്ള വർക്ക്ഫ്ലോ നിങ്ങൾ ശരിയായി പിന്തുടരുമ്പോൾ, 'undo' ബട്ടണിനെക്കുറിച്ചുള്ള പേടി നിങ്ങൾക്ക് ഇല്ലാതാകുന്നു.

എല്ലാ എഡ്ജ് കേസുകളും (edge cases) ഒരേസമയം മനഃപാഠമാക്കാൻ ശ്രമിക്കരുത്. പകരം, ഒരു ശീലം വളർത്തിയെടുക്കുക: ഒരു ലേഔട്ട് തകരുമ്പോൾ പത്ത് മിനിറ്റ് DOM പരിശോധിക്കുക, ബാക്കെൻഡിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് Network ടാബ് പരിശോധിക്കുക, കൂടാതെ ഓരോ തവണയും ഒരു വ്യക്തമായ ചിന്ത പൂർത്തിയാക്കുമ്പോൾ കമിറ്റ് ചെയ്യുക. നിങ്ങളുടെ ആപ്ലിക്കേഷനുകളുടെ വിശ്വാസ്യത തനിയെ വന്നുകൊള്ളും.