13 KiB

Raw Blame History

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

ਲੈਕਚਰ ਤੋਂ ਪਹਿਲਾਂ ਕਵੀਜ਼

ਪਰਿਚਯ

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

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

ਪੂਰਵ ਸ਼ਰਤ

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

ਤੁਸੀਂ ਟਰਮਿਨਲ ਵਿੱਚ ਇਹ ਕਮਾਂਡ ਚਲਾ ਕੇ ਜਾਂਚ ਸਕਦੇ ਹੋ ਕਿ ਸਰਵਰ ਠੀਕ ਤਰ੍ਹਾਂ ਚੱਲ ਰਿਹਾ ਹੈ:

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

ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਦੁਬਾਰਾ ਸੋਚੋ

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

ਮੌਜੂਦਾ ਕੋਡ ਵਿੱਚ 3 ਸਮੱਸਿਆਵਾਂ ਹਨ:

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

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

ਅਸੀਂ ਇੱਥੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ?

ਸਟੇਟ ਮੈਨੇਜਮੈਂਟ ਦਾ ਸਾਰ ਇਹ ਹੈ ਕਿ ਇਨ੍ਹਾਂ ਦੋ ਖਾਸ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਇੱਕ ਵਧੀਆ ਪਹੁੰਚ ਲੱਭੀ ਜਾਵੇ:

ਐਪ ਵਿੱਚ ਡਾਟਾ ਫਲੋਜ਼ ਨੂੰ ਸਮਝਣਯੋਗ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ?
ਸਟੇਟ ਡਾਟਾ ਨੂੰ ਹਮੇਸ਼ਾ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ ਦੇ ਨਾਲ (ਅਤੇ ਇਸਦੇ ਉਲਟ) ਕਿਵੇਂ ਸਿੰਕ ਵਿੱਚ ਰੱਖਣਾ ਹੈ?

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

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

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

ਕੰਮ

ਅਸੀਂ ਕੁਝ ਰੀਫੈਕਟੋਰਿੰਗ ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗੇ। account ਡਿਕਲੇਅਰਸ਼ਨ ਨੂੰ ਬਦਲੋ:

let account = null;

ਇਸ ਨਾਲ:

let state = {
  account: null
};

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

ਸਾਨੂੰ ਇਸਨੂੰ ਵਰਤਣ ਵਾਲੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਵੀ ਅੱਪਡੇਟ ਕਰਨਾ ਪਵੇਗਾ। register() ਅਤੇ login() ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ, account = ... ਨੂੰ state.account = ... ਨਾਲ ਬਦਲੋ;

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

const account = state.account;

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

ਡਾਟਾ ਬਦਲਾਵਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ

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

state ਆਬਜੈਕਟ ਵਿੱਚ ਬਦਲਾਵਾਂ ਕਰਨ ਤੋਂ ਬਚਣ ਲਈ, ਇਸਨੂੰ immutable ਮੰਨਣਾ ਵੀ ਇੱਕ ਵਧੀਆ ਅਭਿਆਸ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸਨੂੰ ਬਿਲਕੁਲ ਵੀ ਬਦਲਾ ਨਹੀਂ ਜਾ ਸਕਦਾ। ਪੋਸਟ-ਲੈਕਚਰ ਕਵਿਜ਼

ਅਸਾਈਨਮੈਂਟ

"Add transaction" ਡਾਇਲਾਗ ਨੂੰ ਲਾਗੂ ਕਰੋ

ਇਹ ਰੂਪ ਰੇਖਾ ਅਸਾਈਨਮੈਂਟ ਪੂਰੀ ਕਰਨ ਤੋਂ ਬਾਅਦ ਦਾ ਉਦਾਹਰਨ ਹੈ:

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

13 KiB Raw Blame History