ਜੇਕਰ ਤੁਸੀਂ ਕਦੇ ਵੀ ਕਿਸੇ ਪੇਜ ਨੂੰ ਰਿਫ੍ਰੈਸ਼ ਕੀਤਾ ਹੈ ਅਤੇ ਆਪਣੀ CSS ਨੂੰ ਗਾਇਬ ਹੁੰਦੇ ਦੇਖਿਆ ਹੈ, ਜਾਂ ਕਿਸੇ ਫਾਈਲ ਨੂੰ ਰਿਵਰਟ ਕੀਤਾ ਹੈ ਪਰ ਇਹ ਅਹਿਸਾਸ ਹੋਇਆ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਯਾਦ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਕੀ ਬਦਲਿਆ ਸੀ, ਤਾਂ ਤੁਸੀਂ ਕੋਡ ਲਿਖਣ ਅਤੇ ਉਸਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਦੇ ਵਿਚਕਾਰਲੇ ਅੰਤਰ ਨੂੰ ਸਮਝਦੇ ਹੋ। ਪੇਸ਼ੇਵਰ ਵੈੱਬ ਡਿਵੈਲਪਮੈਂਟ ਦੀ ਨੀਂਹ ਦੋ ਵਿਚਾਰਾਂ 'ਤੇ ਟਿਕੀ ਹੋਈ ਹੈ: ਬ੍ਰਾਊਜ਼ਰ ਵਾਤਾਵਰਣ (browser environment), ਜੋ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਕੋਡ ਕਿਵੇਂ ਚੱਲਦਾ ਹੈ ਅਤੇ ਡੇਟਾ ਕਿਵੇਂ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ Git, ਜੋ ਤੁਹਾਡੇ ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਹਮੇਸ਼ਾ ਲਈ ਗੁੰਮ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚ ਜਲਦੀ ਮਾਹਰ ਹੋਣਾ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਰਹੱਸਮਈ ਬੱਗਸ (bugs) ਅਤੇ ਟੁੱਟੇ ਹੋਏ ਡਿਪਲੋਇਮੈਂਟਸ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

URL ਇੱਕ ਐਡਰੈੱਸ ਸਿਸਟਮ ਵਜੋਂ

ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਨੈਵੀਗੇਸ਼ਨ ਬਾਰ ਵਿੱਚ ਕੋਈ ਐਡਰੈੱਸ ਟਾਈਪ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਕੋਆਰਡੀਨੇਟਸ (coordinates) ਦਾ ਇੱਕ ਸਮੂਹ ਦੇ ਰਹੇ ਹੁੰਦੇ ਹੋ। ਇੱਕ Uniform Resource Locator ਸਿਰਫ਼ ਇੱਕ ਸਟ੍ਰਿੰਗ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਸੰਰਚਨਾਤਮਕ ਨਿਰਦੇਸ਼ ਮੈਨੂਅਲ ਹੈ ਜੋ ਛੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਹੁੰਦਾ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ protocol ਆਉਂਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ HTTPS ਹੁੰਦਾ ਹੈ। ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਸਰਵਰ ਨਾਲ ਕਿਵੇਂ ਗੱਲਬਾਤ ਕਰਨੀ ਹੈ ਅਤੇ ਕੀ ਗੱਲਬਾਤ ਨੂੰ ਐਨਕ੍ਰਿਪਟ (encrypt) ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ domain DNS ਰਾਹੀਂ ਇੱਕ IP ਐਡਰੈੱਸ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਪਤਾ ਲੱਗ ਸਕੇ ਕਿ ਕਿਸ ਭੌਤਿਕ ਜਾਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨਾਲ ਸੰਪਰਕ ਕਰਨਾ ਹੈ।

port ਉਸ ਸਰਵਰ 'ਤੇ ਸਹੀ ਦਰਵਾਜ਼ੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਪ੍ਰੋਡਕਸ਼ਨ ਸਾਈਟਾਂ 'ਤੇ ਇਸਨੂੰ ਬਹੁਤ ਘੱਟ ਦੇਖਦੇ ਹੋ ਕਿਉਂਕਿ ਵੈੱਬ ਸਰਵਰ HTTPS ਲਈ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ 443 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਪਰ ਲੋਕਲ ਡਿਵੈਲਪਮੈਂਟ ਵਿੱਚ ਤੁਸੀਂ ਲਗਾਤਾਰ ਪੋਰਟਸ ਨਾਲ ਡੀਲ ਕਰਦੇ ਹੋ। localhost:3000 ਜਾਂ localhost:5173 ਬਾਰੇ ਸੋਚੋ। ਜੇਕਰ ਪੋਰਟ ਗਲਤ ਹੈ, ਤਾਂ ਕਨੈਕਸ਼ਨ ਸਿਰਫ਼ ਟਾਈਮ ਆਊਟ ਹੋ ਜਾਵੇਗਾ।

ਅਗਲਾ ਹੈ path, ਜੋ ਕਿਸੇ ਖਾਸ ਫਾਈਲ ਜਾਂ ਰੂਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ /blog/2024/march। ਇਸ ਤੋਂ ਬਾਅਦ query string ਆਉਂਦੀ ਹੈ ਜੋ ਪ੍ਰਸ਼ਨ ਚਿੰਨ੍ਹ (?) ਤੋਂ ਬਾਅਦ ਹੁੰਦੀ ਹੈ ਅਤੇ ਸਰਵਰ ਤੱਕ ਡੇਟਾ ਲੈ ਕੇ ਜਾਂਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ?category=javascript&sort=date। ਅੰਤ ਵਿੱਚ, fragment, ਜੋ ਕਿ ਹੈਸ਼ ਸਿੰਬਲ (#) ਦੁਆਰਾ ਚਿੰਨ੍ਹਿਤ ਹੁੰਦਾ ਹੈ, ਪੇਜ ਦੇ ਅੰਦਰ ਇੱਕ ਖਾਸ ਹਿੱਸੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਫਰੈਗਮੈਂਟਸ ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਲਿੰਕਾਂ ਅਤੇ ਐਕਸੈਸਬਿਲਟੀ (accessibility) ਲਈ ਉਪਯੋਗੀ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਯੂਜ਼ਰਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਰੀਲੋਡ ਕੀਤੇ ਬਿਨਾਂ ਸਿੱਧਾ ਕਿਸੇ ਹੈਡਿੰਗ 'ਤੇ ਲੈ ਜਾਂਦੇ ਹਨ।

ਇਸ ਸੰਰਚਨਾ ਨੂੰ ਸਮਝਣ ਨਾਲ ਤੁਹਾਨੂੰ ਰੂਟਿੰਗ ਗਲਤੀਆਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ, ਸਾਫ਼ APIs ਬਣਾਉਣ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਮੁਸ਼ਕਲ ਦੇ ਨੈੱਟਵਰਕ ਲੌਗਸ (network logs) ਪੜ੍ਹਨ ਵਿੱਚ ਮਦਦ ਮਿਲਦੀ ਹੈ।

DOM ਤੁਹਾਡਾ ਰਨਟਾਈਮ (Runtime) ਹੈ

ਬ੍ਰਾਊਜ਼ਰ ਕਦੇ ਵੀ ਕੱਚੇ HTML ਟੈਕਸਟ ਨੂੰ ਉਵੇਂ ਹੀ ਰੈਂਡਰ ਨਹੀਂ ਕਰਦੇ ਜਿਵੇਂ ਕੋਈ ਕੰਪਾਈਲਰ ਤੁਹਾਡੀ .c ਫਾਈਲ ਨੂੰ ਪਾਰਸ ਕੀਤੇ ਬਿਨਾਂ ਨਹੀਂ ਚਲਾਉਂਦਾ। ਜਦੋਂ ਬ੍ਰਾਊਜ਼ਰ ਤੁਹਾਡਾ ਮਾਰਕਅੱਪ ਡਾਊਨਲੋਡ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਟੈਗਸ ਅਤੇ ਟੈਕਸਟ ਨੂੰ Document Object Model ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਇਨ-ਮੈਮਰੀ ਟ੍ਰੀ (in-memory tree) ਹੈ ਜਿੱਥੇ ਹਰ ਐਲੀਮੈਂਟ ਇੱਕ ਨੋਡ (node) ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨੂੰ JavaScript ਛੂਹ ਸਕਦੀ ਹੈ।

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

ਇਹ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਜੋ ਸੰਰਚਨਾ ਤੁਸੀਂ ਆਪਣੇ ਐਡੀਟਰ ਵਿੱਚ ਲਿਖਦੇ ਹੋ ਅਤੇ ਜੋ ਸੰਰਚਨਾ ਬ੍ਰਾਊਜ਼ਰ ਵਰਤਦਾ ਹੈ, ਉਹ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਸਕ੍ਰਿਪਟਸ ਨਵੇਂ ਨੋਡਸ ਜੋੜ ਸਕਦੀਆਂ ਹਨ। Third-party ਵਿਜੇਟਸ ਮਾਰਕਅੱਪ ਜੋੜ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਸਟਾਈਲਿੰਗ ਜਾਂ ਈਵੈਂਟ ਲਿਸਨਰਸ (event listeners) ਨੂੰ ਡੀਬੱਗ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਆਪਣੇ ਅਸਲ ਸੋਰਸ ਦੀ ਨਹੀਂ, ਸਗੋਂ ਰੈਂਡਰ ਕੀਤੇ ਗਏ DOM ਦੀ ਦੇਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਡੇਟਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ

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

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

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

Cache ਵੱਡੀਆਂ ਐਸੇਟਸ (assets) ਜਿਵੇਂ ਕਿ ਚਿੱਤਰ (images), ਫੌਂਟਸ, ਸਟਾਈਲਸ਼ੀਟਸ ਅਤੇ ਸਕ੍ਰਿਪਟਸ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਹਰ ਵਿਜ਼ਿਟ 'ਤੇ ਦੋ ਮੈਗਾਬਾਈਟ ਦੀ ਹੀਰੋ ਇਮੇਜ ਨੂੰ ਫੈਚ ਕਰਨ ਦੀ ਬਜਾਏ, ਬ੍ਰਾਊਜ਼ਰ ਇਸਦੀ ਇੱਕ ਕਾਪੀ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਦੇਖਣ ਲਈ ਹੈਡਰਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਸਰਵਰ ਕੋਲ ਨਵਾਂ ਵਰਜ਼

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

Elements ਪੈਨਲ ਲਾਈਵ DOM ਅਤੇ ਇਸਦੇ ਕੰਪਿਊਟਡ ਸਟਾਈਲ (computed styles) ਦਿਖਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਲੇਆਉਟ (layout) ਵਿਗੜਦਾ ਹੈ, ਤਾਂ ਨੋਡ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਕੈਸਕੇਡ (cascade) ਨੂੰ ਦੇਖੋ। ਤੁਸੀਂ ਆਪਣੇ ਸੋਰਸ ਕੋਡ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਪ੍ਰੋਪਰਟੀਜ਼ ਨੂੰ ਆਨ ਅਤੇ ਆਫ ਕਰ ਸਕਦੇ ਹੋ, ਜੋ ਕਿ ਐਡੀਟਰ ਵਿੱਚ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਨਾਲੋਂ ਸਪੈਸੀਫਿਟੀ ਵਾਰਜ਼ (specificity wars) ਲੱਭਣ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ।

Console ਸਟੈਕ ਟ੍ਰੇਸ (stack traces) ਦੇ ਨਾਲ ਗਲਤੀਆਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਇੱਕ REPL ਵੀ ਹੈ। ਤੁਸੀਂ ਸਿਲੇਕਟਰਾਂ (selectors) ਨੂੰ ਕੁਐਰੀ ਕਰ ਸਕਦੇ ਹੋ, API ਰਿਸਪਾਂਸਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਮੌਜੂਦਾ ਪੇਜ ਸਟੇਟ ਦੇ ਅਨੁਸਾਰ ਐਕਸਪ੍ਰੈਸ਼ਨਾਂ (expressions) ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਸਕਦੇ ਹੋ।

Network ਪੈਨਲ ਹਰ ਰਿਕੁਐਸ (request) ਦੀ ਟਾਈਮਲਾਈਨ ਦਿਖਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਫੇਲ ਹੋ ਰਹੇ ਐਂਡਪੁਆਇੰਟ (endpoint) ਦੀ ਪਛਾਣ ਕਰ ਸਕਦੇ ਹੋ, API ਲੇਟੈਂਸੀ (latency) ਨੂੰ ਮਾਪ ਸਕਦੇ ਹੋ, ਅਤੇ ਇਹ ਪਛਾਣ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜੀ ਐਸੇਟ (asset) ਤੁਹਾਡੇ ਪਹਿਲੇ ਪੇਂਟ (first paint) ਨੂੰ ਰੋਕ ਰਹੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਯੂਜ਼ਰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਐਪ ਹੌਲੀ ਹੈ, ਤਾਂ ਇੱਥੇ ਹੀ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਸਰਵਰ ਜਾਂ ਫਰੰਟਐਂਡ ਵਿੱਚੋਂ ਕਿਹੜਾ ਰੁਕਾਵਟ (bottleneck) ਬਣਿਆ ਹੋਇਆ ਹੈ।

Application ਪੈਨਲ ਤੁਹਾਨੂੰ ਇੱਕੋ ਥਾਂ 'ਤੇ ਕੁਕੀਜ਼ (cookies), LocalStorage, ਅਤੇ SessionStorage ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਆਥੈਂਟੀਕੇਸ਼ਨ (authentication) ਦੀ ਜਾਂਚ ਕਰਦੇ ਸਮੇਂ ਜਾਂ ਸਟੇਟ ਬੱਗ (state bug) ਨੂੰ ਡੀਬੱਗ ਕਰਦੇ ਸਮੇਂ, ਤੁਸੀਂ ਆਪਣੀ ਪੂਰੀ ਬ੍ਰਾਊਜ਼ਿੰਗ ਹਿਸਟਰੀ ਨੂੰ ਖਤਮ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਨਵੇਂ ਵਿਜ਼ਟਰ ਦਾ ਅਨੁਭਵ ਕਰਨ ਲਈ ਸਟੋਰੇਜ ਨੂੰ ਮੈਨੂਅਲੀ ਸਾਫ਼ ਕਰ ਸਕਦੇ ਹੋ।

ਫਾਈਲਾਂ ਦੀ ਬਜਾਏ Git ਸਟੇਜਾਂ (stages) ਵਿੱਚ ਸੋਚਣਾ

ਇੱਕ ਫਾਈਲ ਨੂੰ ਸੇਵ ਕਰਨਾ ਉਸਦੀ ਵਰਜ਼ਨਿੰਗ (versioning) ਕਰਨ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। Git ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਪੱਕੇ ਤੌਰ 'ਤੇ ਰਿਕਾਰਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ (stages) ਵਿੱਚ ਬਦਲਾਅ ਬਾਰੇ ਸੋਚਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

ਤੁਹਾਡਾ working tree ਇੱਕ ਅਸੰਗਠਿਤ ਡੈਸਕ ਵਾਂਗ ਹੈ। ਤੁਸੀਂ ਫਾਈਲਾਂ ਨੂੰ ਐਡਿਟ ਕਰਦੇ ਹੋ, ਚੀਜ਼ਾਂ ਨੂੰ ਵਿਗਾੜਦੇ ਹੋ, ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਕਮੈਂਟ ਆਊਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਵੇਰੀਏਬਲਜ਼ ਦਾ ਨਾਮ ਬਦਲਦੇ ਹੋ। ਅਜੇ ਤੱਕ ਕੁਝ ਵੀ ਟ੍ਰੈਕ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਥੇ ਕੋਈ ਫਾਈਲ ਡਿਲੀਟ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਕਮਿਟ (commit) ਨਹੀਂ ਕੀਤਾ ਹੈ, ਤਾਂ ਇਹ ਸਿਰਫ਼ ਗਾਇਬ ਹੋ ਜਾਵੇਗੀ।

staging area, ਜਿਸ ਨੂੰ ਇੰਡੈਕਸ (index) ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। git add ਦੇ ਨਾਲ, ਤੁਸੀਂ ਚੁਣੇ ਹੋਏ ਬਦਲਾਅਾਂ ਨੂੰ ਪ੍ਰੀ-ਕਮਿਟ (pre-commit) ਹੋਲਡਿੰਗ ਜ਼ੋਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋ। Staging area ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਅਸੰਬੰਧਿਤ ਕੰਮਾਂ ਨੂੰ ਵੱਖ ਕਰ ਸਕੋ। ਜੇਕਰ ਤੁਸੀਂ ਲੌਗਇਨ ਬੱਗ ਨੂੰ ਠੀਕ ਕੀਤਾ ਹੈ ਅਤੇ ਇੱਕ ਯੂਟੀਲਿਟੀ ਫੰਕਸ਼ਨ ਨੂੰ ਰੀਫੈਕਟਰ (refactor) ਵੀ ਕੀਤਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਸਟੇਜ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕ ਅਸਪਸ਼ਟ ਮੈਸੇਜ ਦੀ ਬਜਾਏ ਦੋ ਸਪਸ਼ਟ ਕਮਿਟ ਮੈਸੇਜ ਲਿਖ ਸਕਦੇ ਹੋ।

ਅੰਤ ਵਿੱਚ, local repository ਅਸਲ ਇਤਿਹਾਸ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ। git commit ਚਲਾਉਣ ਨਾਲ ਤੁਹਾਡੇ ਸਟੇਜ ਕੀਤੇ ਬਦਲਾਅ ਇੱਕ ਵਿਲੱਖਣ ਹੈਸ਼ (hash), ਇੱਕ ਮੈਸੇਜ ਅਤੇ ਇੱਕ ਟਾਈਮਸਟੈਂਪ ਦੇ ਨਾਲ ਇੱਕ ਸਨੈਪਸ਼ੌਟ (snapshot) ਵਿੱਚ ਲੌਕ ਹੋ ਜਾਂਦੇ ਹਨ। ਉਹ ਸਨੈਪਸ਼ੌਟ ਹੁਣ ਵਾਪਸ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਤੁਸੀਂ ਕੱਲ੍ਹ ਫਾਈਲ ਨੂੰ ਕਿੰਨਾ ਵੀ ਵਿਗਾੜ ਦਿਓ। ਕਮਿਟਸ (commits) ਸਸਤੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਤਰਕਪੂਰਨ ਬਣਾਓ। ਛੋਟੇ, ਪੜ੍ਹਨਯੋਗ ਕਮਿਟਸ ਦਾ ਇਤਿਹਾਸ ਸ਼ੁੱਕਰਵਾਰ ਦੁਪਹਿਰ ਦੇ ਕੋਡ ਦੇ ਇੱਕ ਵਿਸ਼ਾਲ ਡੰਪ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਉਪਯੋਗੀ ਹੁੰਦਾ ਹੈ।

ਅਸਲ ਸਿੱਖਿਆ (The Real Takeaway)

ਇਹ ਵਿਸ਼ੇ ਸਿਧਾਂਤਕ ਕੰਪਿਊਟਰ ਵਿਗਿਆਨ (theoretical computer science) ਨਹੀਂ ਹਨ। ਇਹ ਵਿਵਹਾਰਕ ਕੰਟਰੋਲ ਪ੍ਰਣਾਲੀਆਂ (practical control systems) ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਇੱਕ URL ਕਿਵੇਂ ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਲੌਗਸ (logs) ਨੂੰ ਬਿਹਤਰ ਤਰੀਕੇ ਨਾਲ ਪੜ੍ਹਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ DOM ਨੂੰ ਸਟੈਟਿਕ ਮਾਰਕਅੱਪ (static markup) ਦੀ ਬਜਾਏ ਇੱਕ ਜੀਵਤ ਰਨਟਾਈਮ (living runtime) ਵਜੋਂ ਮੰਨਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡਾ JavaScript ਅਨੁਮਾਨਯੋਗ (predictable) ਹੋ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ LocalStorage ਅਤੇ SessionStorage ਦੀ ਸਹੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਟੈਬਾਂ ਵਿੱਚ ਸਟੇਟ ਲੀਕ ਹੋਣ ਤੋਂ ਰੋਕਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਉਦੇਸ਼ ਨਾਲ DevTools ਖੋਲ੍ਹਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਕਿ ਕੋਈ ਬਟਨ ਨੀਲੇ ਦੀ ਬਜਾਏ ਹਰਾ ਕਿਉਂ ਹੈ। ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ Git ਦੇ ਤਿੰਨ-ਪੜਾਵੀ ਵਰਕਫਲੋ (workflow) ਦਾ ਸਤਿਕਾਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਨਡੂ (undo) ਬਟਨ ਤੋਂ ਡਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ।

ਇੱਕੋ ਵਾਰ ਵਿੱਚ ਹਰ ਐਜ ਕੇਸ (edge case) ਨੂੰ ਯਾਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। ਇਸ ਦੀ ਬਜਾਏ, ਇੱਕ ਆਦਤ ਬਣਾਓ: ਜਦੋਂ ਲੇਆਉਟ ਵਿਗੜਦਾ ਹੈ ਤਾਂ ਦਸ ਮਿੰਟ ਲਈ DOM ਦੀ ਜਾਂਚ ਕਰੋ, ਬੈਕਐਂਡ (backend) ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ Network ਟੈਬ ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਸਪਸ਼ਟ ਵਿਚਾਰ ਪੂਰਾ ਕਰਦੇ ਹੋ ਤਾਂ ਕਮਿਟ ਕਰੋ। ਤੁਹਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਆਪਣੇ ਆਪ ਵਧ ਜਾਵੇਗੀ।