React ਦੇ ਮੈਨਟਲ ਮਾਡਲ React ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ: components, rendering, state ਅਤੇ effects ਦੇ ਮੁੱਖ ਖ਼ਿਆਲ ਸਿੱਖੋ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਕੇ chat ਰਾਹੀਂ ਤੇਜ਼ UI ਬਣਾਓ।

ਸ਼ੁਰੂ ਵਿੱਚ React ਚਿੰਤਾਜਨਕ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ UI ਦੇ ਬਦਲਾਅ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਪਰ ਹਮੇਸ਼ਾ ਸਮਝ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਉਹ ਕਿਉਂ ਬਦਲਿਆ। ਤੁਸੀਂ ਇੱਕ ਬਟਨ 'ਤੇ ਕਲਿਕ ਕਰਦੇ ਹੋ, ਕੁਝ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਪੇਜ਼ ਦਾ ਕਿਸੇ ਹੋਰ ਹਿੱਸੇ ਨੇ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰ ਦਿੱਤਾ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ “React ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ ਹੈ” ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਹੈ “ਮੇਰੀ ਸੋਚ React ਦੇ ਕੰਮ ਕਰਨ ਬਾਰੇ ਧੁੰਦਲੀ ਹੈ।”
ਮੈਨਟਲ ਮਾਡਲ ਉਹ ਸਧਾਰਣ ਕਹਾਣੀ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਮਨ ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ ਕਿ ਕੋਈ ਚੀਜ਼ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਜੇ ਕਹਾਣੀ ਗਲਤ ਹੋਵੇ, ਤੁਸੀਂ ਪੱਕੇ ਫੈਸਲੇ ਕਰੋਗੇ ਜੋ ਗੁੰਝਲਦਾਰ ਨਤੀਜੇ ਲਿਆਉਂਦੇ ਹਨ। ਇੱਕ thermostat ਦੀ ਸੋਚੋ: ਖਰਾਬ ਮਾਡਲ ਇਹ ਹੋ ਸਕਦਾ ਹੈ “ਮੈਂ 22°C ਸੈੱਟ ਕੀਤਾ, ਤਾਂ ਕਮਰਾ ਤੁਰੰਤ 22°C ਹੋ ਗਿਆ।” ਇੱਕ ਚੰਗਾ ਮਾਡਲ ਇਹ ਹੈ “ਮੈਂ ਇਕ ਟਾਰਗੇਟ ਰੱਖਿਆ, ਅਤੇ ਹੀਟਰ ਸਮੇਂ ਦੇ ਨਾਲ ਚੱਲਦਾ/ਰੁਕਦਾ ਹੈ ਤਾਂ ਜੋ ਟਾਰਗੇਟ ਮਿਲ ਸਕੇ।” ਚੰਗੀ ਕਹਾਣੀ ਨਾਲ ਵਰਤਾਰਾ random ਨਹੀਂ ਲੱਗਦਾ।
React ਵੀ ਇਹੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ ਸਾਫ਼ ਵਿਚਾਰ ਅਪਣਾ ਲੈਂਦੇ ਹੋ, React ਅਨੁਮਾਨਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਮੌਜੂਦਾ ਡੇਟਾ ਨੂੰ ਦੇਖ ਕੇ ਭਰੋਸੇ ਨਾਲ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਸਕ੍ਰੀਨ 'ਤੇ ਕੀ ਹੋਵੇਗਾ।
Dan Abramov ਨੇ ਇਸ “ਅਨੁਮਾਨਯੋਗ ਬਣਾਓ” ਸੋਚ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ। ਉਦੇਸ਼ ਕਿਸੇ ਨਿਯਮ ਨੂੰ ਯਾਦ ਕਰਨਾ ਨਹੀਂ—ਬਲਕਿ ਆਪਣੇ ਮਨ ਵਿੱਚ ਕੁਝ ਛੋਟੀਆਂ ਸੱਚਾਈਆਂ ਰੱਖਣੀਆਂ ਹਨ ਤਾਂ ਜੋ ਤੁਸੀਂ reasoning ਨਾਲ bug-fix ਕਰ ਸਕੋ, trial-and-error ਨਾਲ ਨਹੀਂ।
ਇਨ੍ਹਾਂ ਵਿਚਾਰਾਂ ਨੂੰ ਆਪਣੇ ਅਗੇ ਰੱਖੋ:
ਇਨ੍ਹਾਂ ਨੂੰ ਫੜ ਲਓ ਅਤੇ React ਜਾਦੂ ਵਰਗਾ ਨਹੀਂ ਰਹੇਗਾ—ਇਹ ਇੱਕ ਸਿਸਟਮ ਵਰਗਾ ਮਹਿਸੂਸ ਹੋਏਗਾ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ।
React ਸੌਖਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ “ਸਕ੍ਰੀਨ” ਸੋਚਣਾ ਛੱਡ ਕੇ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿਚ ਸੋਚਦੇ ਹੋ। ਇੱਕ component UI ਦਾ ਦੁਹਰਾਯੋਗ ਅੰਸ਼ ਹੈ। ਇਹ inputs ਲੈਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ inputs ਲਈ UI ਦਾ ਵਰਣਨ ਵਾਪਸ ਕਰਦਾ ਹੈ।
ਇੱਕ component ਨੂੰ ਇਕ pure description ਵਾਂਗ ਲੈਣਾ ਫਾਇਦੇਮੰਦ ਹੁੰਦਾ ਹੈ: “ਇਸ ਡੇਟਾ ਦਿੱਤੀ ਹੈ ਤਾਂ ਇਹ ਦਿਖਾਓ।” ਇਹ ਵਰਣਨ ਕਈ ਥਾਵਾਂ ਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਆਪਣੇ ਰਹਿਣ-ਸਥਾਨ ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦਾ।
Props ਉਹ inputs ਹਨ। ਉਹ ਪੈਰੈਂਟ component ਵੱਲੋਂ ਆਉਂਦੇ ਹਨ। Props ਕੰਪੋਨੈਂਟ ਦੇ “ਮਲਕ” ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ ਇਹ ਉਹ ਚੀਜ਼ ਨਹੀਂ ਜੋ ਕੰਪੋਨੈਂਟ ਚੁੱਪ ਚਾਪ ਬਦਲ ਦੇਵੇ। ਜੇ ਇੱਕ ਬਟਨ ਨੂੰ label="Save" ਮਿਲਦਾ ਹੈ, ਤਾਂ ਬਟਨ ਦਾ ਕੰਮ ਉਹ label ਰੇਂਡਰ ਕਰਨਾ ਹੈ, ਫੈਸਲਾ ਕਰਨਾ ਨਹੀਂ ਕਿ ਇਹ ਵੱਖਰਾ ਹੋਵੇ।
State ਮਲਕੀਅਤ ਵਾਲਾ ਡੇਟਾ ਹੈ। ਇਹ ਉਹ ਹੈ ਜੋ ਕੰਪੋਨੈਂਟ ਸਮੇਂ ਦੇ ਨਾਲ ਯਾਦ ਰੱਖਦਾ ਹੈ। State ਉਸ ਵੇਲੇ ਬਦਲਦੀ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕੋਈ ਬੇਨਤੀ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਕੁਝ ਵੱਖਰਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। Props ਦੇ ਉਲਟ, state ਉਸ ਕੰਪੋਨੈਂਟ (ਜਾਂ ਜਿਸ ਕੰਪੋਨੈਂਟ ਨੂੰ ਤੁਸੀਂ ਮਾਲਕ ਬਣਾਉਂਦੇ ਹੋ) ਦੀ ਹੈ।
ਮੁੱਖ ਵਿਚਾਰ ਦਾ ਸਧਾਰਣ ਰੂਪ: UI state ਦਾ ਫੰਗਸ਼ਨ ਹੈ। ਜੇ state ਕਹੇ “loading,” ਤਾਂ spinner ਦਿਖਾਓ। ਜੇ state ਕਹੇ “error,” ਤਾਂ ਸੁਨੇਹਾ ਦਿਖਾਓ। ਜੇ state ਕਹੇ “items = 3,” ਤਾਂ ਤਿੰਨ ਸਤਰਾਂ ਰੇਂਡਰ ਕਰੋ। ਤੁਹਾਡਾ ਕੰਮ UI ਨੂੰ state ਤੋਂ ਪੜ੍ਹਕੇ ਰੱਖਣਾ ਹੈ, ਨਾ ਕਿ ਛੁਪੇ ਹੋਏ ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ ਭਟਕਣਾ।
ਸੰਖੇਪ ਰੂਪ:
SearchBox, ProfileCard, CheckoutForm)name, price, disabled)isOpen, query, selectedId)ਉਦਾਹਰਨ: ਇੱਕ modal। ਪੈਰੈਂਟ title ਅਤੇ onClose props ਵਜੋਂ ਪਾਸ ਕਰ ਸਕਦਾ ਹੈ। modal isAnimating ਨੂੰ state ਵਜੋਂ ਰੱਖ ਸਕਦਾ ਹੈ।
ਜੀਤੋਂ ਤੱਕ ਤੁਸੀਂ chat ਰਾਹੀਂ UI ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ Koder.ai), ਇਹ ਵਿਭਾਜਨ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ: ਪਹਿਲਾਂ props vs state ਨਿਰਧਾਰਿਤ ਕਰੋ, ਫਿਰ UI ਨੂੰ ਅਨੁਸਰਣ ਕਰਨ ਦਿਓ।
React ਨੂੰ ਆਪਣੇ ਮਨ ਵਿੱਚ ਰੱਖਣ ਲਈ ਇੱਕ ਵਰਤੋਂਯੋਗ ਤਰੀਕਾ (ਬਹੁਤ Dan Abramov ਦੀ ਰੂਹ ਵਿੱਚ) ਇਹ ਹੈ: rendering ਇਕ ਹਿਸਾਬ ਹੈ, ਇੱਕ paint-ਜਾਬ ਨਹੀਂ। React ਤੁਹਾਡੀਆਂ component functions ਚਲਾਉਂਦਾ ਹੈ ਤਾਂ ਜੋ ਮੌਜੂਦਾ props ਅਤੇ state ਲਈ UI ਕੀ ਹੋਵੇਗਾ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕੇ। ਨਿਕਾਸ pixels ਨਹੀਂ ਹਨ, UI ਦਾ ਵਰਣਨ ਹੈ।
ਰੀ-ਰੇਂਡਰ ਦਾ ਮਤਲਬ ਸਿਰਫ ਇਹ ਹੈ ਕਿ React ਉਸ ਹਿਸਾਬ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ “ਸਾਰਾ ਪੇਜ ਫੇਰੋਂ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੈ।” React ਨਵੇਂ ਨਤੀਜੇ ਨੂੰ ਪਿਛਲੇ ਨਾਲ ਤੁਲਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਸੱਚੇ DOM 'ਤੇ ਸਭ ਤੋਂ ਛੋਟਾ ਬਦਲਾਅ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ components ਰੀ-ਰੇਂਡਰ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਸਿਰਫ ਕੁਝ DOM ਨੋਡ ਅਪਡੇਟ ਹੋਂਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ re-renders ਕੁਝ ਆਸਾਨ ਕਾਰਨਾਂ ਕਰਕੇ ਹੁੰਦੇ ਹਨ: ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਦੀ state ਬਦਲੀ, ਉਸਦੇ props ਬਦਲੇ, ਜਾਂ ਕੋਈ ਪੈਰੈਂਟ ਰੀ-ਰੇਂਡਰ ਹੋਇਆ ਅਤੇ React ਨੇ ਚਾਇਲ્ડ ਨੂੰ ਮੁੜ render ਕਰਨ ਲਈ ਪੁਕਾਰਿਆ। ਆਖਰੀ ਵਾਰ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ ਤੇ ਇਹ ਠੀਕ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ render ਨੂੰ “ਸਸਤਾ ਤੇ ਨਿਰਾਸ਼ਾਜਨਕ” ਸਮਝਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੀ ਐਪ ਸੋਚਣ ਲਈ ਆਸਾਨ ਰਹੇਗੀ।
ਇਕ ਨਿਯਮ ਜੋ ਇਸਨੂੰ ਸਾਫ ਰੱਖਦਾ ਹੈ: render ਨੂੰ pure ਬਣਾਓ। ਇੱਕੋ inputs (props + state) ਦਿੰਦਿਆਂ, ਤੁਹਾਡੀ component ਨੂੰ ਇੱਕੋ UI ਵਰਣਨ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। render ਵਿੱਚ ਅਚਮਕੇ ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ।
ਨਿਰਮਾਣੀ ਉਦਾਹਰਨ: ਜੇ ਤੁਸੀਂ render ਵਿੱਚ Math.random() ਨਾਲ ID ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ re-render ਇਸ ਨੂੰ ਬਦਲ ਦੇਵੇਗਾ ਅਤੇ ਅਚਾਨਕ checkbox focus ਖੋ ਦੇਵੇਗਾ ਜਾਂ list item remount ਹੋ ਜਾਵੇਗਾ। ID ਨੂੰ ਇੱਕ ਵਾਰੀ ਬਣਾਓ (state, memo, ਜਾਂ component ਤੋਂ ਬਾਹਰ) ਤਾਂ ਜੋ render ਸਥਿਰ ਰਹੇ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਕਯਾਦ ਰੱਖੋ: re-render ਦਾ ਮਤਲਬ ਹੈ “UI ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਮੁੜਕੰਪਿyੂਟ ਕਰੋ,” ਨਾ ਕਿ “ਹਰ ਚੀਜ਼ ਨੂੰ ਮੁੜਤਿਆਰ ਕਰੋ।”
ਇਕ ਹੋਰ ਮਦਦਗਾਰ ਮਾਡਲ: state ਅਪਡੇਟ ਇੱਕ ਬੇਨਤੀ ਹੁੰਦੀ ਹੈ, ਤੁਰੰਤ ਅਸਾਈਨਮੈਂਟ ਨਹੀਂ। ਜਦ ਤੁਸੀਂ setCount(count + 1) ਕਾਲ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ React ਨੂੰ ਨਵਾਂ ਮੁੱਲ ਸ਼ੈਡਿਊਲ ਕਰਨ ਦੀ ਬੇਨਤੀ ਕਰ ਰਹੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਫੌਰਨ state ਪੜ੍ਹਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਪੁਰਾਣਾ ਮੁੱਲ ਹੀ ਮਿਲ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ React ਨੇ ਅਜੇ render ਨਹੀਂ ਕੀਤਾ।
ਇਸ ਲਈ “ਛੋਟੇ ਅਤੇ ਅਨੁਮਾਨਯੋਗ” ਅਪਡੇਟ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਜਦ ਨਵਾਂ ਮੁੱਲ ਪਿਛਲੇ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਤਾਂ updater ਫਾਰਮ ਵਰਤੋ: setCount(c => c + 1). ਇਹ React ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕੇ ਨਾਲ ਮਿਲਦਾ ਹੈ: ਕਈ ਅਪਡੇਟ ਕਤਾਰ ਵਿੱਚ ਹੋ ਸਕਦੇ ਹਨ, ਫਿਰ ਅਨੁਕ੍ਰਮ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।
Immutability ਇਸ ਤਸਵੀਰ ਦਾ ਦੂਜਾ ਹਿੱਸਾ ਹੈ। objects ਤੇ arrays ਨੂੰ ਥਾਂ-ਥਾਂ ਬਦਲੋ ਨਹੀਂ। ਬਦਲੇ ਹੋਏ ਨਵੇਂ object ਜਾਂ array ਬਣਾਓ। ਫਿਰ React ਦੇਖ ਸਕਦਾ ਹੈ “ਇਹ ਮੁੱਲ ਨਵਾਂ ਹੈ,” ਅਤੇ ਤੁਹਾਡਾ ਮਨ ਟ੍ਰੇਸ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ।
ਉਦਾਹਰਨ: ਇੱਕ todo item ਨੂੰ toggle ਕਰਨਾ। ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਨਵਾਂ array ਅਤੇ ਸੋਧਿਆ ਹੋਇਆ todo object ਬਣਾਇਆ ਜਾਵੇ। ਖਤਰਨਾਕ ਤਰੀਕਾ ਹੈ todo.done = !todo.done ਮੌਜੂਦਾ array ਵਿੱਚ ਖੁਦ ਬਦਲਾਅ ਕਰਨ ਦੀ।
ਇਸ ਦੇ ਨਾਲ-ਨਾਲ state ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਰੱਖੋ। ਆਮ ਫੰਦਾ ਉਹ ਹੈ ਜੋ ਉਨ੍ਹਾਂ ਮੁੱਲਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਜੋ ਤੁਸੀਂ ਕਲਕੁਲੇਟ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ items ਅਤੇ filter ਹਨ, ਤਾਂ filteredItems ਨੂੰ state ਵਿੱਚ ਰੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਇਹ render ਦੌਰਾਨ ਕੈਲਕੁਲੇਟ ਕਰੋ। ਘੱਟ state ਵੈਰੀਏਬਲ ਦਾ ਮਤਲਬ ਘੱਟ ਰਾਹ ਹਨ ਜਿੱਥੇ ਮੁੱਲ sync ਤੋਂ ਬਾਹਰ ਹੋ ਸਕਦੇ ਹਨ।
ਇਕ ਸਧਾਰਣ ਟੈਸਟ ਕਿ ਕੀ state ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ:
ਜੇ ਤੁਸੀਂ chat ਰਾਹੀਂ UI ਬਣਾ ਰਹੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ Koder.ai), ਤਾਂ ਬਦਲਾਅ ਛੋਟੇ ਪੈਚਾਂ ਵਾਂਗ ਮੰਗੋ: “ਇੱਕ boolean ਫਲੇਗ ਜੋੜੋ” ਜਾਂ “ਇਸ ਲਿਸਟ ਨੂੰ immutable ਤਰੀਕੇ ਨਾਲ ਅਪਡੇਟ ਕਰੋ।” ਛੋਟੇ, ਵਿਸ਼ੇਸ਼ ਬਦਲਾਅ generator ਅਤੇ ਤੁਹਾਡੇ React ਕੋਡ ਨੂੰ aligned ਰੱਖਦੇ ਹਨ।
Rendering UI ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। Effects ਬਾਹਰੀ ਦੁਨੀਆ ਨਾਲ sync ਕਰਨ ਲਈ ਹਨ। “ਬਾਹਰ” ਨਾਲ ਮੁਰਾਦ ਉਹ ਚੀਜ਼ਾਂ ਜੋ React ਦੇ ਨਿਯੰਤਰਣ ਵਿੱਚ ਨਹੀਂ: network calls, timers, browser APIs, ਅਤੇ ਕਦੇ-ਕਦੇ imperative DOM ਕੰਮ।
ਜੇ ਕੋਈ ਚੀਜ਼ props ਅਤੇ state ਤੋਂ ਕੈਲਕੁਲੇਟ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਤਾਂ ਅਕਸਰ ਉਹ effect ਵਿੱਚ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। Effect ਵਿੱਚ ਰੱਖਣ ਨਾਲ ਇੱਕ ਦੂਜਾ ਕਦਮ ਆ ਜਾਂਦਾ ਹੈ (render, effect ਚਲਾਉ, state ਸੈੱਟ ਕਰੋ, ਫੇਰ render)। ਇਹ ਵਾਧੂ ਕਦਮ flickers, loops, ਅਤੇ “ਇਹ stale ਕਿਉਂ ਹੈ?” ਵਰਗੀਆਂ ਬੱਗਾਂ ਨੂੰ جنم ਦਿੰਦਾ ਹੈ।
ਆਮ ਗਲਤਫਹਮੀ: ਤੁਹਾਡੇ ਕੋਲ firstName ਅਤੇ lastName ਹਨ, ਅਤੇ ਤੁਸੀਂ fullName state ਵਿੱਚ effect ਦੀ مدد ਨਾਲ ਰੱਖ ਰਹੇ ਹੋ। ਪਰ fullName ਕੋਈ side effect ਨਹੀਂ—ਇਹ derived data ਹੈ। render ਦੌਰਾਨ ਕੈਲਕੁਲੇਟ ਕਰੋ ਅਤੇ ਇਹ ਹਮੇਸ਼ਾ ਮੇਲ ਖਾਏਗਾ।
ਆਦਤ ਵਜੋਂ: UI ਮੁੱਲ render ਦੌਰਾਨ (ਜਾਂ ਜੇ ਰੀਸੋਰਸ-ਭਾਰ ਹੋਵੇ ਤਾਂ useMemo ਨਾਲ) ਡੈਰੀਵ ਕਰੋ, ਅਤੇ effects ਨੂੰ “ਕੋਈ ਕੰਮ ਕਰੋ” ਵਰਗੇ ਕੰਮ ਲਈ ਰੱਖੋ, ਨਾ ਕਿ “ਕੋਈ ਗੱਲ ਨਿਰਧਾਰਿਤ ਕਰੋ” ਲਈ।
dependency array ਨੂੰ ਇਹ ਸਮਝੋ: “ਜਦੋਂ ਇਹ ਮੁੱਲ ਬਦਲਦੇ ਹਨ, ਬਾਹਰ ਦੀ ਦੁਨੀਆ ਨਾਲ ਮੁੜ sync ਕਰੋ।” ਇਹ ਕੋਈ performance ਟਰਿਕ ਨਹੀਂ ਅਤੇ ਨਾ ਹੀ warnings ਨੂੰ ਦਬਾਉਣ ਲਈ ਥਾਂ ਹੈ।
ਉਦਾਹਰਨ: ਜੇ ਤੁਸੀਂ userId ਬਦਲਦਿਆਂ user details fetch ਕਰਦੇ ਹੋ, ਤਾਂ userId dependency array ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ sync ਨੂੰ trigger ਕਰਦਾ ਹੈ। ਜੇ effect token ਵੀ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਵੀ ਸ਼ਾਮਲ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਪੁਰਾਣੇ token ਨਾਲ fetch ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਚੰਗਾ ਗੁਟ-ਚੈੱਕ: ਜੇ effect ਹਟਾਉਣ ਨਾਲ UI ਸਿਰਫ ਗਲਤ ਹੋ ਜਾਵੇ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ effect ਨਹੀਂ ਸੀ। ਜੇ ਹਟਾਉਣ ਨਾਲ timer ਬੰਦ ਹੋ ਜਾਵੇ, subscription cancel ਹੋ ਜਾਵੇ, ਜਾਂ fetch ਛੁੱਟ ਜਾਵੇ, ਤਾਂ ਇਹ ਪ੍ਰਬੰਧਕ effect ਸੀ।
ਇੱਕ ਸਭ ਤੋਂ ਮ útil ਮੈਨਟਲ ਮਾਡਲ ਸਧਾਰਨ ਹੈ: ਡਾਟਾ ਟ੍ਰੀ ਵਿੱਚ ਹੇਠਾਂ ਵਹਿੰਦਾ ਹੈ, ਅਤੇ ਯੂਜ਼ਰ ਕਿਰਿਆਵਾਂ ਉੱਪਰ ਵੱਲ ਜਾਂਦੀਆਂ ਹਨ।
ਪੈਰੈਂਟ ਬੱਚਿਆਂ ਨੂੰ ਮੁੱਲ ਪਾਸ ਕਰਦਾ ਹੈ। ਬੱਚਿਆਂ ਨੂੰ ਚੋਪ-ਚਾਪ ਇੱਕੋ ਮੁੱਲ ਦੋ ਥਾਵਾਂ "owned" ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਉਹ ਬਦਲਾਅ ਦੀ ਬੇਨਤੀ ਫੰਕਸ਼ਨ ਕਰਕੇ ਕਰਦੇ ਹਨ, ਅਤੇ ਪੈਰੈਂਟ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਨਵਾਂ ਮੁੱਲ ਕੀ ਹੋਵੇ।
ਜਦੋਂ UI ਦੇ ਦੋ ਹਿੱਸੇ ਨੂੰ ਸਹਿਮਤ ਰਹਿਣਾ ਲਾਜ਼ਮੀ ਹੋਵੇ, ਇੱਕ ਥਾਂ ਚੁਣੋ ਜਿੱਥੇ ਮੁੱਲ ਰੱਖਿਆ ਜਾਵੇ ਅਤੇ ਫਿਰ ਥੱਲੇ ਪਾਸ ਕਰੋ। ਇਹ "lifting state" ਹੈ। ਇਹ ਕੁਝ ਹੱਦ ਤੱਕ ਪਲੰਬਿੰਗ ਵਰਗਾ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਇਕ ਹੋਰ ਸਮੱਸਿਆ ਨੂੰ ਰੋਕਦਾ ਹੈ: ਦੋ states ਜੋ ਇੱਕ-दੂਜੇ ਤੋਂ ਡਰਿਫਟ ਕਰ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ sync ਰੱਖਣ ਲਈ ਹੈਕਜ਼ ਜੋੜਣੇ ਪੈਂਦੇ ਹਨ।
ਉਦਾਹਰਨ: ਇੱਕ search box ਅਤੇ results list। ਜੇ input ਆਪਣੀ query ਰੱਖਦਾ ਹੈ ਅਤੇ list ਆਪਣੀ query ਰੱਖਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਖ਼ਿਰਕਾਰ ਵੇਖੋਗੇ “input X ਦਿਖਾ ਰਿਹਾ ਹੈ ਪਰ list Y ਵਰਤ ਰਹੀ ਹੈ।” ਇਸਦਾ ਠੀਕ ਤਰੀਕਾ ਹੈ ਕਿ query ਇੱਕ parent ਵਿੱਚ ਰੱਖੋ, ਦੋਹਾਂ ਨੂੰ ਪਾਸ ਕਰੋ, ਅਤੇ input ਨੂੰ onChangeQuery(newValue) ਹੇਠਾਂ ਤੋਂ callback ਦਿਓ।
ਹਮੇਸ਼ਾ state ਲਿਫਟ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਜੇ ਕੋਈ ਮੁੱਲ ਸਿਰਫ ਇਕ ਕੰਪੋਨੈਂਟ ਦੇ ਅੰਦਰ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਓਥੇ ਹੀ ਰੱਖੋ। state ਨੂੰ ਉਥੇ ਨਜ਼ਦੀਕ ਰੱਖਣਾ ਆਮ ਤੌਰ ਤੇ ਕੋਡ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਨਾਉਂਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬਾਊਂਡਰੀ:
ਜੇ ਤੁਹਾਨੂੰ ਹਾਲ ਨਹੀਂ ਪਤਾ ਕਿ state ਲਿਫਟ ਕਰਨੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਤਦ ਹੇਠਾਂ ਦੇ ਸਿਗਨਲ ਵੇਖੋ: ਦੋ components ਇੱਕੋ ਮੁੱਲ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾ ਰਹੇ ਹਨ; ਇੱਕ ਜਗ੍ਹਾ ਤੇ action ਦੁਜੇ ਦੂਰ ਅਪਡੇਟ ਨੂੰ ਕਾਰਨ ਬਣ ਰਿਹਾ ਹੈ; ਤੁਸੀਂ props ਨੂੰ state ਵਿੱਚ "ਸਿਰਫ਼ ਸੰਭਾਲਣ ਲਈ" ਕਾਪੀ ਕਰ ਰਹੇ ਹੋ; ਜਾਂ ਤੁਸੀਂ ਦੋ ਮੁੱਲਾਂ ਨੂੰ ਰੱਖਣ ਲਈ effects ਜੋੜ ਰਹੇ ਹੋ।
ਇਹ ਮਾਡਲ chat tools (ਜਿਵੇਂ Koder.ai) ਨਾਲ ਬਣਾਉਂਦਿਆਂ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ: ਹਰ ਸਾਂਝੇ state ਟੁੱਕੜੇ ਲਈ ਇਕ ਮਾਲਿਕ ਮੰਗੋ, ਫਿਰ ਉੱਪਰ ਵੱਲ handlers ਜਨਰੇਟ ਕਰੋ।
ਇੱਕ ਛੋਟਾ ਫੀਚਰ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਮਨ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਫਿੱਟ ਹੋਵੇ। ਇਕ ਵਧੀਆ ਉਦਾਹਰਨ ਹੈ ਇੱਕ ਸਰਚੇਬਲ ਲਿਸਟ ਜਿੱਥੇ ਤੁਸੀਂ ਕਿਸੇ ਆਈਟਮ 'ਤੇ ਕਲਿੱਕ ਕਰਕੇ ਵੇਰਵੇ ਮੋਡਲ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ।
ਸ਼ੁਰੂਆਤ ਕਰੋ UI ਹਿੱਸਿਆਂ ਅਤੇ ਹੋ ਸਕਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਦੀ ਸਕੈਚਿੰਗ ਨਾਲ। ਕੋਡ ਬਾਰੇ ਸੋਚੋ ਨਾ—ਸੋਚੋ ਯੂਜ਼ਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ ਕੀ ਦੇਖ ਸਕਦਾ ਹੈ: ਇੱਕ search input, ਇੱਕ list, ਇੱਕ ਚੁਣੀ ਹੋਈ ਸਤਰ ਹਾਈਲਾਈਟ, ਅਤੇ ਇੱਕ modal। ਘਟਨਾਵਾਂ ਹਨ typing, ਆਈਟਮ 'ਤੇ ਕਲਿੱਕ, modal ਖੋਲ੍ਹਣਾ ਅਤੇ ਬੰਦ ਕਰਨਾ।
ਹੁਣ "state ਖਿੱਚੋ"। ਥੋੜ੍ਹੇ ਮੁੱਲ ਲਿਖੋ ਜੋ ਸਟੋਰ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਿਸ ਦਾ ਮਾਲਕ ਕੌਣ ਹੋਵੇ। ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਆਮ ਪੈਰੈਂਟ ਜੋ ਉਹ ਮੁੱਲ ਪੜ੍ਹਦਾ/ਲਿਖਦਾ ਹੈ ਉਹ ਮਾਲਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਸ ਫੀਚਰ ਲਈ state ਛੋਟੀ ਹੋ ਸਕਦੀ ਹੈ: query (string), selectedId (id ਜਾਂ null), ਅਤੇ isModalOpen (boolean). list query ਪੜ੍ਹ ਕੇ items ਰੇਂਡਰ ਕਰਦਾ ਹੈ। modal selectedId ਪੜ੍ਹ ਕੇ ਵੇਰਵੇ ਦਿਖਾਉਂਦਾ ਹੈ। ਜੇ ਦੋਹਾਂ list ਅਤੇ modal ਨੂੰ selectedId ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ parent ਵਿੱਚ ਰੱਖੋ, ਦੋ ਬਜਾਏ।
ਫਿਰ derived data ਨੂੰ stored data ਤੋਂ ਵੱਖ ਕਰੋ। filtered list derived ਹੈ: filteredItems = items.filter(...). ਇਸਨੂੰ state ਵਿੱਚ ਨਾ ਰੱਖੋ ਕਿਉਂਕਿ ਇਹ ਸਦਾ items ਅਤੇ query ਤੋਂ ਮੁੜ ਕੈਲਕੁਲੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। derived data ਨੂੰ store ਕਰਨ ਨਾਲ ਮੁੱਲ ਇੱਕ-ਦੂਜੇ ਤੋਂ ਡਰਿਫਟ ਕਰ ਸਕਦੇ ਹਨ।
ਫਿਰ ਪucho: ਕੀ ਸanu effect ਦੀ ਲੋੜ ਹੈ? ਜੇ items ਪਹਿਲਾਂ ਹੀ memory ਵਿੱਚ ਹਨ ਤਾਂ ਨਹੀਂ। ਜੇ typing ਨਾਲ fetch ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਹਾਂ। ਜੇ modal ਬੰਦ ਕਰਨ 'ਤੇ ਕੁਝ save ਕਰਨਾ ਹੈ ਤਾਂ ਹਾਂ। Effects syncing ਲਈ ਹਨ (fetch, save, subscribe), ਬੁਨਿਆਦੀ UI wiring ਲਈ ਨਹੀਂ।
ਅਖੀਰ ਵਿੱਚ ਕੁਝ edge cases ਨਾਲ flow ਦੀ ਜਾਂਚ ਕਰੋ:
selectedId ਅਜੇ ਵੀ ਮਾਨਯੋਗ ਹੈ?ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਦਾ ਕਾਗਜ਼ ਤੇ ਉੱਤਰ ਦੇ ਸਕਦੇ ਹੋ, ਤਾਂ React ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਸਿੱਧਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ React ਦੀ ਭੁਲ syntax ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਹੋਂਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ ਕੋਡ ਉਹ ਸਧਾਰਣ ਕਹਾਣੀ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਮਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋ ਨਾਲ ਮੇਲ ਖਾਣਾ ਛੱਡ ਦੇਵੇ।
Derived state ਰੱਖਣਾ. ਤੁਸੀਂ fullName state ਵਿੱਚ ਸਟੋਰ ਕਰ ਲੈਂਦੇ ਹੋ ਜਦੋਂ ਕਿ ਇਹ ਸਿਰਫ firstName + lastName ਹੈ। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਤੱਕ ਇੱਕ ਫੀਲਡ ਬਦਲਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਨਹੀਂ, ਫਿਰ UI stale ਦਿਖਾਉਂਦਾ ਹੈ।
Effect loops. ਇਕ effect ਡੇਟਾ fetch ਕਰਦਾ, state ਸੈੱਟ ਕਰਦਾ, ਅਤੇ dependency list ਇਸਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਂਦੀ ਹੈ। ਲੱਛਣ ਹੁੰਦਾ ਹੈ ਬਾਰ-ਬਾਰ requests, jittery UI, ਜਾਂ state ਜੋ settle ਨਹੀਂ ਹੁੰਦੀ।
Stale closures. ਇਕ click handler ਪੁਰਾਣਾ ਮੁੱਲ ਪੜ੍ਹਦਾ ਹੈ (ਜਿਵੇਂ outdated counter ਜਾਂ filter)। ਲੱਛਣ: “ਮੈਂ ਕਲਿੱਕ ਕੀਤਾ ਪਰ ਇਸਨੇ ਕੱਲ ਦਾ ਮੁੱਲ ਵਰਤਿਆ।”
Global state ਹਰ ਜਗ੍ਹਾ. ਹਰ UI ਵੇਰਵਾ ਨੂੰ global store ਵਿੱਚ ਰੱਖਣਾ ਇਹ ਪਤਾ ਕਰਨਾ ਔਖਾ ਕਰ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਸ ਨੇ ਕੀ ਮਾਲਕੀ ਹੈ। ਲੱਛਣ: ਤੁਸੀਂ ਇੱਕ ਚੀਜ਼ ਬਦਲਦੇ ਹੋ ਅਤੇ ਤਿਨਾਂ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਅਚਾਨਕ ਪ੍ਰਭਾਵ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
Nested objects ਦੀ mutation. ਤੁਸੀਂ object ਜਾਂ array ਨੂੰ ਜਗ੍ਹਾ 'ਤੇ ਹੀ ਬਦਲਦੇ ਹੋ ਅਤੇ ਸੋਚਦੇ ਹੋ ਕਿ UI ਅਪਡੇਟ ਹੋਵੇਗੀ। ਲੱਛਣ: “ਡੇਟਾ ਬਦਲਿਆ, ਪਰ ਕੁਝ re-render ਨਹੀਂ ਹੋਇਆ।”
ਇੱਕ ਸੰਪ੍ਰਕ ਉਦਾਹਰਨ: एक “search ਅਤੇ sort” ਪੈਨਲ। ਜੇ ਤੁਸੀਂ filteredItems state ਵਿੱਚ ਰੱਖਦੇ ਹੋ, ਇਹ items ਨਾਲ ਡਰਿਫਟ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਨਵਾਂ ਡੇਟਾ ਆਵੇ। ਇਸ ਦੀ ਥਾਂ, inputs (search text, sort choice) ਰੱਖੋ ਅਤੇ filtered list render ਵਿੱਚ ਕੈਲਕੁਲੇਟ ਕਰੋ।
Effects ਦੇ ਨਾਲ, ਉਨ੍ਹਾਂ ਨੂੰ ਬਾਹਰੀ ਦੁਨੀਆ ਨਾਲ sync ਕਰਨ ਲਈ ਰੱਖੋ (fetching, subscriptions, timers)। ਜੇ ਇੱਕ effect ਬੁਨਿਆਦੀ UI ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਉਹ ਆਮ ਤੌਰ 'ਤੇ render ਜਾਂ event handler ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ chat ਰਾਹੀਂ ਕੋਡ ਜਨਰੇਟ ਜਾਂ ਸੋਧ ਰਹੇ ਹੋ, ਇਹ ਗ਼ਲਤੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਬਦਲਾਅ ਵੱਡੇ-ਵੱਡੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਆ ਸਕਦੇ ਹਨ। ਇੱਕ ਚੰਗੀ ਆਦਤ ਇਹ ਹੈ ਕਿ ਅਪਨੇ ਬੇਨਤੀਆਂ state possession ਦੀ ਰੂਪ-ਰੇਖਾ ਦੁਆਰਾ ਫ੍ਰੇਮ ਕਰੋ: “ਇਸ ਮੁੱਲ ਦਾ ਸਰੋਤ-ਸੱਚਾਈ ਕੀ ਹੈ?” ਅਤੇ “ਕੀ ਅਸੀਂ ਇਸਨੂੰ ਕੈਲਕੁਲੇਟ ਕਰ ਸਕਦੇ ਹਾਂ ਬਜਾਏ store ਕਰਨ ਦੇ?”
ਜਦੋਂ ਤੁਹਾਡੀ UI ਅਣਪਛਾਤੀ ਹੋਣ ਲੱਗੇ, ਆਮ ਤੌਰ 'ਤੇ ਇਹ “ਬਹੁਤ React” ਨਹੀਂ ਹੁੰਦਾ—ਅਕਸਰ ਇਹ ਬਹੁਤ state, ਗਲਤ ਥਾਂ ਤੇ, ਜੋ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ।
ਹਰ ਵਾਰ useState ਜੋੜਣ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕੋ ਅਤੇ ਪੁੱਛੋ:
ਛੋਟਾ ਉਦਾਹਰਨ: search box, filter dropdown, list. ਜੇ ਤੁਸੀਂ query ਅਤੇ filteredItems ਦੋਹਾਂ state ਵਿੱਚ ਰੱਖਦੇ ਹੋ, ਤੁਹਾਡੇ ਕੋਲ ਹੁਣ ਦੋ ਸਰੋਤ-ਸੱਚਾਈਆਂ ਹਨ। ਇਸ ਦੀ ਥਾਂ, query ਅਤੇ filter ਨੂੰ state ਰੱਖੋ, ਫਿਰ full list ਤੋਂ render ਵਿੱਚ filteredItems ਕੈਲਕੁਲੇਟ ਕਰੋ।
ਇਹ ਗੱਲ chat tools ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦਿਆਂ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਤੇਜ਼ੀ ਵਧੀਆ ਹੈ, ਪਰ ਹਮੇਸ਼ਾ ਪੁੱਛਦੇ ਰਹੋ: “ਕੀ ਅਸੀਂ state ਜੋੜੀ, ਜਾਂ ਅਸੀਂ ਗਲਤੀ ਨਾਲ ਡੈਰੀਵਡ ਮੁੱਲ ਜੋੜ ਦਿੱਤਾ?” ਜੇ ਇਹ ਡੈਰੀਵਡ ਹੈ, ਉਸ state ਨੂੰ ਹਟਾ ਦਿਓ ਅਤੇ ਉਸਨੂੰ ਕੈਲਕੁਲੇਟ ਕਰੋ।
ਇੱਕ ਛੋਟੀ ਟੀਮ admin UI ਬਣਾ ਰਹੀ ਹੈ: orders ਦੀ table, ਕੁਝ filters, ਅਤੇ order edit ਕਰਨ ਲਈ dialog। ਪਹਿਲੀ ਬੇਨਤੀ ਅਸਪੱਸ਼ਟ ਹੋ ਸਕਦੀ ਹੈ: “filters ਅਤੇ edit popup ਜੋੜੋ।” ਇਹ ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ random state ਹਰ ਜਗ੍ਹਾ ਫੈਲਾ ਦਿੰਦਾ ਹੈ।
ਇਸਨੂੰ state ਅਤੇ events ਵਿੱਚ ਤਬਦੀਲ ਕਰਕੇ ਠੋਸ ਬਣਾਓ। “filters” ਬਦਲੇ, state ਦਾ ਨਾਮ ਕਰੋ: query, status, dateRange। “edit popup” ਲਈ ਘਟਨਾ ਨਾਮ ਕਰੋ: “user Edit 'ਤੇ click ਕਰਦਾ ਹੈ।” ਫਿਰ ਹਰ state ਦਾ ਮਾਲਕ ਨਿਰਧਾਰਿਤ ਕਰੋ (page, table, ਜਾਂ dialog) ਅਤੇ ਕੀ derived ਹੈ ਇਹ ਫੈਸਲਾ ਕਰੋ (ਜਿਵੇਂ filtered list)।
ਉਦਾਹਰਨ prompts ਜੋ ਮਾਡਲ ਨੂੰ ਟਿਕਾਊ ਰੱਖਦੇ ਹਨ (ਇਹ chat-ਅਧਾਰਿਤ ਬਿਲਡਰਾਂ ਜਿਵੇਂ Koder.ai ਵਿੱਚ ਵੀ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ):
OrdersPage that owns filters and selectedOrderId. OrdersTable is controlled by filters and calls onEdit(orderId).”visibleOrders from orders and filters. Do not store visibleOrders in state.”EditOrderDialog that receives order and open. When saved, call onSave(updatedOrder) and close.”filters to the URL, not to compute filtered rows.”ਜਦੋਂ UI ਜਨਰੇਟ ਜਾਂ ਅਪਡੇਟ ਹੋ ਜਾਵੇ, ਤੁਰੰਤ ਇੱਕ ਤੇਜ਼ ਸਮੀਖਿਆ ਕਰੋ: ਹਰ state ਮੁੱਲ ਦਾ ਇੱਕ ਮਾਲਕ ਹੋਵੇ, derived values store ਨਾ ਕੀਤੇ ਹੋਣ, effects ਸਿਰਫ ਬਾਹਰੀ ਦੁਨੀਆ ਨਾਲ sync ਕਰਨ ਲਈ ਹੋਣ (URL, network, storage), ਅਤੇ events props ਰਾਹੀਂ ਥੱਲੇ ਅਤੇ callbacks ਰਾਹੀਂ ਉੱਪਰ ਵੱਲ ਜਾਂ।
ਜਦੋਂ state ਅਨੁਮਾਨਯੋਗ ਹੁੰਦੀ ਹੈ, iteration ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ table layout ਬਦਲ ਸਕਦੇ ਹੋ, ਨਵਾਂ filter ਜੋੜ ਸਕਦੇ ਹੋ, ਜਾਂ dialog ਫੀਲਡਸ ਢਾਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੇ ਕਿ ਕਿਹੜਾ ਛੁਪਿਆ state ਟੁੱਟ ਜਾਵੇਗਾ।
ਤੇਜ਼ੀ ਤਦ ਤੱਕ ਹੀ ਫਾਇਦੇਮੰਦ ਹੈ ਜਦੋਂ ਐਪ ਸੋਚਣ ਲਈ ਆਸਾਨ ਰਹੇ। ਸਭ ਤੋਂ ਸਧਾਰਣ ਸੁਰੱਖਿਆ ਇਹ ਹੈ ਕਿ ਇਹਨਾਂ ਮੈਨਟਲ ਮਾਡਲਾਂ ਨੂੰ ਇੱਕ ਚੈੱਕਲਿਸਟ ਵਾਂਗ ਵਰਤੋਂ ਜੋ ਤੁਸੀਂ ਹਰ ਵਾਰ ਕੋਡ (ਜਾਂ ਜਨਰੇਟ) ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਗਾਓ।
ਹਰ ਫੀਚਰ ਨੂੰ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਜ਼ਰੂਰੀ state ਲਿਖੋ, ਉਹਨਾਂ ਨੂੰ ਬਦਲ ਸਕਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਲਿਖੋ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਮਾਲਕ ਨਿਰਧਾਰਿਤ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਕਹਿ ਸਕਦੇ, “ਇਸ ਕੰਪੋਨੈਂਟ ਦਾ ਇਹ state ਹੈ, ਅਤੇ ਇਹ ਘਟਨਾਵਾਂ ਇਸਨੂੰ ਅਪਡੇਟ ਕਰਦੀਆਂ ਹਨ,” ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ ਤੇ scattered state ਅਤੇ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ re-renders ਦੇ ਨਾਲ ਖਤਮ ਹੋਵੋਗੇ।
ਜੇ ਤੁਸੀਂ chat ਰਾਹੀਂ ਬਣਾਉਂਦੇ ਹੋ, planning mode ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਕੰਪੋਨੈਂਟ, state shape, ਅਤੇ transitions ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵਰਣਨ ਕਰੋ ਪਹਿਲਾਂ, ਫਿਰ ਕੋਡ ਮੰਗੋ। ਉਦਾਹਰਨ: “A filter panel updates query state; the results list derives from query; selecting an item sets selectedId; closing clears it.” ਜਦੋਂ ਇਹ ਸਾਫ਼ ਦਰਜ ਹੋਵੇ, UI ਜਨਰੇਟ ਕਰਨਾ ਮਕੈਨੀਕਲ ਕਦਮ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ React ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਲਈ, ਤਾਂ ਇੱਕ ਛੋਟੀ sanity pass ਕਰਨ ਯੋਗ ਹੈ: ਹਰ state ਮੁੱਲ ਲਈ ਇਕ ਸਾਫ਼ ਮਾਲਕ, UI state ਤੋਂ ਡੈਰੀਵਡ, effects ਸਿਰਫ syncing ਲਈ, ਅਤੇ ਦੋਹਰਾ ਸਰੋਤ-ਸੱਚਾਈ ਨਾ ਹੋਵੇ।
ਫਿਰ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਦੁਹਰਾਓ। ਜੇ ਤੁਹਾਨੂੰ state structure ਬਦਲਣੀ ਹੋਵੇ (ਜਿਵੇਂ ਕਈ booleans ਤੋਂ ਇਕ single status field), ਤਾਂ ਪਹਿਲਾਂ ਇੱਕ ਸਨੇਪਸ਼ਾਟ ਲਓ, ਤਜਰਬਾ ਕਰੋ, ਅਤੇ ਜੇ mental model ਖ਼ਰਾਬ ਹੋ ਜਾਵੇ ਤਾਂ rollback ਕਰੋ। ਅਤੇ ਜਦੋਂ ਤੁਹਾਨੂੰ ਡੂੰਘੀ ਸਮੀਖਿਆ ਜਾਂ ਹેન્ડਆਫਟ ਦੀ ਲੋੜ ਹੋਵੇ, source code ਨਿਕਾਸ ਕਰਕੇ ਸੌਂਪਣਾ ਆਸਾਨ ਬਣ ਜਾਂਦਾ ਹੈ: ਕੀ state shape ਅਜੇ ਵੀ UI ਦੀ ਕਹਾਣੀ ਦੱਸਦੀ ਹੈ?
UI = f(state, props) ਇੱਕ ਵਧੀਆ ਸ਼ੁਰੂਆਤੀ ਮਾਡਲ ਹੈ। ਤੁਹਾਡੇ ਕੰਪੋਨੈਂਟ DOM ਨੂੰ “ਸੋਧ” ਨਹੀਂ ਕਰਦੇ; ਉਹ ਵੀਰਣ ਕਰਦੇ ਹਨ ਕਿ ਮੌਜੂਦਾ ਡੇਟਾ ਲਈ ਸਕ੍ਰੀਨ ਤੇ ਕੀ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਸਕ੍ਰੀਨ ਗਲਤ ਲੱਗੇ, DOM ਦੇਖੋ ਨਾ ਕਿ state/props ਦੀ ਜਾਂਚ ਕਰੋ ਜੋ ਉਸ ਨੂੰ ਬਣਾਉਂਦੇ ਹਨ।
Props ਮਾਪਦੰਡ ਹਨ ਮਾਪਦੇ ਹਨ ਮਾਪ ਦੇਣ ਵਾਲੇ ਪੈਰੈਂਟ ਤੋਂ; ਤੁਹਾਡਾ ਕੰਪੋਨੈਂਟ ਉਹਨਾਂ ਨੂੰ read-only ਵਾਂਗ ਵਰਤੇ। State ਯਾਦ ਹੈ ਜੋ ਕਿਸੇ ਕੰਪੋਨੈਂਟ (ਜਾਂ ਜਿਸ ਕੰਪੋਨੈਂਟ ਨੂੰ ਤੁਸੀਂ ਮਾਲਕ ਬਣਾਉਂਦੇ ਹੋ) ਦੇ ਕੋਲ ਹੁੰਦੀ ਹੈ। ਜੇ ਇਕ ਮੁੱਲ ਸਾਂਝਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਸਨੂੰ ਉੱਪਰ ਲਿਫਟ ਕਰੋ ਅਤੇ props ਰਾਹੀਂ ਥੱਲੇ ਪਾਸ ਕਰੋ।
Re-render ਦਾ ਮਤਲਬ ਹੈ React ਤੁਹਾਡੀ ਕੰਪੋਨੈਂਟ ਫੰਕਸ਼ਨ ਨੂੰ ਮੁੜ ਚਲਾਉਂਦਾ ਹੈ ਤਾਂ ਜੋ ਅਗਲਾ UI ਵਰਣਨ ਮਿਲ ਸਕੇ। ਇਹ ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਿ ਪੂਰਾ ਪੇਜ ਫੇਰੋ-ਅਖੀਰ ਹੋ ਜਾਏ। React ਫਿਰ ਸੱਚੇ DOM ਨੂੰ ਸਭ ਤੋਂ ਛੋਟੀਆਂ ਲੋੜੀਂਦੀਆਂ ਬਦਲਾਵਾਂ ਨਾਲ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।
State ਅਪਡੇਟਾਂ ਨੂੰ ਨਿਯਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤੁਰੰਤ ਅਸਾਈਨਮੈਂਟ ਨਹੀਂ। ਜੇ ਅਗਲਾ ਮੁੱਲ ਪਿਛਲੇ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਤਾਂ updater ਫਾਰਮ ਵਰਤੋ ਤਾਂ ਜੋ ਤੁਸੀਂ stale ਮੁੱਲ 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ:
setCount(c => c + 1)ਇਹ ਠੀਕ ਰਹਿੰਦਾ ਹੈ ਭਾਵੇਂ ਕਈ ਅਪਡੇਟ ਕਤਾਰ ਵਿੱਚ ਹੋਣ।
ਜੋ ਕੁਝ ਤੁਸੀਂ ਮੌਜੂਦਾ ਇਨਪੁੱਟ ਤੋਂ ਕੈਲਕੁਲੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਉਸਨੂੰ state ਵਿੱਚ ਸ(store ) ਨਾ ਕਰੋ। ਇਨਪੁੱਟ ਸਟੋਰ ਕਰੋ, ਬਾਕੀ ਨੂੰ render ਦੌਰਾਨ ਡੈਰੀਵ ਕਰੋ。
ਉਦਾਹਰਨ:
items, filtervisibleItems = items.filter(...)ਇਸ ਨਾਲ ਮੁੱਲ synchronize ਰਹਿੰਦੇ ਹਨ।
Effects ਨੂੰ ਉਹ ਕੰਮ ਕਰਨ ਲਈ ਵਰਤੋ ਜੋ React ਦੇ ਬਾਹਰ ਹੋ ਰਹੇ ਹਨ: fetch, subscriptions, timers, browser APIs ਜਾਂ ਕਦੇ-ਕਦੇ imperative DOM ਕੰਮ।
UI ਮੁੱਲ ਕੈਲਕੁਲੇਟ ਕਰਨ ਲਈ effect ਨਾ ਵਰਤੋ—ਉਹਨਾਂ ਨੂੰ render (ਜਾਂ ਮਹਿੰਗਾ ਹੋਣ 'ਤੇ useMemo) ਵਿੱਚ ਕੈਲਕੁਲੇਟ ਕਰੋ।
Dependencies ਨੂੰ ਤਰਜੀਹੀ তালਿਕਾ ਸਮਝੋ: “ਜਦੋਂ ਇਹ ਮੁੱਲ ਬਦਲਦੇ ਹਨ, ਬਾਹਰ ਦੀ ਦੁਨੀਆ ਨਾਲ ਮੁੜ sync ਕਰੋ।” ਆਪਣਾ effect ਜੋ ਵੀ reactive ਮੁੱਲ ਵਰਤਦਾ ਹੈ ਉਹ dependencies ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ।
ਕੋਈ ਚੀਜ਼ ਛਡਣ ਨਾਲ stale ਡੇਟਾ ਰਹਿ ਸਕਦੀ ਹੈ (ਜਿਵੇਂ purana userId ਜਾਂ token)। ਗ਼ਲਤ ਚੀਜ਼ਾਂ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ loops ਬਣ ਸਕਦੇ ਹਨ—ਅਕਸਰ ਨਿਸ਼ਾਨ ਹੁੰਦਾ ਹੈ ਕਿ effect ਉਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜੋ events ਜਾਂ render ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ।
ਜੇ UI ਦੇ ਦੋ ਹਿੱਸੇ ਮੁਸਲਸਲ ਇਕੋ ਮੁੱਲ 'ਤੇ ਸਹਿਮਤ ਰਹਿਣੇ ਚਾਹੁੰਦੇ ਹਨ, ਉਹ state ਉਨ੍ਹਾਂ ਦੇ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਆਮ ਮਾਪੇ (closest common parent) ਵਿੱਚ ਰੱਖੋ, ਮੁੱਲ ਨੂੰ ਥੱਲੇ ਪਾਸ ਕਰੋ ਅਤੇ callbacks ਉੱਪਰ ਲੈ ਜਾਓ।
ਇੱਕ ਤੇਜ਼ ਟੈਸਟ: ਜੇ ਤੁਸੀਂ ਦੋ ਕੰਪੋਨੈਂਟਾਂ ਵਿੱਚ ਇੱਕੋ ਮੁੱਲ ਨਕਲ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ sync ਰੱਖਣ ਲਈ effects ਲਿਖ ਰਹੇ ਹੋ, ਤਾਂ ਉਸ state ਨੂੰ ਇੱਕ ਮਲਿਕ (=owner) ਚਾਹੀਦਾ ਹੈ।
ਜਿਵੇਂ ਕਿ handler ਕਿਸੇ ਪੁਰਾਣੇ render ਤੋਂ ਇੱਕ ਪੁਰਾਣਾ ਮੁੱਲ “capture” ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ stale values ਆਉਂਦੀਆਂ ਹਨ। ਆਮ ਉਪਾਅ:
setX(prev => ...)ਜੇ ਕੋਈ click “ਅੱਜ ਤੋਂ ਵੀ ਪਿਛਲੇ ਮੁੱਲ” ਵਰਤ ਰਿਹਾ ਹੈ, ਤਾਂ stale closure ਸੰਭਵ ਹੈ।
ਛੋਟੇ ਯੋਜਨਾਬੱਧ steps ਨਾਲ ਚਲੋ: ਕੰਪੋਨੈਂਟ, state ਮਾਲਕ, ਅਤੇ events ਲਿਖੋ। ਫਿਰ ਕੋਡ ਛੋਟੇ ਪੈਚਾਂ ਵਾਂਗ ਬਣਵਾਓ (ਇੱਕ state ਖੇਤਰ ਜੋੜੋ, ਇੱਕ handler ਜੋੜੋ, ਇੱਕ ਮੁੱਲ render ਵਿੱਚ ਡੈਰੀਵ ਕਰੋ) ਬਜਾਏ ਵੱਡੇ-ਰੇਫੈਕਟਰ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਚੈਟ ਬਿਲਡਰ ਵਰਤ ਰਹੇ ਹੋ, ਪੁੱਛੋ:
ਇਸ ਨਾਲ GENERATED ਕੋਡ React ਮਾਡਲ ਨਾਲ ਖਰਾਬ ਨਹੀਂ ਹੋਵੇਗਾ।