ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ ਦਿਨ ਕੋਡ ਲਿਖਣ ਵਿੱਚ ਬਿਤਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਪਣੇ ਘੰਟੇ ਦੋ ਮਾਹੌਲਾਂ (environments) ਦੇ ਅੰਦਰ ਬਿਤਾਉਂਦੇ ਹੋ: ਬ੍ਰਾਊਜ਼ਰ ਵਿੰਡੋ ਜਿੱਥੇ ਤੁਹਾਡਾ ਕੰਮ ਅਸਲ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਅਤੇ Git ਰਿਪੋਜ਼ਟਰੀ ਜੋ ਉੱਥੇ ਪਹੁੰਚਣ ਲਈ ਤੁਹਾਡੇ ਦੁਆਰਾ ਲਏ ਗਏ ਹਰ ਫੈਸਲੇ ਨੂੰ ਯਾਦ ਰੱਖਦੀ ਹੈ। ਇੱਕ ਜਨਤਕ-ਮੁਖੀ (public-facing) ਅਤੇ ਅਨਿਸ਼ਚਿਤ ਹੈ, ਦੂਜਾ ਨਿੱਜੀ ਅਤੇ ਸਖ਼ਤ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਸਮਝਣਾ ਲਾਜ਼ਮੀ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਅੰਦਰੂਨੀ ਮਸ਼ੀਨਰੀ ਅਤੇ Git ਦੇ staging logic ਵਿੱਚ ਮੁਹਾਰਤ ਹਾਸਲ ਕਰਨਾ ਉਨ੍ਹਾਂ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਦੂਜਿਆਂ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਅੰਦਾਜ਼ੇ ਲਗਾਉਂਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਤੋਂ ਜੋ ਬਿਲਕੁਲ ਜਾਣਦੇ ਹਨ ਕਿ ਕੁਝ ਕਿਉਂ ਟੁੱਟਿਆ ਅਤੇ ਕਦੋਂ ਬਦਲਿਆ।

URL ਦੀ ਬਣਤਰ (URL Anatomy)

ਕਿਸੇ ਵੈੱਬਸਾਈਟ 'ਤੇ ਹਰ ਯਾਤਰਾ ਅੱਖਰਾਂ ਦੀ ਇੱਕ ਲੜੀ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜੋ ਦੇਖਣ ਵਿੱਚ ਸਧਾਰਨ ਲੱਗਦੀ ਹੈ ਪਰ ਸਹੀ ਨਿਰਦੇਸ਼ ਦਿੰਦੀ ਹੈ। https://shop.example.com:443/products/id/42?sort=price#reviews ਵਰਗਾ URL ਅਸਲ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਨਿਰਦੇਸ਼ਾਂ ਦਾ ਇੱਕ ਸਮੂਹ (stack) ਹੈ।

protocol ਸਭ ਤੋਂ ਅੱਗੇ ਹੁੰਦਾ ਹੈ ਅਤੇ ਗੱਲਬਾਤ ਦੇ ਨਿਯਮ ਤੈਅ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ https:// ਦੇਖਦੇ ਹੋ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਜਾਣਦਾ ਹੈ ਕਿ ਕੁਝ ਵੀ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸਨੂੰ ਕਨੈਕਸ਼ਨ ਨੂੰ ਐਨਕ੍ਰਿਪਟ (encrypt) ਕਰਨ ਦੀ ਲੋੜ ਹੈ। domain (shop.example.com) ਸਰਵਰ ਦੇ ਅਸਲ ਨੈੱਟਵਰਕ ਐਡਰੈੱਸ ਲਈ ਮਨੁੱਖੀ-ਪੜ੍ਹਨਯੋਗ ਨਾਮ ਹੈ। ਇਸਨੂੰ DNS ਰਾਹੀਂ ਹੱਲ (resolve) ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਕੰਪਿਊਟਰ ਜਾਣ ਸਕੇ ਕਿ ਕਿੱਥੇ ਜਾਣਾ ਹੈ। port (:443) ਉਸ ਸਰਵਰ 'ਤੇ ਇੱਕ ਖਾਸ ਦਰਵਾਜ਼ਾ ਹੈ। ਇਹ ਅਕਸਰ ਅਦਿੱਖ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ HTTPS ਲਈ 443 ਅਤੇ HTTP ਲਈ 80 ਮੰਨ ਲੈਂਦੇ ਹਨ, ਪਰ ਮਕੈਨਿਕਸ ਵਿੱਚ ਇਹ ਹਮੇਸ਼ਾ ਉੱਥੇ ਹੁੰਦਾ ਹੈ। path (/products/id/42) ਸਰਵਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਸਰੋਤ (resource) ਨੂੰ ਚਾਹੁੰਦੇ ਹੋ, ਜੋ ਫੋਲਡਰਾਂ ਵਾਂਗ ਸੰਗਠਿਤ ਹੁੰਦਾ ਹੈ। query string (?sort=price) ਡਾਇਨਾਮਿਕ ਡੇਟਾ ਨੂੰ key-value ਜੋੜਾਂ ਵਜੋਂ ਸੌਂਪਦਾ ਹੈ, ਜੋ ਫਿਲਟਰ, ਸਰਚ ਟਰਮਾਂ ਜਾਂ ਪੇਜਨੇਸ਼ਨ (pagination) ਲਈ ਸੰਪੂਰਨ ਹੈ। ਅੰਤ ਵਿੱਚ, fragment (#reviews) ਪੇਜ 'ਤੇ ਇੱਕ ਖਾਸ element ID ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਇਹ ਕਦੇ ਵੀ ਸਰਵਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ; ਬ੍ਰਾਊਜ਼ਰ ਪੇਜ ਆਉਣ ਤੋਂ ਬਾਅਦ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਲਾਇੰਟ-ਸਾਈਡ 'ਤੇ ਇਸਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।

ਫਰੈਗਮੈਂਟ (fragment) ਨੂੰ ਅੰਤ ਵਿੱਚ ਰੱਖੋ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ query string ਤੋਂ ਪਹਿਲਾਂ ਲਿਆਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਲਿੰਕ ਨੂੰ ਤੋੜ ਦਿਓਗੇ ਕਿਉਂਕਿ ਹੈਸ਼ (#) ਤੋਂ ਬਾਅਦ ਦੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਰਵਰ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਬਜਾਏ ਕਲਾਇੰਟ-ਸਾਈਡ ਸੰਦਰਭ (context) ਵਜੋਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।

DOM: ਤੁਹਾਡੇ ਪੇਜ ਦਾ ਜੀਵਤ ਨਰਵਸ ਸਿਸਟਮ (Nervous System)

ਵਾਇਰ ਰਾਹੀਂ ਆਉਣ ਵਾਲਾ HTML ਸਿਰਫ਼ ਟੈਕਸਟ ਹੁੰਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਉਸ ਟੈਕਸਟ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ Document Object Model ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਕਿ nodes ਕੀਹਾ ਜਾਣ ਵਾਲੇ ਆਬਜੈਕਟਾਂ ਦਾ ਇੱਕ ਜੀਵਤ, ਰੁੱਖ ਦੇ ਆਕਾਰ ਦਾ ਨਕਸ਼ਾ ਹੈ। Element tags, element nodes ਬਣ ਜਾਂਦੇ ਹਨ। Tags ਦੇ ਵਿਚਕਾਰ ਵਾਲਾ ਟੈਕਸਟ text nodes ਬਣ ਜਾਂਦਾ ਹੈ। ਇੱਥੋਂ ਤੱਕ ਕਿ attributes ਅਤੇ comments ਦੇ ਵੀ ਆਪਣੇ ਨੋਡ ਟਾਈਪ ਹੁੰਦੇ ਹਨ। ਇਹ ਰੁੱਖ ਕੋਈ ਸਥਿਰ (static) ਡਾਇਗ੍ਰਾਮ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਜੀਵਤ ਡੇਟਾ ਸਟ੍ਰਕਚਰ ਹੈ ਜਿਸ ਨੂੰ JavaScript ਤੁਰੰਤ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਸਕਦੀ ਹੈ।

ਜਦੋਂ ਤੁਹਾਡਾ ਸਕ੍ਰਿਪਟ document.getElementById ਚਲਾਉਂਦਾ ਹੈ ਜਾਂ className ਨੂੰ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਰੁੱਖ ਵਿੱਚ ਜਾ ਕੇ ਇਸਨੂੰ ਬਦਲ (mutate) ਰਹੇ ਹੁੰਦੇ ਹੋ। ਬ੍ਰਾਊਜ਼ਰ ਇਸਨੂੰ ਨੋਟ ਕਰਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਤੋਂ ਨਵਾਂ ਪੇਜ ਮੰਗੇ ਬਿਨਾਂ ਸਕ੍ਰੀਨ ਨੂੰ ਦੁਬਾਰਾ ਪੇਂਟ (repaint) ਕਰਦਾ ਹੈ। ਇਹੀ ਉਹ ਸ਼ਕਤੀ ਹੈ ਜੋ ਆਧੁਨਿਕ ਵੈੱਬ ਐਪਸ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦੀ ਹੈ, ਪਰ ਇਸਦੀ ਇੱਕ ਕੀਮਤ ਵੀ ਹੈ। ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ DOM ਨੂੰ ਛੂਹਦੇ ਹੋ, ਬ੍ਰਾਊਜ਼ਰ ਲੇਆਉਟ (layout) ਅਤੇ ਸਟਾਈਲ ਦੀ ਮੁੜ-ਗਣਨਾ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਸੈਂਕੜੇ ਆਈਟਮਾਂ ਦੇ ਨਾਲ ਇੱਕ ਤੰਗ ਲੂਪ (tight loop) ਦੇ ਅੰਦਰ ਅਜਿਹਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡਾ ਫਰੇਮ ਰੇਟ (frame rate) ਡਿੱਗ ਜਾਵੇਗਾ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਇੱਕ ਲੰਬੀ ਸੂਚੀ (list) ਇਨਸਰਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਮੈਮਰੀ ਵਿੱਚ ਇੱਕ DocumentFragment ਬਣਾਓ, ਫਿਰ ਉਸਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਹੀ ਜੋੜੋ (append)। ਆਪਣੇ ਪੜ੍ਹਨ (reads) ਅਤੇ ਲਿਖਣ (writes) ਦੇ ਕੰਮਾਂ ਨੂੰ ਬੈਚ (batch) ਵਿੱਚ ਕਰੋ। DOM ਲਚਕਦਾਰ ਹੈ, ਪਰ ਇਹ ਮੁਫ਼ਤ ਨਹੀਂ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰ ਸਟੋਰੇਜ: ਤਿੰਨ ਟੂਲ, ਤਿੰਨ ਕੰਮ

ਆਧੁਨਿਕ ਬ੍ਰਾਊਜ਼ਰ ਤੁਹਾਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰ ਦੀ ਮਸ਼ੀਨ 'ਤੇ ਡੇਟਾ ਸਟੋਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਸਹੀ ਵਿਧੀ ਦੀ ਚੋਣ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਵੱਖਰੇ ਜੀਵਨ ਕਾਲ (lifespan) ਅਤੇ ਸਮਰੱਥਾ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ।

LocalStorage ਸਭ ਤੋਂ ਸਧਾਰਨ ਹੈ। ਇਹ ਛੋਟੀ ਮਾਤਰਾ ਵਿੱਚ ਸਟ੍ਰਿੰਗ ਡੇਟਾ ਨੂੰ ਉਦੋਂ ਤੱਕ ਸਥਾਈ ਤੌਰ 'ਤੇ ਸੇਵ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਹਾਡਾ ਕੋਡ ਜਾਂ ਯੂਜ਼ਰ ਇਸਨੂੰ ਡਿਲੀਟ ਨਹੀਂ ਕਰਦਾ। ਇੱਕ ਆਮ ਵਰਤੋਂ ਡਾਰਕ-ਮੋਡ ਦੀ ਪਸੰਦ (preference) ਹੈ। ਜਦੋਂ ਕੋਈ ਸਵਿੱਚ ਨੂੰ ਬਦਲਦਾ ਹੈ, ਤਾਂ LocalStorage ਵਿੱਚ "theme": "dark" ਲਿਖੋ। ਅਗਲੀ ਵਾਰ ਆਉਣ 'ਤੇ, ਇਸਨੂੰ ਪੜ੍ਹੋ ਅਤੇ ਪਹਿਲੀ ਪੇਂਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਸ ਲਾਗੂ ਕਰੋ। ਇਹ synchronous ਹੈ ਅਤੇ origin ਤੱਕ ਸੀਮਤ ਹੈ, ਜੋ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇਸਦੇ ਅੰਦਰ ਕਦੇ ਵੀ ਸੰਵੇਦਨਸ਼ੀਲ (sensitive) ਟੋਕਨ ਨਹੀਂ ਰੱਖਣੇ ਚਾਹੀਦੇ। ਤੁਹਾਡੇ ਪੇਜ 'ਤੇ ਚੱਲਣ ਵਾਲਾ ਕੋਈ ਵੀ ਸਕ੍ਰਿਪਟ ਇਸਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।

SessionStorage ਉਹੀ key-value API ਵਰਤਦਾ ਹੈ, ਪਰ ਇਸਦੀ ਉਮਰ ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਪੇਜ ਰਿਫ੍ਰੈਸ਼ ਹੋਣ 'ਤੇ ਵੀ ਬਚਿਆ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਇਸਨੂੰ ਅਸਥਾਈ ਫਾਰਮ ਪ੍ਰਗਤੀ (form progress) ਲਈ ਸੰਪੂਰਨ ਬਣਾਉਂਦਾ ਹੈ। ਕਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਯੂਜ਼ਰ ਇੱਕ ਲੰਬਾ ਸਰਵੇਖਣ ਭਰ ਰਿਹਾ ਹੈ, ਗਲਤੀ ਨਾਲ ਰੀਲੋਡ ਦਬਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ ਆਪਣੇ ਜਵਾਬ ਦੇਖ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ SessionStorage ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਸੀ। ਜਦੋਂ ਉਹ ਟੈਬ ਬੰਦ ਕਰਦੇ ਹਨ, ਤਾਂ ਡੇਟਾ ਆਪਣੇ ਆਪ ਸਾਫ਼ ਹੋ ਜਾਂਦਾ ਹੈ।

Cache API ਵੱਖਰੇ ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ। ਇਹ request ਅਤੇ response ਦੇ ਜੋੜਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ service workers ਦੁਆਰਾ images, fonts, ਅਤੇ script bundles ਵਰਗੀਆਂ ਵੱਡੀਆਂ static assets ਨੂੰ ਰੱਖਣ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਹਰ ਵਾਰ ਵੇਖਣ 'ਤੇ ਨੈੱਟਵਰਕ ਤੋਂ ਉਹੀ hero image ਜਾਂ React bundle ਨੂੰ ਫੈਚ ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਹਾਡੀ ਐਪ ਇਸਨੂੰ ਸਿੱਧਾ disk cache ਤੋਂ ਸਰਵ ਕਰ ਸਕਦੀ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ offline-capable ਸਾਈਟਾਂ ਵਾਰ-ਵਾਰ ਵੇਖਣ 'ਤੇ ਤੁਰੰਤ ਲੋਡ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਦੂਜਿਆਂ ਵਾਂਗ ਕੋਈ ਆਮ key-value store ਨਹੀਂ ਹੈ; ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ HTTP responses ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ।

ਇੱਕ ਸਖ਼ਤ ਨਿਯਮ: LocalStorage ਵਿੱਚ ਕਦੇ ਵੀ authentication tokens ਜਾਂ ਨਿੱਜੀ ਪਛਾਣਕਰਤਾ (personal identifiers) ਸਟੋਰ ਨਾ ਕਰੋ। XSS ਹਮਲੇ ਉਹਨਾਂ ਨੂੰ ਮਿਲੀਸੈਕਿੰਡਾਂ ਵਿੱਚ ਚੋਰੀ ਕਰ ਸਕਦੇ ਹਨ। ਕਿਸੇ ਵੀ ਸੰਵੇਦਨਸ਼ੀਲ ਚੀਜ਼ ਲਈ HttpOnly, Secure, SameSite cookies ਦੀ ਵਰਤੋਂ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਦੀ Application tab ਵਿੱਚ ਜਾਂਚ ਕਰੋ ਜਿੱਥੇ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਕਿ flags ਅਸਲ ਵਿੱਚ ਸੈੱਟ ਕੀਤੇ ਗਏ ਹਨ।

Browser DevTools: ਅੰਦਾਜ਼ੇ ਲਗਾਉਣਾ ਬੰਦ ਕਰੋ, ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰੋ

DevTools ਪੈਨਲ ਸਿਰਫ਼ ਲਾਲ console errors ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਨਹੀਂ ਹੈ। ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਅੰਦਰ ਹੋ ਰਹੀ ਹਰ ਚੀਜ਼ ਲਈ ਤੁਹਾਡੀ ਡਾਇਗਨੌਸਟਿਕ ਲੈਬ ਹੈ।

Elements ਪੈਨਲ ਵਿੱਚ, ਤੁਸੀਂ DOM tree ਦੇ ਉੱਪਰ ਹੋਵਰ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਪੇਜ 'ਤੇ nodes ਨੂੰ ਹਾਈਲਾਈਟ ਹੁੰਦੇ ਦੇਖ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਆਪਣੇ source code ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ margin ਜਾਂ ਰੰਗ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ Styles pane ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ CSS values ਨੂੰ ਐਡਿਟ ਕਰ ਸਕਦੇ ਹੋ। Console ਤੁਹਾਡਾ scratchpad ਹੈ। Objects ਨੂੰ log ਕਰੋ, regex ਦੀ ਜਾਂਚ ਕਰੋ, ਜਾਂ ਮੌਜੂਦਾ ਪੇਜ ਸਟੇਟ ਦੇ ਵਿਰੁੱਧ ਲਾਈਵ functions ਨੂੰ ਕਾਲ ਕਰੋ। ਜੇਕਰ ਕੋਈ variable ਸਹੀ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ, ਤਾਂ ਉਸਦਾ ਨਾਮ ਟਾਈਪ ਕਰੋ ਅਤੇ ਸਿੱਧਾ ਉਸਦੀ ਜਾਂਚ ਕਰੋ।

Network tab ਪਰਫਾਰਮੈਂਸ ਬਾਰੇ ਸੱਚਾਈ ਦੱਸਦਾ ਹੈ। ਉਹ ਹੌਲੀ ਪੇਜ ਸ਼ਾਇਦ ਤੁਹਾਡਾ JavaScript ਨਾ ਹੋਵੇ। ਇਹ ਕੋਈ third-party font ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਚਾਰ ਸਕਿੰਟ ਲੱਗ ਰਹੇ ਹਨ, ਜਾਂ ਕੋਈ API endpoint ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਦੋ-ਮੈਗਾਬਾਈਟ ਦਾ JSON payload ਵਾਪਸ ਕਰ ਰਿਹਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਕਦੇ ਕੰਪਰੈੱਸ ਨਹੀਂ ਕੀਤਾ। ਤੁਸੀਂ ਹਰ request ਦੇ ਪੂਰੇ lifecycle ਨੂੰ ਟ੍ਰੇਸ ਕਰ ਸਕਦੇ ਹੋ, ਆਪਣੇ API calls ਨੂੰ ਦੇਖਣ ਲਈ Fetch/XHR ਦੁਆਰਾ ਫਿਲਟਰ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ headers ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ ਕਿ caching directives ਦੀ ਪਾਲਣਾ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਸ ਦੌਰਾਨ, Application tab ਤੁਹਾਨੂੰ ਆਪਣੇ storage ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। LocalStorage key-value pairs ਦੇ ਅੰਦਰ ਝਾਤ ਮਾਰੋ, ਵਿਅਕਤੀਗਤ cookies ਅਤੇ ਉਹਨਾਂ ਦੇ flags ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡਾ service worker ਅਸਲ ਵਿੱਚ ਰਜਿਸਟਰਡ ਹੈ ਅਤੇ ਉਹੀ ਕੈਸ਼ ਕਰ ਰਿਹਾ ਹੈ ਜਿਸ ਦੀ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ।

Git Workflow: ਤਿੰਨ ਬੱਕੇ (The Three Buckets)

Git ਕੋਈ backup software ਨਹੀਂ ਹੈ। ਇਹ ਇਤਿਹਾਸ (history) ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਇੱਕ ਸਾਧਨ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਸੋਚਣ ਨਾਲ ਤੁਹਾਡੇ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਤਰੀਕਾ ਬਦਲ ਜਾਂਦਾ ਹੈ। Git ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਖੇਤਰਾਂ ਰਾਹੀਂ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ।

working tree ਤੁਹਾਡੀ ਅਸੰਗਠਿਤ ਮੇਜ਼ ਹੈ। ਤੁਸੀਂ ਇੱਥੇ ਫਾਈਲਾਂ ਨੂੰ ਐਡਿਟ ਕਰਦੇ ਹੋ, ਫੋਲਡਰ ਡਿਲੀਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਪ੍ਰਯੋਗ ਕਰਦੇ ਹੋ। ਅਜੇ ਕੁਝ ਵੀ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ। staging area, ਜਾਂ index, ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਚੋਣਵਾਂ ਤਰੀਕੇ ਨਾਲ ਚੁਣਦੇ ਹੋ ਕਿ ਅਗਲੇ snapshot ਵਿੱਚ ਕੀ ਜਾਵੇਗਾ। ਕਿਸੇ ਫਾਈਲ 'ਤੇ git add ਚਲਾਉਣ ਨਾਲ ਉਹ working tree ਤੋਂ staging ਵਿੱਚ ਚਲੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਸਟੀਕਤਾ (precision) ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਦਸ ਫਾਈਲਾਂ ਨੂੰ ਸੋਧ ਸਕਦੇ ਹੋ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਤਿੰਨ ਨੂੰ stage ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਇੱਕ ਸਾਫ਼, ਤਰਕਪੂਰਨ snapshot commit ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਅਸਲ ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ git commit ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ local repository snapshot ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ। ਉਸ ਸਮੇਂ, Git ਤੁਹਾਡੇ ਸੰਦੇਸ਼ ਦੇ ਨਾਲ staged ਫਾਈਲਾਂ ਦੀ ਪੂਰੀ ਸਥਿਤੀ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ, ਇੱਕ ਸਥਾਈ checkpoint ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਵਾਪਸ ਜਾ ਸਕਦੇ ਹੋ।

ਕੁਝ ਵੀ stage ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, git status ਚਲਾਓ। ਇਹ ਤੁਹਾਨੂੰ untracked ਫਾਈਲਾਂ ਅਤੇ ਸੋਧੀਆਂ ਹੋਈਆਂ ਫਾਈਲਾਂ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਤੁਸੀਂ ਭੁੱਲ ਗਏ ਹੋ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਜਾਂਚ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ ਤਾਂ ਅਸਥਾਈ build artifacts, log files, ਜਾਂ environment files commits ਵਿੱਚ ਲੀਕ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਮਜ਼ਬੂਤ .gitignore ਫਾਈਲ ਮਦਦ ਕਰਦੀ ਹੈ, ਪਰ git status ਤੁਹਾਡੀ ਅੰਤਿਮ pre-flight ਜਾਂਚ ਹੈ।

Staging ਤੁਹਾਨੂੰ ਗਲਤੀਆਂ ਨੂੰ ਇਤਿਹਾਸ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਵੀ ਦਿੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਫਾਈਲ ਨੂੰ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਜੋੜ ਦਿੱਤਾ ਹੈ, ਤਾਂ git restore --staged ਨਾਲ ਉਸਨੂੰ unstage ਕਰੋ। ਜੇਕਰ ਤੁਸੀਂ ਬਹੁਤ ਅਸਪਸ਼ਟ ਸਨ, ਤਾਂ ਆਪਣੇ commit message ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੋ। Staging area ਬਿਲਕੁਲ ਇਸ ਲਈ ਮੌਜੂਦ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡੇ commits ਇੱਕ ਸੁਮੇਲ ਵਾਲੀ ਕਹਾਣੀ ਦੱਸਣ, ਨਾ ਕਿ ਸਿਰਫ਼ ਦੁਪਹਿਰ ਤੋਂ ਕੀਤੇ ਗਏ ਹਰ keystroke ਦਾ ਇੱਕ ਕੱਚਾ ਡੰਪ।

ਸਭ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ

ਇਹ ਦੋ ਖੇਤਰ, ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ Git, ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੇ workflow ਦੇ ਹਰ ਘੰਟੇ ਨੂੰ ਰੂਪ ਦਿੰਦੇ ਹਨ। ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ ਕਿ requests ਕਿਵੇਂ ਹੱਲ ਹੁੰਦੀਆਂ ਹਨ, DOM ਤੁਹਾਡੇ scripts ਪ੍ਰਤੀ ਕਿਵੇਂ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ client 'ਤੇ data ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ। Secrets ਲਈ LocalStorage ਦੀ ਦੁਰਵਰਤੋਂ ਕਰਨਾ ਜਾਂ unbatched updates ਨਾਲ DOM 'ਤੇ ਹਮਲਾ ਕਰਨਾ ਕਮਜ਼ੋਰ, ਹੌਲੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਂਦਾ ਹੈ। ਆਪਣੇ terminal ਵਿੱਚ, Git ਨੂੰ save button ਵਾਂਗ ਮੰਨਣਾ ਅਜਿਹਾ ਇਤਿਹਾਸ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜ