நீங்கள் உங்கள் நாட்களைக் குறியீடு (code) எழுதுவதில் செலவிடுகிறீர்கள் என்றால், நீங்கள் இரண்டு சூழல்களுக்குள் உங்கள் நேரத்தைச் செலவிடுகிறீர்கள்: உங்கள் வேலை உண்மையில் இயங்கும் பிரவுசர் விண்டோ (browser window), மற்றும் நீங்கள் அங்கு சென்றடைய எடுத்த ஒவ்வொரு முடிவையும் நினைவில் வைத்திருக்கும் Git ரெபாசிட்டரி (Git repository). ஒன்று பொதுமக்களுக்குத் தெரியும் மற்றும் கணிக்க முடியாதது, மற்றொன்று தனிப்பட்டது மற்றும் துல்லியமானது. இவை இரண்டையும் புரிந்துகொள்வது கட்டாயமானது. பிரவுசரின் உள் இயந்திரவியல் மற்றும் Git-ன் ஸ்டேஜிங் லாஜிக் (staging logic) ஆகியவற்றில் புலமை பெறுவது, யூகத்தின் அடிப்படையில் செயல்படும் டெவலப்பர்களுக்கும், ஏதோ ஒன்று ஏன் உடைந்தது மற்றும் எப்போது மாறியது என்பதைத் துல்லியமாகத் தெரிந்த டெவலப்பர்களுக்கும் இடையிலான வேறுபாடாகும்.
URL கட்டமைப்பு
ஒவ்வொரு இணையதளப் பயணமும் எளிமையானதாகத் தோன்றும் ஆனால் துல்லியமான வழிமுறைகளைக் கொண்ட ஒரு எழுத்துத் தொடருடன் தொடங்குகிறது. https://shop.example.com:443/products/id/42?sort=price#reviews போன்ற ஒரு URL உண்மையில் தனித்தனி வழிமுறைகளின் தொகுப்பாகும்.
protocol முன்னால் அமர்ந்து உரையாடலின் விதிகளைத் தீர்மானிக்கிறது. நீங்கள் https:// என்பதைக் காணும்போது, எதையும் அனுப்புவதற்கு முன் இணைப்பை என்க்ரிப்ட் (encrypt) செய்ய வேண்டும் என்பதை பிரவுசர் அறிந்து கொள்கிறது. domain (shop.example.com) என்பது சர்வரின் (server) உண்மையான நெட்வொர்க் முகவரிக்கான மனிதன் வாசிக்கக்கூடிய பெயராகும். உங்கள் கணினி எங்கே தொடர்பு கொள்ள வேண்டும் என்பதைத் தெரிந்துகொள்ள இது DNS மூலம் தீர்க்கப்படுகிறது (resolved). port (:443) என்பது அந்த சர்வரில் உள்ள ஒரு குறிப்பிட்ட நுழைவாயில் ஆகும். பிரவுசர்கள் HTTPS-க்கு 443 மற்றும் HTTP-க்கு 80 என்று கருதுவதால் இது பெரும்பாலும் கண்ணுக்குத் தெரிவதில்லை, ஆனால் இயந்திரவியலில் இது எப்போதும் அங்கேயே இருக்கும். path (/products/id/42) நீங்கள் எந்த வளத்தை (resource) விரும்புகிறீர்கள் என்பதை ஃபோல்டர்களைப் போல வரிசைப்படுத்தி சர்வருக்குத் தெரிவிக்கிறது. query string (?sort=price) டைனமிக் தரவுகளை (dynamic data) key-value ஜோடிகளாக வழங்குகிறது, இது ஃபில்டர்கள் (filters), தேடல் சொற்கள் அல்லது பக்கப் பிரிப்பிற்கு (pagination) ஏற்றது. இறுதியாக, fragment (#reviews) பக்கத்தில் உள்ள ஒரு குறிப்பிட்ட element ID-ஐக் குறிக்கிறது. இது சர்வரைச் சென்றடைவதில்லை; பக்கம் வந்தடைந்த பிறகு பிரவுசர் இதை முழுமையாக கிளையன்ட் பக்கத்தில் (client side) கையாள்கிறது.
fragment-ஐ இறுதியில் வைத்திருங்கள். அதை query string-க்கு முன்னால் நகர்த்தினால், இணைப்பு உடைந்துவிடும், ஏனெனில் hash-க்கு அடுத்து வரும் அனைத்தும் கிளையன்ட்-சைடு சூழலாகவே (client-side context) கருதப்படும், சர்வருக்கான வழிமுறைகளாக அல்ல.
DOM: உங்கள் பக்கத்தின் நேரடி நரம்பு மண்டலம்
இணையம் வழியாக வரும் HTML வெறும் உரை (text) மட்டுமே. பிரவுசர் அந்த உரையைப் படித்து, nodes எனப்படும் ஆப்ஜெக்ட்களின் நேரடி, மரம் போன்ற அமைப்பைக் கொண்ட Document Object Model-ஐ உருவாக்குகிறது. Element டேக்-கள் element nodes ஆகின்றன. டேக்குகளுக்கு இடையிலான உரை text nodes ஆகிறது. அட்ரிபியூட்கள் (attributes) மற்றும் கமெண்ட்டுகள் (comments) கூட அவற்றிற்கெனத் தனித்தனி நோட் வகைகளைக் கொண்டுள்ளன. இந்த மரம் ஒரு நிலையான வரைபடம் அல்ல. இது JavaScript மூலம் உடனுக்குடன் படிக்கவும் மாற்றவும் கூடிய ஒரு நேரடி தரவு அமைப்பாகும் (live data structure).
உங்கள் ஸ்கிரிப்ட் document.getElementById இயக்கும்போது அல்லது ஒரு className-ஐ மாற்றும்போது, நீங்கள் இந்த மரத்திற்குள் சென்று அதை மாற்றியமைக்கிறீர்கள் (mutate). பிரவுசர் அதை உணர்ந்து, சர்வரிடம் புதிய பக்கத்தைக் கேட்காமல் திரையை மீண்டும் வரைகிறது (repaint). இந்தத் திறமையே நவீன வெப் ஆப்ஸ்களை (web apps) சாத்தியமாக்குகிறது, ஆனால் அதற்கு ஒரு விலை உண்டு. நீங்கள் ஒவ்வொரு முறையும் DOM-ஐத் தொடும்போது, பிரவுசர் லேஅவுட் (layout) மற்றும் ஸ்டைல்களை (styles) மீண்டும் கணக்கிடலாம். நூற்றுக்கணக்கான உருப்படிகளுடன் ஒரு லூப்பிற்குள் (loop) இதைச் செய்தால், உங்கள் பிரேம் ரேட் (frame rate) குறைந்துவிடும். நீங்கள் ஒரு நீண்ட பட்டியலைச் சேர்க்க விரும்பினால், முதலில் நினைவகத்தில் (memory) ஒரு DocumentFragment-ஐ உருவாக்கி, பின்னர் அதை ஒரே முறையில் இணைக்கவும். உங்கள் ரீட் (read) மற்றும் ரைட் (write) செயல்பாடுகளைத் தொகுப்பாக (batch)ச் செய்யுங்கள். DOM மீள்தன்மை கொண்டது, ஆனால் அது இலவசமானது அல்ல.
பிரவுசர் ஸ்டோரேஜ்: மூன்று கருவிகள், மூன்று பணிகள்
நவீன பிரவுசர்கள் பயனரின் கணினியிலேயே தரவைச் சேமிக்க அனுமதிக்கின்றன, மேலும் சரியான முறையைத் தேர்ந்தெடுப்பது முக்கியம், ஏனெனில் ஒவ்வொன்றும் வெவ்வேறு ஆயுட்காலம் மற்றும் கொள்ளளவுக்காக உருவாக்கப்பட்டுள்ளது.
LocalStorage மிகவும் எளிமையானது. உங்கள் குறியீடு அல்லது பயனர் அதை நீக்கும் வரை இது சிறிய அளவிலான ஸ்ட்ரிங் தரவை (string data) நிரந்தரமாகச் சேமிக்கிறது. ஒரு சிறந்த உதாரணம் டார்க்-மோட் (dark-mode) விருப்பம். யாராவது ஸ்விட்சைத் திருப்பும்போது, LocalStorage-இல் "theme": "dark" என்று எழுதுங்கள். அடுத்த முறை வரும்போது, அதை மீண்டும் படித்து முதல் பெயிண்டிற்கு (first paint) முன்பே அந்த கிளாஸை (class)ச் செயல்படுத்தவும். இது synchronous மற்றும் origin-க்கு உட்பட்டது, இது எளிதானது என்றாலும், இதில் முக்கியமான டோக்கன்களை (sensitive tokens) ஒருபோதும் சேமிக்கக் கூடாது என்பதும் இதன் பொருள். உங்கள் பக்கத்தில் இயங்கும் எந்த ஸ்கிரிப்ட்டும் இதைப் படிக்க முடியும்.
SessionStorage அதே key-value API-ஐப் பயன்படுத்துகிறது, ஆனால் அதன் ஆயுட்காலம் பிரவுசர் டேப்-உடன் (browser tab) பிணைக்கப்பட்டுள்ளது. இது பக்கத்தை ரீஃப்ரெஷ் (refresh) செய்தாலும் அழியாது, எனவே தற்காலிக ஃபார்ம் முன்னேற்றத்திற்கு (form progress) இது சரியானது. ஒரு பயனர் நீண்ட ஒரு சர்வேயை நிரப்பும்போது, தவறுதலாக ரீலோட் (reload) செய்துவிட்டு, நீங்கள் SessionStorage-இல் சேமித்து வைத்ததால் அவர்களின் பதில்களைத் தொடர்ந்து பார்ப்பதாகக் கற்பனை செய்து பாருங்கள். அவர்கள் டேப்பை மூடிவிட்டால், தரவு தானாகவே அழிந்துவிடும்.
Cache API ஒரு மாறுபட்ட அளவில் செயல்படுகிறது. இது கோரிக்கை (request) மற்றும் பதில் (response) ஜோடிகளைச் சேமிக்கிறது, பொதுவாக படங்கள், எழுத்துருக்கள் (fonts) மற்றும் ஸ்கிரிப்ட் பண்டில்கள் (script bundles) போன்ற பெரிய நிலையான சொத்துக்களை (static assets) சேமிக்க service workers மூலம் பயன்படுத்தப்படுகிறது. ஒவ்வொரு முறை பார்வையிடும் போதும் அதே hero image அல்லது React bundle-ஐ நெட்வொர்க் மூலம் பெறுவதற்குப் பதிலாக, உங்கள் ஆப் அதை நேரடியாக disk cache-லிருந்து வழங்க முடியும். இதன் மூலமே ஆஃப்லைனில் இயங்கக்கூடிய தளங்கள் மீண்டும் பார்வையிடும்போது உடனடியாகத் திறக்கின்றன. இது மற்ற இரண்டைப் போல ஒரு பொதுவான key-value store அல்ல; இது HTTP responses-க்காகவே பிரத்யேகமாக உருவாக்கப்பட்டது.
ஒரு முக்கியமான விதி: authentication tokens அல்லது தனிப்பட்ட அடையாளங்களை (personal identifiers) ஒருபோதும் LocalStorage-இல் சேமிக்காதீர்கள். XSS தாக்குதல்கள் அவற்றை மில்லி விநாடிகளில் திருடிவிடக்கூடும். முக்கியமான தகவல்களுக்கு HttpOnly, Secure, SameSite cookies-களைப் பயன்படுத்துங்கள், மேலும் Application tab-இல் அவற்றைச் சரிபார்த்து, அந்த flags சரியாக அமைக்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.
Browser DevTools: யூகிக்க வேண்டாம், வாசிக்கத் தொடங்குங்கள்
DevTools panel என்பது வெறும் சிவப்பு நிற console பிழைகளைத் திருத்துவதற்காக மட்டுமல்ல. பிரவுசருக்குள் நடக்கும் அனைத்தையும் கண்டறியும் உங்கள் கண்டறியும் ஆய்வகம் (diagnostic lab) இதுவாகும்.
Elements panel-இல், நீங்கள் DOM tree-ன் மீது மவுஸை நகர்த்தும்போது (hover), பக்கத்தில் உள்ள nodes நிகழ்நேரத்தில் (real time) ஹைலைட் ஆவதைக் காணலாம். உங்கள் மூலக் குறியீட்டை (source code) தொடாமலேயே, ஒரு margin அல்லது நிறத்தைச் சோதிக்க Styles pane-இல் நேரடியாக CSS மதிப்புகளை மாற்றியமைக்கலாம். Console என்பது உங்கள் குறிப்பேடு (scratchpad) போன்றது. ஆப்ஜெக்ட்களை லாக் (log) செய்யவும், regex-ஐச் சோதிக்கவும் அல்லது தற்போதைய பக்க நிலைக்கு (page state) ஏற்ப செயல்பாடுகளை (functions) நேரடியாக அழைக்கவும் இதைப் பயன்படுத்தலாம். ஒரு variable சரியாகச் செயல்படவில்லை என்றால், அதன் பெயரைத் தட்டச்சு செய்து நேரடியாகச் சோதிக்கலாம்.
Network tab செயல்திறன் (performance) பற்றிய உண்மையை வெளிப்படுத்துகிறது. அந்த மெதுவான பக்கம் உங்கள் JavaScript-ஆல் இருக்கலாம் என்று நினைக்க வேண்டாம். அது பதிலளிக்க நான்கு விநாடிகள் எடுத்துக்கொள்ளும் ஒரு மூன்றாம் தரப்பு எழுத்துருவாகவோ (third-party font), அல்லது நீங்கள் சுருக்காத (compress செய்யாத) இரண்டு மெகாபைட் JSON payload-ஐத் தரும் ஒரு API endpoint-ஆகவோ இருக்கலாம். ஒவ்வொரு கோரிக்கையின் (request) முழு வாழ்க்கைச் சுழற்சியையும் நீங்கள் கண்காணிக்கலாம், உங்கள் சொந்த API அழைப்புகளைப் பார்க்க Fetch/XHR மூலம் வடிகட்டலாம் (filter), மேலும் caching directives சரியாகப் பின்பற்றப்படுகின்றனவா என்பதைப் பார்க்க headers-ஐச் சோதிக்கலாம். அதே நேரத்தில், Application tab உங்கள் சேமிப்பகத்தை (storage) தணிக்கை செய்ய அனுமதிக்கிறது. LocalStorage key-value ஜோடிகளைப் பார்க்கவும், தனிப்பட்ட cookies மற்றும் அவற்றின் flags-களைச் சோதிக்கவும், மேலும் உங்கள் service worker உண்மையில் பதிவு செய்யப்பட்டு நீங்கள் எதிர்பார்ப்பதைச் சேமிக்கிறதா என்பதை உறுதிப்படுத்தவும் இது உதவும்.
Git Workflow: மூன்று தொகுதிகள் (The Three Buckets)
Git என்பது ஒரு backup மென்பொருள் அல்ல. இது வரலாற்றைப் பராமரிப்பதற்கான (curating history) ஒரு கருவி. அவ்வாறு சிந்திப்பது நீங்கள் அதைப் பயன்படுத்தும் முறையை மாற்றும். Git உங்கள் திட்டத்தை மூன்று தனித்துவமான பகுதிகள் மூலம் நிர்வகிக்கிறது.
working tree என்பது உங்கள் கலைந்து கிடக்கும் மேசை போன்றது. இங்கே நீங்கள் கோப்புகளைத் திருத்தலாம், கோப்புறைகளை (folders) நீக்கலாம் மற்றும் சோதனைகளைச் செய்யலாம். இன்னும் எதுவும் பாதுகாப்பானது அல்ல. staging area, அல்லது index என்பது அடுத்த snapshot-இல் எவை இடம்பெற வேண்டும் என்பதை நீங்கள் தேர்ந்தெடுக்கும் இடமாகும். ஒரு கோப்பில் git add என்று இயக்குவது அதை working tree-லிருந்து staging-க்கு மாற்றுகிறது. இது உங்களுக்குத் துல்லியத்தன்மையைத் தருகிறது. நீங்கள் பத்து கோப்புகளை மாற்றியமைத்துவிட்டு, அவற்றில் மூன்றை மட்டும் staging செய்து, ஒரு மாற்றத்தை மட்டும் துல்லியமாக விவரிக்கும் சுத்தமான, தர்க்கரீதியான (logical) snapshot-ஐ commit செய்யலாம். நீங்கள் git commit என்று இயக்கும்போது, local repository அந்த snapshot-ஐப் பெறுகிறது. அந்த நேரத்தில், Git உங்கள் செய்தியுடன் (message) சேர்த்து staging செய்யப்பட்ட கோப்புகளின் முழு நிலையைச் சேமித்து, நீங்கள் பின்னர் திரும்பப் பெறக்கூடிய ஒரு நிரந்தரக் குறிப்புப் புள்ளியை (checkpoint) உருவாக்குகிறது.
எதையும் stage செய்வதற்கு முன், git status என்று இயக்கவும். நீங்கள் மறந்திருக்கக்கூடிய track செய்யப்படாத கோப்புகள் (untracked files) மற்றும் மாற்றப்பட்ட கோப்புகளை இது உங்களுக்குக் காட்டும். இந்தச் சரிபார்ப்பைத் தவிர்த்தால், தற்காலிக build artifacts, log கோப்புகள் அல்லது environment கோப்புகள் commits-க்குள் கசிந்துவிடக்கூடும். ஒரு சிறந்த .gitignore கோப்பு உதவும், ஆனால் git status என்பது உங்கள் இறுதிப் பரிசோதனை (pre-flight inspection) ஆகும்.
தவறுகள் வரலாறாக மாறுவதற்கு முன்பே அவற்றைச் சரிசெய்ய staging உதவுகிறது. ஒரு கோப்பைத் தவறாகச் சேர்த்துவிட்டால், git restore --staged மூலம் அதை unstage செய்யலாம். உங்கள் commit செய்தி தெளிவற்றதாக இருந்தால் அதைத் திருத்தி எழுதலாம். உங்கள் commits வெறும் மதிய உணவிற்குப் பிறகு நீங்கள் செய்த ஒவ்வொரு தட்டச்சுப் பதிவுகளின் தொகுப்பாக இல்லாமல், ஒரு தெளிவான கதையைச் சொல்வதற்காகவே staging area உள்ளது.
ஒருங்கிணைத்தல் (Bringing It Together)
பிரவுசர் மற்றும் Git ஆகிய இந்த இரண்டு களங்களும் உங்கள் பணிப்பாய்வின் (workflow) ஒவ்வொரு மணிநேரத்தையும் வடிவமைக்கின்றன. பிரவுசரில், கோரிக்கைகள் (requests) எவ்வாறு தீர்க்கப்படுகின்றன, உங்கள் ஸ்கிரிப்ட்களுக்கு DOM எவ்வாறு எதிர்வினையாற்றுகிறது மற்றும் கிளையண்டில் தரவு எங்குள்ளது என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். ரகசியத் தகவல்களுக்கு LocalStorage-ஐத் தவறாகப் பயன்படுத்துவதோ அல்லது தொகுக்கப்படாத (unbatched) புதுப்பிப்புகளால் DOM-ஐத் தாக்குவதோ (hammering) பலவீனமான மற்றும் மெதுவான செயலிகளை உருவாக்கும். உங்கள் டெர்மினலில், Git-ஐ ஒரு 'save' பொத்தானைப் போலக் கையாள்வது, உங்கள் எதிர்காலத் தேவைகளுக்கே படிக்க முடியாத ஒரு வரலாற்றை உருவாக்கும். staging area-வைத் திட்டமிட்டுப் பயன்படுத்துங்கள். உங்கள் status-ஐச் சரிபார்க்கவும். 'என்ன நடந்தது' என்பதை மட்டும் சொல்லாமல், 'ஏன் நடந்தது' என்பதை விளக்கும் வகையில் commits-களை எழுதுங்கள்.
இந்த இரண்டு உலகங்களையும் இணைக்கும் பழக்கம் 'பரிசோதனை' (inspection) ஆகும். API-ஐக் குற்றம் சாட்டுவதற்கு முன் URL-களை ஆராயுங்கள். ஒரு framework-ஐச் சேர்ப்பதற்கு முன் DOM-ஐப் பகுப்பாய்வு (profile) செய்யுங்கள். பெரிய சர்வரை வாங்குவதற்கு முன் Network tab-ஐப் படியுங்கள். ஒரு தவறை உறுதிப்படுத்துவதற்கு முன் git status-ஐ மறுபரிசீலனை செய்யுங்கள். கருவிகள் ஏற்கனவே உங்கள் திரையில் திறந்திருக்கின்றன. அவற்றை நேர்மையாகப் படிக்கக் கற்றுக்கொள்வதே உங்கள் வேலை.