40 KiB

Raw Blame History

ਬੈਂਕਿੰਗ ਐਪ ਬਣਾਓ ਭਾਗ 4: ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਦੇ ਸਿਧਾਂਤ

ਪੂਰਵ-ਵਿਆਖਿਆ ਪ੍ਰਸ਼ਨਾਵਲੀ

ਜਾਣ ਪਛਾਣ

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

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

ਇਹ ਖਰਾਬ ਕੋਡਿੰਗ ਦੇ ਸੰਕੇਤ ਨਹੀਂ ਹਨ - ਇਹ ਕੁਦਰਤੀ ਵਿਕਾਸ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ ਜੋ ਉਸ ਸਮੇਂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਨਿਰਧਾਰਿਤ ਜਟਿਲਤਾ ਦੀ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੇ ਹਨ। ਹਰ ਡਿਵੈਲਪਰ ਨੂੰ ਇਹ ਚੁਣੌਤੀਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜਦੋਂ ਉਹਨਾਂ ਦੀਆਂ ਐਪਸ "ਸਿਧਾਂਤ ਦਾ ਸਬੂਤ" ਤੋਂ "ਉਤਪਾਦਨ ਲਈ ਤਿਆਰ" ਵਿੱਚ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ।

ਇਸ ਪਾਠ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਕੇਂਦਰੀ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਸਿਸਟਮ ਲਾਗੂ ਕਰਾਂਗੇ ਜੋ ਤੁਹਾਡੀ ਬੈਂਕਿੰਗ ਐਪ ਨੂੰ ਇੱਕ ਭਰੋਸੇਮੰਦ, ਪੇਸ਼ੇਵਰ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਬਦਲ ਦੇਵੇਗਾ। ਤੁਸੀਂ ਡਾਟਾ ਫਲੋਜ਼ ਨੂੰ ਪੇਸ਼ਗੀ ਤੌਰ 'ਤੇ ਮੈਨੇਜ ਕਰਨਾ, ਯੂਜ਼ਰ ਸੈਸ਼ਨ ਨੂੰ ਢੰਗ ਨਾਲ ਸਟੋਰ ਕਰਨਾ, ਅਤੇ ਆਧੁਨਿਕ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਲੋੜੀਂਦਾ ਸੁਗਮ ਯੂਜ਼ਰ ਅਨੁਭਵ ਬਣਾਉਣਾ ਸਿੱਖੋਗੇ।

ਪੂਰਵ ਸ਼ਰਤਾਂ

ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਦੇ ਸਿਧਾਂਤਾਂ ਵਿੱਚ ਡੁੱਬਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਆਪਣਾ ਡਿਵੈਲਪਮੈਂਟ ਵਾਤਾਵਰਣ ਢੰਗ ਨਾਲ ਸੈਟਅੱਪ ਕਰਨਾ ਹੋਵੇਗਾ ਅਤੇ ਆਪਣੀ ਬੈਂਕਿੰਗ ਐਪ ਦੀ ਬੁਨਿਆਦ ਤਿਆਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਪਾਠ ਇਸ ਸਿਰੀਜ਼ ਦੇ ਪਿਛਲੇ ਭਾਗਾਂ ਦੇ ਸਿਧਾਂਤਾਂ ਅਤੇ ਕੋਡ 'ਤੇ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਅਧਾਰਿਤ ਹੈ।

ਪ੍ਰਗਤੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਤਿਆਰ ਰੱਖੋ:

ਲੋੜੀਂਦਾ ਸੈਟਅੱਪ:

ਡਾਟਾ ਫੈਚਿੰਗ ਪਾਠ ਪੂਰਾ ਕਰੋ - ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਖਾਤੇ ਦਾ ਡਾਟਾ ਲੋਡ ਅਤੇ ਡਿਸਪਲੇ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
ਆਪਣੇ ਸਿਸਟਮ 'ਤੇ Node.js ਇੰਸਟਾਲ ਕਰੋ ਬੈਕਐਂਡ API ਚਲਾਉਣ ਲਈ
ਖਾਤੇ ਦੇ ਡਾਟਾ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਸਰਵਰ API ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਕਰੋ

ਆਪਣੇ ਵਾਤਾਵਰਣ ਦੀ ਜਾਂਚ:

ਇਹ ਕਮਾਂਡ ਟਰਮੀਨਲ ਵਿੱਚ ਚਲਾਕੇ ਆਪਣੇ API ਸਰਵਰ ਨੂੰ ਸਹੀ ਤੌਰ 'ਤੇ ਚਲਾਉਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ:

curl http://localhost:5000/api
# -> should return "Bank API v1.0.0" as a result

ਇਹ ਕਮਾਂਡ ਕੀ ਕਰਦੀ ਹੈ:

GET ਰਿਕਵੈਸਟ ਭੇਜਦੀ ਹੈ ਤੁਹਾਡੇ ਸਥਾਨਕ API ਸਰਵਰ ਨੂੰ
ਕਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ ਅਤੇ ਸਰਵਰ ਦੇ ਜਵਾਬ ਦੇਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ
API ਵਰਜਨ ਜਾਣਕਾਰੀ ਵਾਪਸ ਕਰਦੀ ਹੈ ਜੇਕਰ ਸਭ ਕੁਝ ਸਹੀ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ

ਮੌਜੂਦਾ ਸਟੇਟ ਸਮੱਸਿਆਵਾਂ ਦੀ ਜਾਂਚ

ਜਿਵੇਂ ਸ਼ਰਲਾਕ ਹੋਮਜ਼ ਇੱਕ ਜੁਰਮ ਦੇ ਸਥਾਨ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਸੀਂ ਆਪਣੀ ਮੌਜੂਦਾ ਲਾਗੂ ਕਰਨ ਦੀ ਪੂਰੀ ਸਮਝ ਲੈਣੀ ਹੈ ਕਿ ਯੂਜ਼ਰ ਸੈਸ਼ਨ ਕਿਉਂ ਗਾਇਬ ਹੋ ਰਹੇ ਹਨ।

ਆਓ ਇੱਕ ਸਧਾਰਨ ਪ੍ਰਯੋਗ ਕਰੀਏ ਜੋ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਦੀਆਂ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:

🧪 ਇਹ ਡਾਇਗਨੋਸਟਿਕ ਟੈਸਟ ਕਰੋ:

ਆਪਣੀ ਬੈਂਕਿੰਗ ਐਪ ਵਿੱਚ ਲੌਗਇਨ ਕਰੋ ਅਤੇ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਜਾਓ
ਬ੍ਰਾਊਜ਼ਰ ਪੰਨਾ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ
ਦੇਖੋ ਕਿ ਤੁਹਾਡੀ ਲੌਗਇਨ ਸਥਿਤੀ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ

ਜੇਕਰ ਤੁਹਾਨੂੰ ਮੁੜ ਲੌਗਇਨ ਸਕ੍ਰੀਨ 'ਤੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕਲਾਸਿਕ ਸਟੇਟ ਪERSISTENCE ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕਰ ਲਈ ਹੈ। ਇਹ ਵਿਹਾਰ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਸਾਡੀ ਮੌਜੂਦਾ ਲਾਗੂ ਕਰਨ ਵਾਲੀ ਯੂਜ਼ਰ ਡਾਟਾ ਨੂੰ ਜਾਵਾਸਕ੍ਰਿਪਟ ਵੈਰੀਏਬਲ ਵਿੱਚ ਸਟੋਰ ਕਰਦੀ ਹੈ ਜੋ ਹਰ ਪੰਨਾ ਲੋਡ ਨਾਲ ਰੀਸੈਟ ਹੋ ਜਾਂਦੇ ਹਨ।

ਮੌਜੂਦਾ ਲਾਗੂ ਕਰਨ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ:

ਪਿਛਲੇ ਪਾਠ ਦੇ ਸਧਾਰਨ account ਵੈਰੀਏਬਲ ਨੇ ਤਿੰਨ ਮਹੱਤਵਪੂਰਨ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕੀਤੀਆਂ ਹਨ ਜੋ ਯੂਜ਼ਰ ਅਨੁਭਵ ਅਤੇ ਕੋਡ ਦੀ ਰੱਖ-ਰਖਾਵ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ:

ਸਮੱਸਿਆ	ਤਕਨੀਕੀ ਕਾਰਨ	ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ
ਸੈਸ਼ਨ ਖੋਣਾ	ਪੰਨਾ ਰੀਫ੍ਰੈਸ਼ ਜਾਵਾਸਕ੍ਰਿਪਟ ਵੈਰੀਏਬਲ ਨੂੰ ਸਾਫ ਕਰ ਦਿੰਦਾ ਹੈ	ਯੂਜ਼ਰ ਨੂੰ ਵਾਰ-ਵਾਰ ਮੁੜ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਨੀ ਪੈਂਦੀ ਹੈ
ਬਿਖਰੇ ਅੱਪਡੇਟ	ਕਈ ਫੰਕਸ਼ਨ ਸਿੱਧੇ ਸਟੇਟ ਨੂੰ ਬਦਲਦੇ ਹਨ	ਡਿਬੱਗਿੰਗ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਹੈ
ਅਧੂਰਾ ਕਲੀਨਅੱਪ	ਲੌਗਆਉਟ ਸਾਰੇ ਸਟੇਟ ਰਿਫਰੈਂਸ ਨੂੰ ਸਾਫ ਨਹੀਂ ਕਰਦਾ	ਸੰਭਾਵਿਤ ਸੁਰੱਖਿਆ ਅਤੇ ਗੋਪਨੀਯਤਾ ਚਿੰਤਾਵਾਂ

ਆਰਕੀਟੈਕਚਰਲ ਚੁਣੌਤੀ:

ਜਿਵੇਂ ਟਾਇਟੈਨਿਕ ਦੇ ਕਮਰਿਆਂ ਦਾ ਡਿਜ਼ਾਈਨ ਮਜ਼ਬੂਤ ਲੱਗਦਾ ਸੀ ਜਦੋਂ ਤੱਕ ਕਈ ਕਮਰੇ ਇੱਕੋ ਸਮੇਂ ਵਿੱਚ ਪਾਣੀ ਨਾਲ ਭਰ ਨਹੀਂ ਗਏ, ਇਹ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਠੀਕ ਕਰਨਾ ਅਧਾਰਭੂਤ ਆਰਕੀਟੈਕਚਰਲ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰੇਗਾ। ਸਾਨੂੰ ਇੱਕ ਵਿਆਪਕ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਹੱਲ ਦੀ ਲੋੜ ਹੈ।

💡 ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਇੱਥੇ ਕੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ?

ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਦੋ ਮੁੱਖ ਪਹੇਲੀਆਂ ਨੂੰ ਹੱਲ ਕਰਨ ਬਾਰੇ ਹੈ:

ਮੇਰਾ ਡਾਟਾ ਕਿੱਥੇ ਹੈ?: ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਸਾਡੇ ਕੋਲ ਕੀ ਜਾਣਕਾਰੀ ਹੈ ਅਤੇ ਇਹ ਕਿੱਥੋਂ ਆ ਰਹੀ ਹੈ
ਕੀ ਸਭ ਇੱਕੋ ਪੰਨੇ 'ਤੇ ਹਨ?: ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਯੂਜ਼ਰ ਜੋ ਦੇਖਦੇ ਹਨ ਉਹ ਅਸਲ ਵਿੱਚ ਹੋ ਰਹੇ ਨਾਲ ਮਿਲਦਾ ਹੈ

ਸਾਡਾ ਯੋਜਨਾ:

ਆਪਣੇ ਆਪ ਨੂੰ ਗੁੰਝਲ ਵਿੱਚ ਪਾਉਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਇੱਕ ਕੇਂਦਰੀ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਸਿਸਟਮ ਬਣਾਉਣ ਜਾ ਰਹੇ ਹਾਂ। ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸੋਚੋ ਕਿ ਸਾਰੇ ਮਹੱਤਵਪੂਰਨ ਕੰਮਾਂ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਇੱਕ ਬਹੁਤ ਹੀ ਸੰਗਠਿਤ ਵਿਅਕਤੀ ਦੇ ਹੱਥ ਵਿੱਚ ਹੈ:

ਇਸ ਡਾਟਾ ਫਲੋ ਨੂੰ ਸਮਝਣਾ:

ਕੇਂਦਰੀਕਰਿਤ ਸਾਰੇ ਐਪਲੀਕੇਸ਼ਨ ਸਟੇਟ ਨੂੰ ਇੱਕ ਸਥਾਨ ਵਿੱਚ
ਰੂਟ ਸਾਰੇ ਸਟੇਟ ਬਦਲਾਅ ਨੂੰ ਨਿਯੰਤਰਿਤ ਫੰਕਸ਼ਨਾਂ ਰਾਹੀਂ
ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ UI ਮੌਜੂਦਾ ਸਟੇਟ ਨਾਲ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਰਹੇ
ਪੇਸ਼ਕਸ਼ ਡਾਟਾ ਮੈਨੇਜਮੈਂਟ ਲਈ ਇੱਕ ਸਾਫ, ਪੇਸ਼ਗੀ ਪੈਟਰਨ

💡 ਪੇਸ਼ੇਵਰ ਅੰਦਰੂਨੀ ਜਾਣਕਾਰੀ: ਇਹ ਪਾਠ ਮੁੱਢਲੀ ਸਿਧਾਂਤਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ। ਜਟਿਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, Redux ਵਰਗੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਹੋਰ ਉੱਚ-ਸਤਹ ਦੇ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਫੀਚਰ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਮੁੱਢਲੇ ਸਿਧਾਂਤਾਂ ਨੂੰ ਸਮਝਣਾ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਲਾਇਬ੍ਰੇਰੀ 'ਤੇ ਮਾਹਰ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ।

⚠️ ਉੱਚ-ਸਤਹ ਵਿਸ਼ਾ: ਅਸੀਂ ਸਟੇਟ ਬਦਲਾਅ ਦੁਆਰਾ ਸਵੈਚਾਲਿਤ UI ਅੱਪਡੇਟਾਂ ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਾਂਗੇ, ਕਿਉਂਕਿ ਇਹ Reactive Programming ਸਿਧਾਂਤਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਤੁਹਾਡੇ ਸਿੱਖਣ ਦੇ ਯਾਤਰਾ ਲਈ ਇੱਕ ਸ਼ਾਨਦਾਰ ਅਗਲਾ ਕਦਮ ਸਮਝੋ!

ਕੰਮ: ਸਟੇਟ ਸਟ੍ਰਕਚਰ ਨੂੰ ਕੇਂਦਰੀਕਰਿਤ ਕਰੋ

ਆਓ ਆਪਣੀ ਬਿਖਰੀ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਇੱਕ ਕੇਂਦਰੀ ਸਿਸਟਮ ਵਿੱਚ ਬਦਲਣਾ ਸ਼ੁਰੂ ਕਰੀਏ। ਇਹ ਪਹਿਲਾ ਕਦਮ ਉਹਨਾਂ ਸਾਰੀਆਂ ਸੁਧਾਰਾਂ ਲਈ ਬੁਨਿਆਦ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਜੋ ਅੱਗੇ ਆਉਣਗੇ।

ਕਦਮ 1: ਇੱਕ ਕੇਂਦਰੀ ਸਟੇਟ ਆਬਜੈਕਟ ਬਣਾਓ

ਸਧਾਰਨ account ਡਿਕਲੇਰੇਸ਼ਨ ਨੂੰ ਬਦਲੋ:

let account = null;

ਇੱਕ ਸਟ੍ਰਕਚਰਡ ਸਟੇਟ ਆਬਜੈਕਟ ਨਾਲ:

let state = {
  account: null
};

ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ:

ਕੇਂਦਰੀਕਰਿਤ ਸਾਰੇ ਐਪਲੀਕੇਸ਼ਨ ਡਾਟਾ ਨੂੰ ਇੱਕ ਸਥਾਨ ਵਿੱਚ
ਤਿਆਰ ਕਰਦਾ ਹੈ ਹੋਰ ਸਟੇਟ ਪ੍ਰਾਪਰਟੀਜ਼ ਨੂੰ ਜੋੜਨ ਲਈ ਸਟ੍ਰਕਚਰ
ਸਪਸ਼ਟ ਬਾਊਂਡਰੀ ਬਣਾਉਂਦਾ ਹੈ ਸਟੇਟ ਅਤੇ ਹੋਰ ਵੈਰੀਏਬਲਾਂ ਦੇ ਵਿਚਕਾਰ
ਪੈਟਰਨ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਐਪ ਦੇ ਵਧਣ ਨਾਲ ਸਕੇਲ ਕਰਦਾ ਹੈ

ਕਦਮ 2: ਸਟੇਟ ਐਕਸੈਸ ਪੈਟਰਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ

ਆਪਣੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਨਵੀਂ ਸਟੇਟ ਸਟ੍ਰਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਅੱਪਡੇਟ ਕਰੋ:

register() ਅਤੇ login() ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ, ਬਦਲੋ:

account = ...

ਨਾਲ:

state.account = ...

updateDashboard() ਫੰਕਸ਼ਨ ਵਿੱਚ, ਇਹ ਲਾਈਨ ਸ਼ੁਰੂ 'ਤੇ ਸ਼ਾਮਲ ਕਰੋ:

const account = state.account;

ਇਹ ਅੱਪਡੇਟ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ:

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

💡 ਨੋਟ: ਇਹ ਰੀਫੈਕਟੋਰਿੰਗ ਤੁਰੰਤ ਸਾਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਨਹੀਂ ਕਰਦੀ, ਪਰ ਇਹ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸੁਧਾਰਾਂ ਲਈ ਜ਼ਰੂਰੀ ਬੁਨਿਆਦ ਬਣਾਉਂਦੀ ਹੈ!

ਨਿਯੰਤਰਿਤ ਸਟੇਟ ਅੱਪਡੇਟਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ

ਸਾਡੇ ਸਟੇਟ ਨੂੰ ਕੇਂਦਰੀਕਰਿਤ ਕਰਨ ਨਾਲ, ਅਗਲਾ ਕਦਮ ਡਾਟਾ ਬਦਲਾਅ ਲਈ ਨਿਯੰਤਰਿਤ ਮਕੈਨਿਜ਼ਮ ਸਥਾਪਿਤ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ। ਇਹ ਪਹੁੰਚ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਸਟੇਟ ਬਦਲਾਅ ਪੇਸ਼ਗੀ ਹਨ ਅਤੇ ਡਿਬੱਗਿੰਗ ਆਸਾਨ ਹੈ।

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

ਅਮਿਊਟੇਬਲ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ:

ਅਸੀਂ ਆਪਣੇ state ਆਬਜੈਕਟ ਨੂੰ immutable ਵਜੋਂ ਮੰਨਾਂਗੇ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਇਸਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਬਦਲਦੇ ਨਹੀਂ। ਇਸਦੀ ਬਜਾਏ, ਹਰ ਬਦਲਾਅ ਇੱਕ ਨਵਾਂ ਸਟੇਟ ਆਬਜੈਕਟ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਅੱਪਡੇਟ ਕੀਤਾ ਡਾਟਾ ਹੁੰਦਾ ਹੈ।

ਜਦੋਂ ਕਿ ਇਹ ਪਹੁੰਚ ਸਿੱਧੇ ਬਦਲਾਅ ਦੇ ਮੁਕਾਬਲੇ ਸ਼ੁਰੂ ਵਿੱਚ ਅਸਰਦਾਰ ਨਹੀਂ ਲੱਗਦੀ, ਇਹ ਡਿਬੱਗਿੰਗ, ਟੈਸਟਿੰਗ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਪੇਸ਼ਗੀਤਾ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਫਾਇਦੇ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।

ਅਮਿਊਟੇਬਲ ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਦੇ ਫਾਇਦੇ:

ਫਾਇਦਾ	ਵੇਰਵਾ	ਪ੍ਰਭਾਵ
ਪੇਸ਼ਗੀਤਾ	ਬਦਲਾਅ ਸਿਰਫ ਨਿਯੰਤਰਿਤ ਫੰਕਸ਼ਨਾਂ ਰਾਹੀਂ ਹੁੰਦੇ ਹਨ	ਡਿਬੱਗ ਅਤੇ ਟੈਸਟ ਕਰਨਾ ਆਸਾਨ
ਇਤਿਹਾਸ ਟ੍ਰੈਕਿੰਗ	ਹਰ ਸਟੇਟ ਬਦਲਾਅ ਇੱਕ ਨਵ

💡 ਤਕਨੀਕੀ ਵਿਕਲਪ: ਵੱਡੇ ਡਾਟਾਸੈਟ ਵਾਲੀਆਂ ਜਟਿਲ ਆਫਲਾਈਨ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, IndexedDB API ਬਾਰੇ ਸੋਚੋ। ਇਹ ਪੂਰੀ ਕਲਾਇੰਟ-ਸਾਈਡ ਡਾਟਾਬੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਪਰ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਧੇਰੇ ਜਟਿਲਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਟਾਸਕ: localStorage Persistence ਲਾਗੂ ਕਰੋ

ਆਓ ਪERSISTENT ਸਟੋਰੇਜ ਲਾਗੂ ਕਰੀਏ ਤਾਂ ਕਿ ਯੂਜ਼ਰ explicit ਤੌਰ 'ਤੇ ਲੌਗ ਆਉਟ ਕਰਨ ਤੱਕ ਲੌਗਇਨ ਰਹਿ ਸਕਣ। ਅਸੀਂ localStorage ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬ੍ਰਾਊਜ਼ਰ ਸੈਸ਼ਨ ਵਿੱਚ ਖਾਤੇ ਦੇ ਡਾਟਾ ਨੂੰ ਸਟੋਰ ਕਰਾਂਗੇ।

ਪਹਿਲਾ ਕਦਮ: ਸਟੋਰੇਜ ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

const storageKey = 'savedAccount';

ਇਹ constant ਕੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:

ਸਥਿਰ ਪਛਾਣਕਰਤਾ ਬਣਾਉਂਦਾ ਹੈ ਸਟੋਰ ਕੀਤੇ ਡਾਟਾ ਲਈ
ਟਾਈਪੋਜ਼ ਨੂੰ ਰੋਕਦਾ ਹੈ ਸਟੋਰੇਜ ਕੀ ਰਿਫਰੈਂਸ ਵਿੱਚ
ਸਟੋਰੇਜ ਕੀ ਨੂੰ ਬਦਲਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਜੇ ਲੋੜ ਹੋਵੇ
ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਸਥਿਰ ਕੋਡ ਲਈ

ਦੂਜਾ ਕਦਮ: Automatic Persistence ਸ਼ਾਮਲ ਕਰੋ

updateState() ਫੰਕਸ਼ਨ ਦੇ ਅੰਤ ਵਿੱਚ ਇਹ ਲਾਈਨ ਸ਼ਾਮਲ ਕਰੋ:

localStorage.setItem(storageKey, JSON.stringify(state.account));

ਇਸਦੇ ਪਿੱਛੇ ਕੀ ਹੁੰਦਾ ਹੈ:

ਖਾਤੇ ਦੇ ਆਬਜੈਕਟ ਨੂੰ JSON ਸਟ੍ਰਿੰਗ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਸਟੋਰੇਜ ਲਈ
ਡਾਟਾ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ ਸਾਡੇ ਸਥਿਰ ਸਟੋਰੇਜ ਕੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ
ਆਪਮਾਤਰ ਚਲਾਉਂਦਾ ਹੈ ਜਦੋਂ ਸਟੇਟ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ
ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਸਟੋਰ ਕੀਤਾ ਡਾਟਾ ਹਮੇਸ਼ਾ ਮੌਜੂਦਾ ਸਟੇਟ ਨਾਲ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਰਹੇ

💡 ਆਰਕੀਟੈਕਚਰ ਦਾ ਫਾਇਦਾ: ਕਿਉਂਕਿ ਅਸੀਂ ਸਾਰੇ ਸਟੇਟ ਅਪਡੇਟ ਨੂੰ updateState() ਰਾਹੀਂ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕੀਤਾ ਹੈ, ਪERSISTENCE ਸ਼ਾਮਲ ਕਰਨਾ ਸਿਰਫ ਇੱਕ ਲਾਈਨ ਕੋਡ ਦੀ ਲੋੜ ਸੀ। ਇਹ ਚੰਗੇ ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲਿਆਂ ਦੀ ਤਾਕਤ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ!

ਤੀਜਾ ਕਦਮ: ਐਪ ਲੋਡ 'ਤੇ ਸਟੇਟ ਨੂੰ ਮੁੜ ਸਥਾਪਿਤ ਕਰੋ

ਸੇਵ ਕੀਤੇ ਡਾਟਾ ਨੂੰ ਮੁੜ ਸਥਾਪਿਤ ਕਰਨ ਲਈ ਇੱਕ initialization ਫੰਕਸ਼ਨ ਬਣਾਓ:

function init() {
  const savedAccount = localStorage.getItem(storageKey);
  if (savedAccount) {
    updateState('account', JSON.parse(savedAccount));
  }

  // Our previous initialization code
  window.onpopstate = () => updateRoute();
  updateRoute();
}

init();

Initialization ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਮਝਣਾ:

ਪਹਿਲਾਂ ਸਟੋਰ ਕੀਤਾ ਖਾਤਾ ਡਾਟਾ localStorage ਤੋਂ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ
JSON ਸਟ੍ਰਿੰਗ ਨੂੰ ਮੁੜ JavaScript ਆਬਜੈਕਟ ਵਿੱਚ ਪਾਰਸ ਕਰਦਾ ਹੈ
ਸਾਡੇ ਨਿਯੰਤਰਿਤ ਅਪਡੇਟ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਟੇਟ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ
ਯੂਜ਼ਰ ਦਾ ਸੈਸ਼ਨ ਆਪਣੇ ਆਪ ਮੁੜ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਪੇਜ ਲੋਡ 'ਤੇ
ਰੂਟ ਅਪਡੇਟ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾਉਂਦਾ ਹੈ ਤਾਂ ਜੋ ਸਟੇਟ ਉਪਲਬਧ ਹੋਵੇ

ਚੌਥਾ ਕਦਮ: Default Route ਨੂੰ Optimize ਕਰੋ

Persistence ਦਾ ਫਾਇਦਾ ਲੈਣ ਲਈ default route ਨੂੰ ਅਪਡੇਟ ਕਰੋ:

updateRoute() ਵਿੱਚ, ਇਹ ਬਦਲੋ:

// Replace: return navigate('/login');
return navigate('/dashboard');

ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਸਹੀ ਹੈ:

ਸਾਡੇ ਨਵੇਂ persistence ਸਿਸਟਮ ਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਲਾਭ ਲੈਂਦਾ ਹੈ
ਡੈਸ਼ਬੋਰਡ ਨੂੰ authentication ਚੈੱਕ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ
ਆਪਮਾਤਰ ਲੌਗਇਨ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ ਜੇ ਕੋਈ ਸੇਵ ਕੀਤੀ ਸੈਸ਼ਨ ਮੌਜੂਦ ਨਹੀਂ ਹੈ
ਇੱਕ ਵਧੀਆ ਯੂਜ਼ਰ ਅਨੁਭਵ ਬਣਾਉਂਦਾ ਹੈ

ਤੁਹਾਡੀ Implementation ਦੀ ਟੈਸਟਿੰਗ:

ਆਪਣੇ ਬੈਂਕਿੰਗ ਐਪ ਵਿੱਚ ਲੌਗਇਨ ਕਰੋ
ਬ੍ਰਾਊਜ਼ਰ ਪੇਜ ਨੂੰ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ
ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਲੌਗਇਨ ਰਹਿੰਦੇ ਹੋ ਅਤੇ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਹੋ
ਆਪਣਾ ਬ੍ਰਾਊਜ਼ਰ ਬੰਦ ਕਰੋ ਅਤੇ ਮੁੜ ਖੋਲ੍ਹੋ
ਮੁੜ ਆਪਣੇ ਐਪ 'ਤੇ ਜਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਹਾਲੇ ਵੀ ਲੌਗਇਨ ਹੋ

🎉 ਸਫਲਤਾ ਪ੍ਰਾਪਤ ਕੀਤੀ: ਤੁਸੀਂ ਸਫਲਤਾਪੂਰਵਕ persistent state management ਲਾਗੂ ਕਰ ਦਿੱਤੀ ਹੈ! ਹੁਣ ਤੁਹਾਡਾ ਐਪ ਇੱਕ ਪੇਸ਼ੇਵਰ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਵਾਂਗ ਵਰਤਦਾ ਹੈ।

Persistence ਅਤੇ Data Freshness ਦੇ ਵਿਚਕਾਰ ਸੰਤੁਲਨ

ਸਾਡਾ persistence ਸਿਸਟਮ ਸਫਲਤਾਪੂਰਵਕ ਯੂਜ਼ਰ ਸੈਸ਼ਨ ਨੂੰ ਬਣਾਈ ਰੱਖਦਾ ਹੈ, ਪਰ ਇੱਕ ਨਵਾਂ ਚੁਣੌਤੀ ਪੇਸ਼ ਕਰਦਾ ਹੈ: ਡਾਟਾ ਦੀ ਪੁਰਾਣੇ ਹੋਣ ਦੀ ਸਮੱਸਿਆ। ਜਦੋਂ ਕਈ ਯੂਜ਼ਰ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕੋ ਸਰਵਰ ਡਾਟਾ ਨੂੰ ਸੋਧਦੇ ਹਨ, ਤਾਂ ਸਥਾਨਕ cached ਜਾਣਕਾਰੀ ਪੁਰਾਣੀ ਹੋ ਜਾਂਦੀ ਹੈ।

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

🧪 Data Freshness ਦੀ ਸਮੱਸਿਆ ਦੀ ਖੋਜ:

test ਖਾਤੇ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਲੌਗਇਨ ਕਰੋ
ਇਸ ਕਮਾਂਡ ਨੂੰ ਟਰਮੀਨਲ ਵਿੱਚ ਚਲਾਓ ਤਾਂ ਕਿ ਕਿਸੇ ਹੋਰ ਸਰੋਤ ਤੋਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਨੂੰ simulate ਕੀਤਾ ਜਾ ਸਕੇ:

curl --request POST \
     --header "Content-Type: application/json" \
     --data "{ \"date\": \"2020-07-24\", \"object\": \"Bought book\", \"amount\": -20 }" \
     http://localhost:5000/api/accounts/test/transactions

ਆਪਣੇ ਬ੍ਰਾਊਜ਼ਰ ਪੇਜ ਨੂੰ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ
ਦੇਖੋ ਕਿ ਕੀ ਤੁਹਾਨੂੰ ਨਵੀਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ

ਇਹ ਟੈਸਟ ਕੀ ਦਰਸਾਉਂਦਾ ਹੈ:

ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ local storage "stale" (ਪੁਰਾਣਾ) ਹੋ ਸਕਦਾ ਹੈ
ਅਸਲੀ ਜ਼ਿੰਦਗੀ ਦੇ ਸਥਿਤੀਆਂ ਨੂੰ simulate ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਡਾਟਾ ਬਦਲਦਾ ਹੈ
Persistence ਅਤੇ Data Freshness ਦੇ ਵਿਚਕਾਰ ਤਣਾਅ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ

Data Staleness ਦੀ ਚੁਣੌਤੀ:

ਸਮੱਸਿਆ	ਕਾਰਨ	ਯੂਜ਼ਰ 'ਤੇ ਪ੍ਰਭਾਵ
ਪੁਰਾਣਾ ਡਾਟਾ	localStorage ਆਪਣੇ ਆਪ expire ਨਹੀਂ ਹੁੰਦਾ	ਯੂਜ਼ਰ ਪੁਰਾਣੀ ਜਾਣਕਾਰੀ ਦੇਖਦੇ ਹਨ
ਸਰਵਰ ਬਦਲਾਅ	ਹੋਰ ਐਪ/ਯੂਜ਼ਰ ਇੱਕੋ ਡਾਟਾ ਨੂੰ ਸੋਧਦੇ ਹਨ	ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਅਸੰਗਤ ਦ੍ਰਿਸ਼
Cache vs. Reality	ਸਥਾਨਕ cache ਸਰਵਰ ਸਟੇਟ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ	ਖਰਾਬ ਯੂਜ਼ਰ ਅਨੁਭਵ ਅਤੇ ਗੁੰਝਲ

ਸਮੱਸਿਆ ਦਾ ਹੱਲ:

ਅਸੀਂ "refresh on load" ਪੈਟਰਨ ਲਾਗੂ ਕਰਾਂਗੇ ਜੋ persistence ਦੇ ਫਾਇਦੇ ਨੂੰ ਤਾਜ਼ਾ ਡਾਟਾ ਦੀ ਲੋੜ ਨਾਲ ਸੰਤੁਲਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਸਹੀ ਡਾਟਾ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਜਦੋਂ ਕਿ smooth ਯੂਜ਼ਰ ਅਨੁਭਵ ਨੂੰ ਬਣਾਈ ਰੱਖਦੀ ਹੈ।

ਟਾਸਕ: Data Refresh System ਲਾਗੂ ਕਰੋ

ਅਸੀਂ ਇੱਕ ਸਿਸਟਮ ਬਣਾਵਾਂਗੇ ਜੋ ਸਰਵਰ ਤੋਂ ਤਾਜ਼ਾ ਡਾਟਾ ਆਪਣੇ ਆਪ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਸਾਡੇ persistent state management ਦੇ ਫਾਇਦੇ ਨੂੰ ਬਣਾਈ ਰੱਖਦਾ ਹੈ।

ਪਹਿਲਾ ਕਦਮ: Account Data Updater ਬਣਾਓ

async function updateAccountData() {
  const account = state.account;
  if (!account) {
    return logout();
  }

  const data = await getAccount(account.user);
  if (data.error) {
    return logout();
  }

  updateState('account', data);
}

ਇਸ ਫੰਕਸ਼ਨ ਦੇ ਲਾਜ਼ਿਕ ਨੂੰ ਸਮਝਣਾ:

ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਯੂਜ਼ਰ ਹਾਲੇ ਵੀ ਲੌਗਇਨ ਹੈ (state.account ਮੌਜੂਦ ਹੈ)
ਲੌਗਆਉਟ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ ਜੇ ਕੋਈ ਵੈਧ ਸੈਸ਼ਨ ਨਹੀਂ ਮਿਲਦਾ
ਤਾਜ਼ਾ ਖਾਤਾ ਡਾਟਾ ਸਰਵਰ ਤੋਂ ਲੈਂਦਾ ਹੈ ਮੌਜੂਦਾ getAccount() ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ
ਸਰਵਰ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਲ ਕਰਦਾ ਹੈ ਗਲਤ ਸੈਸ਼ਨ ਨੂੰ ਲੌਗਆਉਟ ਕਰਕੇ
ਤਾਜ਼ਾ ਡਾਟਾ ਨਾਲ ਸਟੇਟ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਸਾਡੇ ਨਿਯੰਤਰਿਤ ਅਪਡੇਟ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ
localStorage persistence ਨੂੰ ਆਪਣੇ ਆਪ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ updateState() ਫੰਕਸ਼ਨ ਰਾਹੀਂ

ਦੂਜਾ ਕਦਮ: Dashboard Refresh Handler ਬਣਾਓ

async function refresh() {
  await updateAccountData();
  updateDashboard();
}

ਇਹ refresh ਫੰਕਸ਼ਨ ਕੀ ਕਰਦਾ ਹੈ:

ਡਾਟਾ ਰੀਫ੍ਰੈਸ਼ ਅਤੇ UI ਅਪਡੇਟ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਸਾਂਝਾ ਕਰਦਾ ਹੈ
ਤਾਜ਼ਾ ਡਾਟਾ ਲੋਡ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ ਡਿਸਪਲੇਅ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ
ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਡੈਸ਼ਬੋਰਡ ਸਭ ਤੋਂ ਮੌਜੂਦਾ ਜਾਣਕਾਰੀ ਦਿਖਾਉਂਦਾ ਹੈ
ਡਾਟਾ ਮੈਨੇਜਮੈਂਟ ਅਤੇ UI ਅਪਡੇਟ ਦੇ ਵਿਚਕਾਰ ਸਾਫ਼ ਵੱਖਰਾ ਬਣਾਈ ਰੱਖਦਾ ਹੈ

ਤੀਜਾ ਕਦਮ: Route System ਨਾਲ ਇੰਟੀਗਰੇਟ ਕਰੋ

ਆਪਣੇ route configuration ਨੂੰ ਅਪਡੇਟ ਕਰੋ ਤਾਂ ਕਿ refresh ਆਪਣੇ ਆਪ ਟ੍ਰਿਗਰ ਹੋਵੇ:

const routes = {
  '/login': { templateId: 'login' },
  '/dashboard': { templateId: 'dashboard', init: refresh }
};

ਇਹ ਇੰਟੀਗਰੇਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ:

refresh ਫੰਕਸ਼ਨ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ ਹਰ ਵਾਰ ਜਦੋਂ ਡੈਸ਼ਬੋਰਡ route ਲੋਡ ਹੁੰਦਾ ਹੈ
ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਤਾਜ਼ਾ ਡਾਟਾ ਹਮੇਸ਼ਾ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਜਾਂਦੇ ਹਨ
ਮੌਜੂਦਾ route ਸਟ੍ਰਕਚਰ ਨੂੰ ਬਣਾਈ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਕਿ ਡਾਟਾ freshness ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ
route-specific initialization ਲਈ ਇੱਕ ਸਥਿਰ ਪੈਟਰਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ

ਤੁਹਾਡੀ Data Refresh System ਦੀ ਟੈਸਟਿੰਗ:

ਆਪਣੇ ਬੈਂਕਿੰਗ ਐਪ ਵਿੱਚ ਲੌਗਇਨ ਕਰੋ
ਪਹਿਲਾਂ ਦੀ curl ਕਮਾਂਡ ਚਲਾਓ ਤਾਂ ਕਿ ਨਵੀਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਬਣਾਈ ਜਾ ਸਕੇ
ਆਪਣੇ ਡੈਸ਼ਬੋਰਡ ਪੇਜ ਨੂੰ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ ਜਾਂ ਦੂਰ ਜਾਓ ਅਤੇ ਮੁੜ ਆਓ
ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਨਵੀਂ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਤੁਰੰਤ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ

🎉 ਸੰਤੁਲਨ ਪੂਰਾ ਕੀਤਾ: ਹੁਣ ਤੁਹਾਡਾ ਐਪ persistent state ਦੇ smooth ਅਨੁਭਵ ਨੂੰ ਤਾਜ਼ਾ ਸਰਵਰ ਡਾਟਾ ਦੀ ਸਹੀਤਾ ਨਾਲ ਜੋੜਦਾ ਹੈ!

GitHub Copilot Agent Challenge 🚀

Agent ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੇਠਾਂ ਦਿੱਤੇ ਚੈਲੈਂਜ ਨੂੰ ਪੂਰਾ ਕਰੋ:

ਵੇਰਵਾ: ਬੈਂਕਿੰਗ ਐਪ ਲਈ undo/redo functionality ਵਾਲਾ ਇੱਕ ਵਿਆਪਕ state management ਸਿਸਟਮ ਲਾਗੂ ਕਰੋ। ਇਹ ਚੈਲੈਂਜ state history tracking, immutable updates, ਅਤੇ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਸਮੇਤ ਉੱਚ-ਸਤਹ ਦੇ state management ਸੰਕਲਪਾਂ ਦਾ ਅਭਿਆਸ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ।

ਪ੍ਰੇਰਣਾ: ਇੱਕ ਵਧੇਰੇ state management ਸਿਸਟਮ ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੇ: 1) ਇੱਕ state history array ਜੋ ਸਾਰੇ ਪਿਛਲੇ ਸਟੇਟਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਦਾ ਹੈ, 2) Undo ਅਤੇ redo ਫੰਕਸ਼ਨ ਜੋ ਪਿਛਲੇ ਸਟੇਟਾਂ 'ਤੇ ਵਾਪਸ ਜਾ ਸਕਦੇ ਹਨ, 3) ਡੈਸ਼ਬੋਰਡ 'ਤੇ undo/redo operations ਲਈ UI ਬਟਨ, 4) ਮੈਮਰੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੋਕਣ ਲਈ 10 ਸਟੇਟਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ history ਸੀਮਾ, ਅਤੇ 5) ਯੂਜ਼ਰ ਲੌਗਆਉਟ ਕਰਨ 'ਤੇ history ਦੀ ਸਹੀ ਸਫਾਈ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ undo/redo functionality ਖਾਤੇ ਦੇ ਬੈਲੈਂਸ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਰੀਫ੍ਰੈਸ਼ ਦੇ ਪਾਰ ਰਹਿੰਦੀ ਹੈ।

agent mode ਬਾਰੇ ਹੋਰ ਜਾਣੋ।

🚀 ਚੈਲੈਂਜ: Storage Optimization

ਤੁਹਾਡੀ implementation ਹੁਣ ਯੂਜ਼ਰ ਸੈਸ਼ਨ, ਡਾਟਾ ਰੀਫ੍ਰੈਸ਼, ਅਤੇ state management ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਲ ਕਰਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਸੋਚੋ ਕਿ ਕੀ ਸਾਡਾ ਮੌਜੂਦਾ ਪਹੁੰਚ storage efficiency ਨੂੰ functionality ਨਾਲ ਸੰਤੁਲਿਤ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਲ ਕਰਦਾ ਹੈ।

ਜਿਵੇਂ ਸ਼ਤਰੰਜ ਦੇ ਮਾਹਰ ਜ਼ਰੂਰੀ ਟੁਕੜਿਆਂ ਅਤੇ ਬੇਕਾਰ ਪਿਦਾਂ ਵਿੱਚ ਫਰਕ ਕਰਦੇ ਹਨ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ state management ਲਈ ਇਹ ਪਛਾਣ ਕਰਨੀ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਕਿਹੜਾ ਡਾਟਾ ਸਟੋਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਹੜਾ ਹਮੇਸ਼ਾ ਸਰਵਰ ਤੋਂ ਤਾਜ਼ਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

Optimization Analysis:

ਤੁਹਾਡੇ ਮੌਜੂਦਾ localStorage implementation ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ ਅਤੇ ਇਹ ਰਣਨੀਤਿਕ ਸਵਾਲਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰੋ:

ਯੂਜ਼ਰ authentication ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਘੱਟੋ-ਘੱਟ ਜਾਣਕਾਰੀ ਕੀ ਹੈ?
ਕਿਹੜਾ ਡਾਟਾ ਇੰਨਾ ਵਧੇਰੇ ਬਦਲਦਾ ਹੈ ਕਿ ਸਥਾਨਕ caching ਦਾ ਕੋਈ ਫਾਇਦਾ ਨਹੀਂ ਹੈ?
ਸਟੋਰੇਜ optimization ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਨਾਂ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨੂੰ ਘਟਾਏ ਕਿਵੇਂ ਸੁਧਾਰ ਸਕਦਾ ਹੈ?

ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਆਰਕੀਟੈਕਚਰਲ ਮੁਲਾਂਕਣ ਉਹਨਾਂ ਅਨੁਭਵੀ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਦਾ ਹੈ ਜੋ ਆਪਣੇ ਹੱਲਾਂ ਵਿੱਚ functionality ਅਤੇ efficiency ਦੋਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹਨ।

Implementation Strategy:

ਪਛਾਣ ਕਰੋ ਜਰੂਰੀ ਡਾਟਾ ਜੋ ਸਟੋਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਸ਼ਾਇਦ ਸਿਰਫ ਯੂਜ਼ਰ ਪਛਾਣ)
localStorage implementation ਨੂੰ ਸੋਧੋ ਤਾਂ ਕਿ ਸਿਰਫ਼ ਮਹੱਤਵਪੂਰਨ ਸੈਸ਼ਨ ਡਾਟਾ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇ
ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤਾਜ਼ਾ ਡਾਟਾ ਹਮੇਸ਼ਾ ਡੈਸ਼ਬੋਰਡ ਦੌਰੇ 'ਤੇ ਸਰਵਰ ਤੋਂ ਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
ਟੈਸਟ ਕਰੋ ਕਿ ਤੁਹਾਡਾ optimized ਪਹੁੰਚ ਉਹੀ ਯੂਜ਼ਰ ਅਨੁਭਵ ਬਣਾਈ ਰੱਖਦਾ ਹੈ

Advanced Consideration:

ਤੁਲਨਾ ਕਰੋ ਪੂਰੇ ਖਾਤੇ ਦੇ ਡਾਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਸਿਰਫ਼ authentication tokens ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੇ ਵਿਚਕਾਰ trade-offs
ਆਪਣੇ ਫੈਸਲੇ ਅਤੇ ਕਾਰਨ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਭਵਿੱਖ ਦੇ ਟੀਮ ਮੈਂ

ਅਸਵੀਕਰਤਾ:
ਇਹ ਦਸਤਾਵੇਜ਼ AI ਅਨੁਵਾਦ ਸੇਵਾ Co-op Translator ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਦੋਂ ਕਿ ਅਸੀਂ ਸਹੀ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਸਵੈਚਾਲਿਤ ਅਨੁਵਾਦਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਜਾਂ ਅਸੁੱਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਮੂਲ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਇਸਦੀ ਮੂਲ ਭਾਸ਼ਾ ਵਿੱਚ ਅਧਿਕਾਰਤ ਸਰੋਤ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਜਾਣਕਾਰੀ ਲਈ, ਪੇਸ਼ੇਵਰ ਮਨੁੱਖੀ ਅਨੁਵਾਦ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਅਨੁਵਾਦ ਦੀ ਵਰਤੋਂ ਤੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਗਲਤਫਹਿਮੀ ਜਾਂ ਗਲਤ ਵਿਆਖਿਆ ਲਈ ਅਸੀਂ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ ਹਾਂ।

40 KiB Raw Blame History