React ਮੈਨਟਲ ਮਾਡਲ: Dan Abramov ਦੇ ਸਟਾਈਲ ਵਾਲੇ ਸੋਚਣ ਦੇ ਤਰੀਕੇ

ਕਿਉਂ React ਔਖਾ ਲੱਗਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਸਹੀ ਮੈਨਟਲ ਮਾਡਲ ਨਾ ਹੋਵੇ

ਸ਼ੁਰੂ ਵਿੱਚ React ਚਿੰਤਾਜਨਕ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ UI ਦੇ ਬਦਲਾਅ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਪਰ ਹਮੇਸ਼ਾ ਸਮਝ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਉਹ ਕਿਉਂ ਬਦਲਿਆ। ਤੁਸੀਂ ਇੱਕ ਬਟਨ 'ਤੇ ਕਲਿਕ ਕਰਦੇ ਹੋ, ਕੁਝ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਪੇਜ਼ ਦਾ ਕਿਸੇ ਹੋਰ ਹਿੱਸੇ ਨੇ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰ ਦਿੱਤਾ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ “React ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ ਹੈ” ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਹੈ “ਮੇਰੀ ਸੋਚ React ਦੇ ਕੰਮ ਕਰਨ ਬਾਰੇ ਧੁੰਦਲੀ ਹੈ।”

ਮੈਨਟਲ ਮਾਡਲ ਉਹ ਸਧਾਰਣ ਕਹਾਣੀ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਮਨ ਵਿੱਚ ਬਣਾਉਂਦੇ ਹੋ ਕਿ ਕੋਈ ਚੀਜ਼ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਜੇ ਕਹਾਣੀ ਗਲਤ ਹੋਵੇ, ਤੁਸੀਂ ਪੱਕੇ ਫੈਸਲੇ ਕਰੋਗੇ ਜੋ ਗੁੰਝਲਦਾਰ ਨਤੀਜੇ ਲਿਆਉਂਦੇ ਹਨ। ਇੱਕ thermostat ਦੀ ਸੋਚੋ: ਖਰਾਬ ਮਾਡਲ ਇਹ ਹੋ ਸਕਦਾ ਹੈ “ਮੈਂ 22°C ਸੈੱਟ ਕੀਤਾ, ਤਾਂ ਕਮਰਾ ਤੁਰੰਤ 22°C ਹੋ ਗਿਆ।” ਇੱਕ ਚੰਗਾ ਮਾਡਲ ਇਹ ਹੈ “ਮੈਂ ਇਕ ਟਾਰਗੇਟ ਰੱਖਿਆ, ਅਤੇ ਹੀਟਰ ਸਮੇਂ ਦੇ ਨਾਲ ਚੱਲਦਾ/ਰੁਕਦਾ ਹੈ ਤਾਂ ਜੋ ਟਾਰਗੇਟ ਮਿਲ ਸਕੇ।” ਚੰਗੀ ਕਹਾਣੀ ਨਾਲ ਵਰਤਾਰਾ random ਨਹੀਂ ਲੱਗਦਾ।

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

Dan Abramov ਨੇ ਇਸ “ਅਨੁਮਾਨਯੋਗ ਬਣਾਓ” ਸੋਚ ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ। ਉਦੇਸ਼ ਕਿਸੇ ਨਿਯਮ ਨੂੰ ਯਾਦ ਕਰਨਾ ਨਹੀਂ—ਬਲਕਿ ਆਪਣੇ ਮਨ ਵਿੱਚ ਕੁਝ ਛੋਟੀਆਂ ਸੱਚਾਈਆਂ ਰੱਖਣੀਆਂ ਹਨ ਤਾਂ ਜੋ ਤੁਸੀਂ reasoning ਨਾਲ bug-fix ਕਰ ਸਕੋ, trial-and-error ਨਾਲ ਨਹੀਂ।

ਇਨ੍ਹਾਂ ਵਿਚਾਰਾਂ ਨੂੰ ਆਪਣੇ ਅਗੇ ਰੱਖੋ:

• UI state ਦਾ ਨਤੀਜਾ ਹੈ, DOM ਤੇ manual edits ਦਾ ਸੈਟ ਨਹੀਂ।
• Components ਫੰਕਸ਼ਨ ਹਨ ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ UI ਕਿਵੇਂ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ।
• ਡਾਟਾ ਹੇਠਾਂ ਵਹਿੰਦੀ ਹੈ; ਬਦਲਾਅ events ਰਾਹੀਂ ਉੱਪਰ ਆਉਂਦੇ ਹਨ।
• Side effects rendering ਤੋਂ ਵੱਖ ਹਨ ਤੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਮਕਸਦ ਹੈ।

ਇਨ੍ਹਾਂ ਨੂੰ ਫੜ ਲਓ ਅਤੇ React ਜਾਦੂ ਵਰਗਾ ਨਹੀਂ ਰਹੇਗਾ—ਇਹ ਇੱਕ ਸਿਸਟਮ ਵਰਗਾ ਮਹਿਸੂਸ ਹੋਏਗਾ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ।

ਕੰਪੋਨੈਂਟ, props ਅਤੇ state: ਮੁੱਖ ਤਸਵੀਰ

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 ਤੋਂ ਪੜ੍ਹਕੇ ਰੱਖਣਾ ਹੈ, ਨਾ ਕਿ ਛੁਪੇ ਹੋਏ ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ ਭਟਕਣਾ।

ਸੰਖੇਪ ਰੂਪ:

• Component: UI ਦਾ ਟੁਕੜਾ (SearchBox, ProfileCard, CheckoutForm)
• Props: ਜੋ ਇਸਨੂੰ ਦਿਖਾਉਣ ਲਈ ਚਾਹੀਦਾ (name, price, disabled)
• State: ਜੋ ਇਹ ਯਾਦ ਰੱਖਦਾ (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 ਅਪਡੇਟ: ਬਦਲਾਅ ਛੋਟੇ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਰੱਖੋ

ਇਕ ਹੋਰ ਮਦਦਗਾਰ ਮਾਡਲ: 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 ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ:

• ਉਸਨੂੰ ਸੰਭਾਲੋ ਜੇ ਉਹ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ UI ਨੂੰ ਰੀਐਕਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
• ਇਸਨੂੰ ਨਾ ਸੰਭਾਲੋ ਜੇ ਉਹ ਹੋਰ state ਜਾਂ props ਤੋਂ ਨਿਕਲ ਕੇ ਕੈਲਕੁਲੇਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• ਇੱਕੋ ਸੱਚਾਈ ਦੇ дубਲੇ ਮੁੱਖ ਸਟੋਰ ਨਾ ਰੱਖੋ।

ਜੇ ਤੁਸੀਂ chat ਰਾਹੀਂ UI ਬਣਾ ਰਹੇ ਹੋ (ਉਦਾਹਰਣ ਲਈ Koder.ai), ਤਾਂ ਬਦਲਾਅ ਛੋਟੇ ਪੈਚਾਂ ਵਾਂਗ ਮੰਗੋ: “ਇੱਕ boolean ਫਲੇਗ ਜੋੜੋ” ਜਾਂ “ਇਸ ਲਿਸਟ ਨੂੰ immutable ਤਰੀਕੇ ਨਾਲ ਅਪਡੇਟ ਕਰੋ।” ਛੋਟੇ, ਵਿਸ਼ੇਸ਼ ਬਦਲਾਅ generator ਅਤੇ ਤੁਹਾਡੇ React ਕੋਡ ਨੂੰ aligned ਰੱਖਦੇ ਹਨ।

Effects syncing ਲਈ ਹਨ, ਬੁਨਿਆਦੀ UI ਲੌਜਿਕ ਲਈ ਨਹੀਂ

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 ਨੂੰ trigger-list ਸਮਝੋ

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 ਸੀ।

ਡਾਟਾ ਫਲੋ: ਇਕ ਸਰੋਤ-ਸੱਚਾਈ ਵੰਡੇ ਹੋਏ state ਤੋਂ ਬਿਹਤਰ ਹੈ

ਇੱਕ ਸਭ ਤੋਂ ਮ ú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 ਨੂੰ ਉਥੇ ਨਜ਼ਦੀਕ ਰੱਖਣਾ ਆਮ ਤੌਰ ਤੇ ਕੋਡ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਨਾਉਂਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬਾਊਂਡਰੀ:

• Local state: UI-ਕੇਵਲ ਵੇਰਵੇ (dropdown ਖੁੱਲਾ, ਕਿਹੜਾ tab ਹਾਈਲਾਈਟ)
• Shared state: ਉਹ ਡੇਟਾ ਜੋ ਕਈ components ਨੂੰ ਇਕੱਠੇ ਸਹਿਮਤ ਚਾਹੀਦਾ (filters, selected item, auth status)

ਜੇ ਤੁਹਾਨੂੰ ਹਾਲ ਨਹੀਂ ਪਤਾ ਕਿ state ਲਿਫਟ ਕਰਨੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਤਦ ਹੇਠਾਂ ਦੇ ਸਿਗਨਲ ਵੇਖੋ: ਦੋ components ਇੱਕੋ ਮੁੱਲ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾ ਰਹੇ ਹਨ; ਇੱਕ ਜਗ੍ਹਾ ਤੇ action ਦੁਜੇ ਦੂਰ ਅਪਡੇਟ ਨੂੰ ਕਾਰਨ ਬਣ ਰਿਹਾ ਹੈ; ਤੁਸੀਂ props ਨੂੰ state ਵਿੱਚ "ਸਿਰਫ਼ ਸੰਭਾਲਣ ਲਈ" ਕਾਪੀ ਕਰ ਰਹੇ ਹੋ; ਜਾਂ ਤੁਸੀਂ ਦੋ ਮੁੱਲਾਂ ਨੂੰ ਰੱਖਣ ਲਈ effects ਜੋੜ ਰਹੇ ਹੋ।

ਇਹ ਮਾਡਲ chat tools (ਜਿਵੇਂ Koder.ai) ਨਾਲ ਬਣਾਉਂਦਿਆਂ ਵੀ ਮਦਦ ਕਰਦਾ ਹੈ: ਹਰ ਸਾਂਝੇ state ਟੁੱਕੜੇ ਲਈ ਇਕ ਮਾਲਿਕ ਮੰਗੋ, ਫਿਰ ਉੱਪਰ ਵੱਲ handlers ਜਨਰੇਟ ਕਰੋ।

ਕਦਮ-ਦਰ-ਕਦਮ: ਪਹਿਲਾਂ state ਡਰਾਇੰਗ ਕਰਕੇ ਫੀਚਰ ਡਿਜ਼ਾਇਨ ਕਰੋ

ਇੱਕ ਛੋਟਾ ਫੀਚਰ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਮਨ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਫਿੱਟ ਹੋਵੇ। ਇਕ ਵਧੀਆ ਉਦਾਹਰਨ ਹੈ ਇੱਕ ਸਰਚੇਬਲ ਲਿਸਟ ਜਿੱਥੇ ਤੁਸੀਂ ਕਿਸੇ ਆਈਟਮ 'ਤੇ ਕਲਿੱਕ ਕਰਕੇ ਵੇਰਵੇ ਮੋਡਲ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ।

ਸ਼ੁਰੂਆਤ ਕਰੋ 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 ਦੀ ਜਾਂਚ ਕਰੋ:

• ਤੇਜ਼ੀ ਨਾਲ ਟਾਈਪ ਕਰੋ, ਫਿਰ input ਸਾਫ ਕਰੋ: ਕੀ list ਨਾਰਮਲ 'ਤੇ ਵਾਪਸ ਆਉਂਦੀ ਹੈ?
• ਇੱਕ ਆਈਟਮ 'ਤੇ ਕਲਿੱਕ ਕਰੋ, ਫਿਰ search ਨਾਲ list ਬਦਲ ਜਾਵੇ: ਕੀ selectedId ਅਜੇ ਵੀ ਮਾਨਯੋਗ ਹੈ?
• modal ਬੰਦ ਕਰੋ: ਕੀ ਚੋਣ ਰਹਿੰਦੀ ਹੈ ਜਾਂ reset ਹੋ ਜਾਂਦੀ ਹੈ?
• ਸਰਵਰ ਤੋਂ items ਤਾਜ਼ਾ ਹੋਣ: ਜੇ selected item ਮਿਟ ਜਾਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਦਾ ਕਾਗਜ਼ ਤੇ ਉੱਤਰ ਦੇ ਸਕਦੇ ਹੋ, ਤਾਂ 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 ਕਰਨ ਦੇ?”

ਜਦੋਂ state ਗੁੰਝਲਦਾਰ ਮਹਿਸੂਸ ਹੋਵੇ ਤਾਂ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਜਦੋਂ ਤੁਹਾਡੀ UI ਅਣਪਛਾਤੀ ਹੋਣ ਲੱਗੇ, ਆਮ ਤੌਰ 'ਤੇ ਇਹ “ਬਹੁਤ React” ਨਹੀਂ ਹੁੰਦਾ—ਅਕਸਰ ਇਹ ਬਹੁਤ state, ਗਲਤ ਥਾਂ ਤੇ, ਜੋ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ।

ਹਰ ਵਾਰ useState ਜੋੜਣ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕੋ ਅਤੇ ਪੁੱਛੋ:

• ਉਹਨਾਂ ਛੋਟੇ ਮੁੱਲਾਂ ਦਾ ਸਭ ਤੋਂ ਘੱਟ ਸੈਟ ਕੀ ਹੈ ਜੋ ਅਜੇ ਦੀ ਦ੍ਰਿਸ਼ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੇਰਣ ਕਰਦਾ ਹੈ?
• ਹਰ ਮੁੱਲ ਕਿੱਥੇ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਜਿਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੈ ਉਹ ਪੜ੍ਹ ਸਕਣ ਅਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲੋੜ ਨਹੀਂ ਉਹ ਸ਼ਾਂਤ ਰਹਿਣ?
• ਕੀ ਇਹ ਮੁੱਲ ਨਵੀਂ ਜਾਣਕਾਰੀ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਇਸਨੂੰ props, URL params, ਜਾਂ ਹੋਰ state ਤੋਂ ਕੈਲਕੁਲੇਟ ਕਰ ਸਕਦੇ ਹੋ?
• ਕੀ ਤੁਸੀਂ effect UI ਕੈਲਕੁਲੇਟ ਕਰਨ ਲਈ ਵਰਤ ਰਹੇ ਹੋ, ਜਾਂ ਸਿਰਫ ਬਾਹਰ ਵਾਲੀ ਚੀਜ਼ ਨਾਲ sync ਕਰਨ ਲਈ (network, timers, browser APIs)?
• ਜੇ ਇੱਕ ਮੁੱਲ ਬਦਲੇ ਤਾਂ কোন components ਨੂੰ re-render ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਇਸਨੂੰ ਪੜ੍ਹਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਨਹੀਂ?

ਛੋਟਾ ਉਦਾਹਰਨ: search box, filter dropdown, list. ਜੇ ਤੁਸੀਂ query ਅਤੇ filteredItems ਦੋਹਾਂ state ਵਿੱਚ ਰੱਖਦੇ ਹੋ, ਤੁਹਾਡੇ ਕੋਲ ਹੁਣ ਦੋ ਸਰੋਤ-ਸੱਚਾਈਆਂ ਹਨ। ਇਸ ਦੀ ਥਾਂ, query ਅਤੇ filter ਨੂੰ state ਰੱਖੋ, ਫਿਰ full list ਤੋਂ render ਵਿੱਚ filteredItems ਕੈਲਕੁਲੇਟ ਕਰੋ।

ਇਹ ਗੱਲ chat tools ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦਿਆਂ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਤੇਜ਼ੀ ਵਧੀਆ ਹੈ, ਪਰ ਹਮੇਸ਼ਾ ਪੁੱਛਦੇ ਰਹੋ: “ਕੀ ਅਸੀਂ state ਜੋੜੀ, ਜਾਂ ਅਸੀਂ ਗਲਤੀ ਨਾਲ ਡੈਰੀਵਡ ਮੁੱਲ ਜੋੜ ਦਿੱਤਾ?” ਜੇ ਇਹ ਡੈਰੀਵਡ ਹੈ, ਉਸ state ਨੂੰ ਹਟਾ ਦਿਓ ਅਤੇ ਉਸਨੂੰ ਕੈਲਕੁਲੇਟ ਕਰੋ।

ਉਦਾਹਰਨ: ਤੀਜ਼ੀ ਨਾਲ UI 'ਤੇ iterate ਕਰੋ ਬਿਨਾਂ predictability ਗੁਆਏ

ਇੱਕ ਛੋਟੀ ਟੀਮ 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 ਵਿੱਚ ਵੀ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ):

• “Create an OrdersPage that owns filters and selectedOrderId. OrdersTable is controlled by filters and calls onEdit(orderId).”
• “Derive visibleOrders from orders and filters. Do not store visibleOrders in state.”
• “Add an EditOrderDialog that receives order and open. When saved, call onSave(updatedOrder) and close.”
• “If data is fetched, keep it in one place. Use an effect only to sync 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 ਟੁੱਟ ਜਾਵੇਗਾ।

ਅਗਲੇ ਕਦਮ: chat ਨਾਲ ਤੇਜ਼ ਬਣਾਓ, ਪਰ React ਮਾਡਲ ਰੱਖੋ

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

ਹਰ ਫੀਚਰ ਨੂੰ ਇੱਕੋ ਹੀ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਜ਼ਰੂਰੀ 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 ਦੀ ਕਹਾਣੀ ਦੱਸਦੀ ਹੈ?