30 ਦਸੰ 2025·8 ਮਿੰਟ
Claude Code ਨਾਲ React ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰੋ
Claude Code ਦੀ ਵਰਤੋਂ ਕਰਕੇ React ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ characterization tests, ਛੋਟੇ ਸੁਰੱਖਿਅਤ ਕਦਮ ਅਤੇ state ਅਲੱਗਕਰਨ ਦੇ ਨਾਲ ਢਾਂਚਾ ਸੁਧਾਰਦੇ ਹੋਏ ਬਰਤਾਓ ਨਾ ਬਦਲੇ ਇਹ ਸਿੱਖੋ।
Claude Code ਦੀ ਵਰਤੋਂ ਕਰਕੇ React ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ characterization tests, ਛੋਟੇ ਸੁਰੱਖਿਅਤ ਕਦਮ ਅਤੇ state ਅਲੱਗਕਰਨ ਦੇ ਨਾਲ ਢਾਂਚਾ ਸੁਧਾਰਦੇ ਹੋਏ ਬਰਤਾਓ ਨਾ ਬਦਲੇ ਇਹ ਸਿੱਖੋ।
React ਰੀਫੈਕਟਰ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਕੰਪੋਨੈਂਟ ਛੋਟੇ, ਸਾਫ਼ ਬਿਲਡਿੰਗ ਬਲਾਕ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ UI, state, effects ਅਤੇ “ਹੋਰ ਇੱਕ prop” ਵਾਲੀਆਂ ਠੀਕਸ ਨੁਕਤਿਆਂ ਦਾ ਜਿਹੜਾ ਜੀਵਤ ਗੜਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਢਾਂਚਾ ਬਦਲਦੇ ਹੋ, ਅਕਸਰ ਤੁਸੀਂ ਬਿਨਾਂ ਮਨਸੂਬੇ ਦੇ ਟਾਈਮਿੰਗ, ਪਛਾਣ ਜਾਂ ਡੇਟਾ ਫਲੋ ਬਦਲ ਦਿੰਦੇ ਹੋ।
ਰੀਫੈਕਟਰ ਵਹਿਵਾਹਿਕਤਾ ਨੂੰ ਅਕਸਰ ਤਦ ਬਦਲਦਾ ਹੈ ਜਦੋਂ ਇਹ ਅਜਿਹੇ ਤਰੀਕਿਆਂ ਨਾਲ ਐਕਸੀਡੈਂਟਲ ਹੁੰਦਾ ਹੈ:
key ਬਦਲ ਗਿਆ।ਰੀਫੈਕਟਰ rewrite ਵਿੱਚ ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ ਜਦੋਂ “ਸਾਫ਼-ਸੁਥਰਾ” ਅਤੇ “ਸੁਧਾਰ” ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਇਕ ਕੰਪੋਨੈਂਟ ਨੂੰ ਇੱਕਸਟਰੈਕਟ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਫਿਰ ਕਈ ਚੀਜ਼ਾਂ rename ਕਰਦੇ ਹੋ, ਫਿਰ state shape “ਸਹੀ” ਕਰਦੇ ਹੋ, ਫਿਰ ਇੱਕ hook ਬਦਲ ਦਿੰਦੇ ਹੋ। ਜਲਦੀ ਹੀ ਤੁਸੀਂ ਲੌਜਿਕ ਅਤੇ ਲੇਆਉਟ ਦੋਹਾਂ ਬਦਲ ਰਹੇ ਹੋ। ਬਿਨਾਂ ਗਾਰਡਰੇਲਸ ਦੇ, ਪਤਾ ਲੱਗਣਾ ਔਖਾ ਹੁੰਦਾ ਕਿ ਕਿਹੜੇ ਬਦਲਾਅ ਕਾਰਨ bug ਆਇਆ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ ਦੀ ਇੱਕ ਸਧਾਰਣ ਵਾਅਦਾ ਹੁੰਦਾ ਹੈ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਉਹੀ ਬਰਤਾਓ ਮਿਲੇ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਸਾਫ਼ ਕੋਡ ਬਚੇ। Props, events, loading states, error states ਅਤੇ ਏਡਜ ਕੇਸਾਂ ਨੂੰ ਉਹੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਬਰਤਾਓ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਉਹ ਜਾਣਬੂਝ ਕੇ, ਛੋਟਾ ਅਤੇ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Claude Code (ਜਾਂ ਕੋਈ ਵੀ ਕੋਡ ਸਹਾਇਕ) ਨਾਲ React ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਤੇਜ਼ pair programmer ਵਾਂਗ ਲਓ, autopilot ਨਹੀਂ। ਇਸਨੂੰ ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਖਤਰੇ ਵਰਣਨ ਕਰਨ ਲਈ ਕਹੋ, ਛੋਟੇ, ਸੁਰੱਖਿਅਤ ਕਦਮਾਂ ਨਾਲ ਯੋਜਨਾ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ ਅਤੇ ਦੱਸੋ ਕਿ ਇਸਨੇ ਬਰਤਾਓ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਰੱਖਣ ਲਈ ਕਿਵੇਂ ਚੈੱਕ ਕੀਤਾ। ਫਿਰ ਖੁਦ ਵੈਲਿਡੇਟ ਕਰੋ: ਐਪ ਚਲਾਓ, ਅਜੀਬ ਰਾਹਾਂ 'ਤੇ ਕਲਿੱਕ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਟੈਸਟਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰੋ ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ ਕੰਪੋਨੈਂਟ ਅੱਜ ਕੀ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਉਹ ਕੀ ਕਰੇ।
ਉਹ ਇਕ ਕੰਪੋਨੈਂਟ ਚੁਣੋ ਜੋ ਤੁਹਾਨੂੰ ਸਮਾਂ ਖਰਚ ਕਰਾਉਂਦਾ ਹੈ। ਨਾ ਪੂਰਾ ਪੇਜ, ਨਾ "UI ਲੇਅਰ", ਅਤੇ ਨਾ ਹੀ ਧੁੰਦਲਾ "ਸਾਫ਼-ਸੁਥਰਾ"। ਇੱਕ ਇਕੱਲਾ ਕੰਪੋਨੈਂਟ ਚੁਣੋ ਜੋ ਪੜ੍ਹਨ ਵਿੱਚ ਮੁਸ਼ਕਲ, ਬਦਲਣ ਵਿੱਚ ਮੁਸ਼ਕਲ, ਜਾਂ state ਅਤੇ side effects ਨਾਲ ਭਰਿਆ ਹੋਇਆ ਹੋਵੇ। ਇਕ ਟਾਈਟ ਟਾਰਗਟ ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਸਹਾਇਕ ਦੀਆਂ ਸੁਝਾਵਾਂ ਦੇਖਣ ਅਤੇ ਸਰੋਟ ਕਰਨ 'ਚ ਆਸਾਨੀ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਟੀਚਾ ਲਿਖੋ ਜਿਸਨੂੰ ਪੰਜ ਮਿੰਟ ਵਿੱਚ ਚੈੱਕ ਕੀਤਾ ਜਾ ਸਕੇ। ਚੰਗੇ ਟੀਚੇ ਸਟ੍ਰਕਚਰ ਬਾਰੇ ਹੁੰਦੇ ਹਨ, ਨਤੀਜਿਆਂ ਬਾਰੇ ਨਹੀਂ: “ਛੋਟੀ ਕੰਪੋਨੈਂਟਾਂ ਵਿੱਚ ਵੰਡੋ”, “state ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਬਣਾਓ”, ਜਾਂ “ਟੈਸਟੇਬਲ ਬਣਾਓ ਬਿਨਾਂ ਐਪ ਦਾ ਅਧਾ ਮੌਕ ਕਰਨ ਦੇ”। "ਇਸਨੂੰ ਬਿਹਤਰ ਬਣਾਓ" ਜਾਂ "ਪਰਫ਼ਾਰਮੈਂਸ ਸੁਧਾਰੋ" ਵਰਗੇ ਟੀਚਿਆਂ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਮੈਟਰਿਕ ਅਤੇ ਜਾਣਿਆ ਹੋਇਆ ਬੋਤਲ-ਨੇਕ ਨਾ ਹੋਵੇ।
ਇਡੀਟਰ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਹੱਦੇ ਸੈੱਟ ਕਰੋ। ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ ਬੋਰਿੰਗ ਹੁੰਦੇ ਹਨ:
ਫਿਰ ਉਹ ਡੀਪੈਂਡੈਂਸੀਜ਼ ਲਿਸਟ ਕਰੋ ਜਿਹੜੀਆਂ ਕੋਡ ਹਿਲਾਉਣ ਵੇਲੇ ਖਾਮੋਸ਼ੀ ਨਾਲ ਬਰਤਾਓ ਤੋੜ ਸਕਦੀਆਂ ਹਨ: API calls, context providers, routing params, feature flags, analytics events ਅਤੇ ਸਾਂਝਾ ਗਲੋਬਲ state।
ਇੱਕ ਠੋਸ ਉਦਾਹਰਣ: ਤੁਹਾਡੇ ਕੋਲ 600-line OrdersTable ਹੈ ਜੋ ਡੇਟਾ ਫੈਚ ਕਰਦਾ, ਫਿਲਟਰ ਕਰਦਾ, ਸਿਲੈਕਸ਼ਨ ਨੂੰ ਮੈਨੇਜ ਕਰਦਾ ਅਤੇ ਡੀਟੇਲ ਲਈ ਇੱਕ ਡ੍ਰਾਅਰ dikhaunda। ਇਕ ਸਪਸ਼ਟ ਲਕੜੀ ਹੋ ਸਕਦੀ ਹੈ: "row rendering ਅਤੇ drawer UI ਨੂੰ ਕੰਪੋਨੈਂਟਾਂ ਵਿੱਚ ਕੱਢੋ, ਅਤੇ selection state ਨੂੰ ਇੱਕ reducer ਵਿੱਚ ਲਿਆਓ, ਬਿਨਾਂ UI ਬਦਲਾਅ ਦੇ।" ਇਹ ਲਕੜੀ ਦੱਸਦੀ ਹੈ ਕਿ "done" ਦਿਖਣ 'ਤੇ ਕੀ ਹੋਵੇਗਾ ਅਤੇ ਕੀ scope ਤੋਂ ਬਾਹਰ ਹੈ।
ਰੀਫੈਕਟਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕੰਪੋਨੈਂਟ ਨੂੰ ਕਾਲਾ ਬਾਕਸ ਸਮਝੋ। ਤੁਹਾਡੀ ਨੌਕਰੀ ਅੱਜ ਜੋ ਕਰਦਾ ਉਹ.capture ਕਰਨ ਦੀ ਹੈ, ਨਾ ਕਿ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਕਰੇ। ਇਸ ਨਾਲ ਰੀਫੈਕਟਰ redesign ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ।
ਸ਼ੁਰੂਆਤ ਕਰੋ ਮੌਜੂਦਾ ਬਰਤਾਓ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖ ਕੇ: ਇਹ ਇਨਪੁਟ ਦਿੱਤੇ ਜਾਣ 'ਤੇ UI ਇਹ ਨਤੀਜਾ ਦਿਖਾਉਂਦਾ। Props, URL params, feature flags ਅਤੇ context/ਸਟੋਰ ਤੋਂ ਆਉਣ ਵਾਲੇ ਡੇਟਾ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ Claude Code ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਛੋਟਾ, ਫੋਕਸ ਕੀਤਾ snippet ਪੇਸਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਆਖਣ ਲਈ ਕਹੋ ਕਿ ਇਹ ਪਹਿਨੇ ਵਾਲੀ ਭਾਸ਼ਾ ਵਿੱਚ ਵਰਨਨ ਕਰੇ ਜਿਹੜੀਆਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਚੈੱਕ ਕਰ ਸਕੋ।
ਉਹ UI ਹਾਲਤਾਂ ਕਵਰ ਕਰੋ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਵੇਖਦੇ ਹਨ। ਇੱਕ ਕੰਪੋਨੈਂਟ ਖੁਸ਼-ਰਾਹ 'ਤੇ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਲੋਡਿੰਗ, empty ਜਾਂ error ਦੇ ਸਮੇਂ ਟੁੱਟ ਸਕਦਾ ਹੈ।
ਉਹ ਇੰਪਲਿਸਿਟ ਨਿਯਮ ਵੀ ਕੈਪਚਰ ਕਰੋ ਜੋ ਆਸਾਨੀ ਨਾਲ ਲੁਕ ਜਾਂਦੇ ਹਨ ਅਤੇ ਅਕਸਰ ਰੀਫੈਕਟਰ ਨੂੰ ਤੋੜਦੇ ਹਨ:
ਉਦਾਹਰਣ: ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਯੂਜ਼ਰ ਟੇਬਲ ਹੈ ਜੋ ਨਤੀਜੇ ਲੋਡ ਕਰਦੀ, ਸਰਚ ਦਾ ਸਹਾਰਾ ਦਿੰਦੀ, ਅਤੇ "Last active" ਅਨੁਸਾਰ ਸੋਰਟ ਕਰਦੀ। ਲਿਖੋ ਕਿ ਜਦੋਂ search ਖਾਲੀ ਹੋਵੇ, ਜਦੋਂ API ਖਾਲੀ ਸੂਚੀ ਵਾਪਸ ਕਰੇ, ਜਦੋਂ API error ਕਰੇ, ਅਤੇ ਜਦੋਂ ਦੋ ਯੂਜ਼ਰਾਂ ਦੀ "Last active" ਸਮੇਂ ਇੱਕੋ ਜਿਹਾ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਛੋਟੇ ਵਿਸਥਾਰਾਂ ਨੂੰ ਦਰਜ ਕਰੋ ਜਿਵੇਂ ਕਿ ਸੋਰਟ case-insensitive ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਜਦੋਂ ਫਿਲਟਰ ਬਦਲਦਾ ਹੈ ਟੇਬਲ ਇਕੋ page ਰੱਖਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।
ਜਦੋਂ ਤੁਹਾਡੇ ਨੋਟ ਬੋਰਿੰਗ ਅਤੇ ਵਿਸਥਾਰ ਨਾਲ ਭਰੇ ਹੋਣ, ਤਾਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ।
Characterization tests "ਇਹ ਅੱਜ ਇਸ ਤਰ੍ਹਾਂ ਕਰਦਾ ਹੈ" ਟੈਸਟ ਹੁੰਦੇ ਹਨ। ਉਹ ਮੌਜੂਦਾ ਬਰਤਾਓ ਨੂੰ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਭਾਵੇਂ ਉਹ ajeeb ਹੋਵੇ ਜਾਂ ਲੰਮੇ ਸਮੇਂ ਲਈ ਠੀਕ ਨਾ ਲੱਗੇ। ਇਹ ਉਲਟ ਸੁਝਾਅ ਜਿਹਾ ਹੈ, ਪਰ ਇਹ ਰੀਫੈਕਟਰ ਨੂੰ ਲਾਪਰਵਾਹੀ ਨਾਲ rewrite ਬਣਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ Claude Code ਨਾਲ React ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰ ਰਹੇ ਹੋ, ਇਹ ਟੈਸਟ ਤੁਹਾਡੇ ਸੁਰੱਖਿਆ ਰੇਲਾਂ ਹਨ। ਟੂਲ ਕੋਡ ਨੂੰ ਰੀਸ਼ੇਪ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਨਹੀਂ ਬਦਲਣਾ।
ਯੂਜ਼ਰ ਅਤੇ ਹੋਰ ਕੋਡ ਜਿਸ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ ਉਸ 'ਤੇ ਧਿਆਨ ਦਿਓ:
ਟੈਸਟਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਲਈ, ਨਤੀਜਿਆਂ 'ਤੇ assert ਕਰੋ, implementation 'ਤੇ ਨਹੀਂ। "Save button disabled ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸੁਨੇਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ" ਨੂੰ ترجیح ਦਿਓ ਬਜਾਏ "setState ਕਾਲ ਹੋਈ" ਜਾਂ "ਇਹ hook ਚੱਲਿਆ"। ਜੇ ਟੈਸਟ ਟੁੱਟੇ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਕ ਕੰਪੋਨੈਂਟ ਦਾ ਨਾਮ ਬਦਲਿਆ ਜਾਂ hooks ਦੀ ਕ੍ਰਮਬੱਧਤਾ ਬਦਲੀ, ਤਾਂ ਉਹ ਬਰਤਾਓ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰ ਰਿਹਾ।
ਐਸਿੰਕ ਬਰਤਾਓ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਰੀਫੈਕਟਰ ਅਕਸਰ ਟਾਈਮਿੰਗ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਸਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਵਰਤੋ: UI ਦੇ settle ਹੋਣ ਦੀ ਉਡੀਕ ਕਰੋ, ਫਿਰ assert ਕਰੋ। ਜੇ timers ਹਨ (debounced search, delayed toasts), fake timers ਵਰਤੋ ਅਤੇ ਸਮਾਂ ਅੱਗੇ ਵਧਾਓ। ਜੇ ਨੈੱਟਵਰਕ ਕਾਲ ਹਨ, fetch ਨੂੰ mock ਕਰੋ ਅਤੇ success ਅਤੇ failure ਸਥਿਤੀਆਂ 'ਚ ਯੂਜ਼ਰ ਨੂੰ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਚੀਜ਼ assert ਕਰੋ। Suspense-ਵਾਂਗੇ flows ਲਈ, fallback ਅਤੇ resolved view ਦੋਹਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ।
ਉਦਾਹਰਣ: "Users" ਟੇਬਲ "No results" ਸਿਰਫ਼ search ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਦਿਖਾਉਂਦੀ ਹੈ। ਇੱਕ characterization test ਉਸ ਸੀਕਵੈਂਸ ਨੂੰ ਲਾਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਪਹਿਲਾਂ loading indicator, ਫਿਰ rows ਜਾਂ empty message, ਭਾਵੇਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕੰਪੋਨੈਂਟ ਕਿਵੇਂ ਵੀ ਵੰਡੋ।
ਜਿੱਤ "ਵੱਡੇ ਬਦਲਾਅ ਤੇਜ਼ ਹੋਣਾ" ਨਹੀਂ, ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਸਮਝੋ ਕਿ ਕੰਪੋਨੈਂਟ ਕੀ ਕਰਦਾ ਹੈ, ਫਿਰ ਹਰ ਵਾਰ ਇੱਕ ਛੋਟਾ ਚੇਜ਼ ਬਦਲੋ ਜਦੋਂ ਬਰਤਾਓ ਇਕੋ ਜਿਹਾ ਰਹੇ।
ਸ਼ੁਰੂ ਕਰੋ ਕੰਪੋਨੈਂਟ ਪੇਸਟ ਕਰਕੇ ਅਤੇ ਇਸ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦੀ ਸਧਾਰਨ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ summary ਮੰਗੋ। ਵਿਸਥਾਰ ਲਈ ਧੱਕੋ: ਇਹ ਕਿਹੜਾ ਡੇਟਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਕਿਹੜੀਆਂ ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ side effects ਟ੍ਰਿਗਰ ਹੁੰਦੇ ਹਨ (fetching, timers, subscriptions, analytics)। ਇਸ ਨਾਲ ਅਕਸਰ ਉਹ ਲੁਕਿਆ ਹੋਇਆ ਕੰਮ ਸਾਹਮਣੇ ਆ ਜਾਂਦਾ ਹੈ ਜੋ ਰੀਫੈਕਟਰ ਨੂੰ ਖਤਰਨਾਕ ਬਣਾਉਂਦਾ ਹੈ।
ਅਗਲੇ, dependency map ਮੰਗੋ। ਹਰ input ਅਤੇ output ਦਾ ਇਨਵੈਂਟਰੀ ਚਾਹੀਦਾ ਹੈ: props, context reads, custom hooks, local state, derived values, effects, ਅਤੇ ਕੋਈ module-level helpers। ਇੱਕ ਯੂਜ਼ਫੁਲ ਨਕਸ਼ਾ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ move ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਹੈ (pure calculations) ਅਤੇ ਕੀ "sticky" ਹੈ (ਟਾਈਮਿੰਗ, DOM, ਨੈੱਟਵਰਕ)।
ਫਿਰ ਇਸਨੂੰ extraction candidates ਦੇਣ ਲਈ ਕਹੋ, ਇੱਕ ਸਖਤ ਨਿਯਮ ਨਾਲ: pure view ਹਿੱਸਿਆਂ ਨੂੰ stateful controller ਹਿੱਸਿਆਂ ਤੋਂ ਅਲਗ ਕਰੋ। JSX-ਭਾਰੀ ਸੈਕਸ਼ਨ ਜੋ ਸਿਰਫ props ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ, ਪਹਿਲੇ ਹਨ। ਜਿਹੜੇ ਹਿੱਸੇ event handlers, async calls, ਅਤੇ state updates ਮਿਸ਼ਰਤ ਕਰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ ਹਨ।
ਇੱਕ ਵਰਕਫਲੋ ਜੋ ਅਸਲ ਕੋਡ ਵਿੱਚ ਟਿਕਦਾ ਹੈ:
Checkpoint ਮਹੱਤਵਪੂਰਨ ਹਨ। Claude Code ਤੋਂ ਇੱਕ ਨਿਊਨਤਮ ਯੋਜਨਾ ਮੰਗੋ ਜਿੱਥੇ ਹਰ ਕਦਮ commit ਅਤੇ revert ਕੀਤਾ ਜਾ ਸਕੇ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ checkpoint ਹੋ ਸਕਦਾ ਹੈ: "<TableHeader> ਨੂੰ extraction ਕਰੋ ਬਿਨਾਂ ਲੌਜਿਕ ਬਦਲਾਅ ਦੇ" ਪਹਿਲਾਂ sorting state ਨੂੰ ਛੂਹਣ ਤੋਂ।
ਉਦਾਹਰਣ: ਜੇ ਇੱਕ ਕੰਪੋਨੈਂਟ ਗਾਹਕ ਟੇਬਲ ਰੈਂਡਰ ਕਰਦਾ, ਫਿਲਟਰਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ, ਅਤੇ ਡੇਟਾ ਫੈਚ ਕਰਦਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਟੇਬਲ ਮਾਰਕਅਪ (headers, rows, empty state) ਨੂੰ pure component ਵਿੱਚ ਕੱਢੋ। ਫਿਰ ਹੀ filter state ਜਾਂ fetch effect ਨੂੰ move ਕਰੋ। ਇਹ ਕ੍ਰਮ bugs ਨੂੰ JSX ਨਾਲ ਨਾਲ ਭੇਜਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਵੱਡੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਵੰਡਦੇ ਹੋ, ਖਤਰਾ JSX move ਕਰਨ ਨਾਲ ਨਹੀਂ ਹੁੰਦਾ; ਖਤਰਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਡੇਟਾ ਫਲੋ, ਟਾਈਮਿੰਗ, ਜਾਂ ਇਵੈਂਟ ਵਾਇਰਿੰਗ ਅਕਸਿਡੈਂਟਲ ਬਦਲ ਦਿੰਦੇ ਹੋ। ਪਹਿਲਾਂ extraction ਨੂੰ copy-and-wire ਵਰਗਾ ਮਾਨੋ, ਅਤੇ cleanup ਬਾਅਦ ਕਰੋ।
ਸ਼ੁਰੂਆਤ ਕਰੋ UI ਵਿੱਚ ਪਹਿਲਾਂ ਮੌਜੂਦ ਸੀਮਾਵਾਂ ਨੂੰ ਲੱਭ ਕੇ, ਫਾਇਲ ਸਟ੍ਰਕਚਰ ਵਿੱਚ ਨਹੀਂ। ਉਹ ਹਿੱਸੇ ਲੱਭੋ ਜਿਹੜਿਆਂ ਨੂੰ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਬਣਾਕੇ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ: ਇੱਕ ਹੈਡਰ with actions, ਇੱਕ filter bar, ਇੱਕ results list, ਇੱਕ footer with pagination।
ਸੁਰੱਖਿਅਤ ਪਹਿਲਾ ਕਦਮ ਹੈ pure presentational components ਕੱਢਣਾ: props ਆਉਂਦੇ ਹਨ, JSX ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਜਾਣਬੂਝ ਕੇ ਬੋਰਿੰਗ ਰੱਖੋ। ਕੋਈ ਨਵੀਂ state, ਕੋਈ ਨਵਾਂ effect, ਕੋਈ ਨਵਾਂ API ਕਾਲ ਨਹੀਂ। ਜੇ ਮੂਲ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਇੱਕ click handler ਸੀ ਜੋ ਤਿੰਨ ਕੰਮ ਕਰਦਾ ਸੀ, ਤਾਂ ਉਹ handler parent ਵਿੱਚ ਹੀ ਰੱਖੋ ਅਤੇ ਨੀਵੇਂ ਕੰਪੋਨੈਂਟ ਨੂੰ pass ਕਰੋ।
ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਸਰਹੱਦ: header area, list ਅਤੇ row item, filters (inputs only), footer controls (pagination, totals, bulk actions), ਅਤੇ dialogs (open/close ਅਤੇ callbacks pass ਕੀਤੇ ਜਾ ਸਕਦੇ)।
ਨਾਮ ਚੁਣਨਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਖਾਸ ਨាមਾਂ ਵਰਤੋ ਜਿਵੇਂ UsersTableHeader ਜਾਂ InvoiceRowActions। "Utils" ਜਾਂ "HelperComponent" ਵਰਗੇ ਜੇਨਰਿਕ ਨਾਂਬਾਕਸ ਤੋਂ ਬਚੋ।
ਇੱਕ container component ਤਦ ਹੀ introduce ਕਰੋ ਜਦੋਂ ਵਾਸਤਵ ਵਿੱਚ ਲੋੜ ਹੋਵੇ: ਇੱਕ UI ਦੀ chunk ਜਿਸਨੂੰ state ਜਾਂ effects own ਕਰਨਿਆਂ ਲਾਜ਼ਮੀ ਹੋਵੇ। ਫਿਰ ਵੀ, ਇਸਨੂੰ ਤਾਂਗਰਾ ਰੱਖੋ—ਇੱਕ ਚੰਗਾ container ਇਕ ਹੀ ਮਕਸਦ own ਕਰਦਾ ਹੈ (ਜਿਵੇਂ "filter state") ਅਤੇ باقی ਸਾਰਾ ਕੰਮ props ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ।
ਗੰਦੇ ਕੰਪੋਨੈਂਟ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਕਿਸਮਾਂ ਦੇ ਡੇਟਾ ਮਿਲਾ ਦਿੰਦੇ ਹਨ: ਅਸਲੀ UI state (ਜੋ ਯੂਜ਼ਰ ਸੈਟ ਕਰਦਾ ਹੈ), derived data (ਜੋ ਤੁਸੀਂ compute ਕਰ ਸਕਦੇ ਹੋ), ਅਤੇ server state (ਜੋ ਨੈੱਟਵਰਕ ਤੋਂ ਆਉਂਦਾ ਹੈ)। ਜੇ ਤੁਸੀਂ ਸਾਰਾ ਕੁਝ local state ਵਾਂਗ treat ਕਰੋਗੇ, ਤਾਂ ਰੀਫੈਕਟਰ ਖਤਰਨਾਕ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਅਕਸਰ ਇਹ ਬਦਲ ਦਿੰਦੇ ਹੋ ਕਿ ਚੀਜ਼ਾਂ ਕਦੋਂ ਅਪਡੇਟ ਹੁੰਦੀਆਂ ਹਨ।
ਸ਼ੁਰੂਆਤ ਕਰੋ ਹਰ piece of data ਨੂੰ ਲੇਬਲ ਕਰਕੇ। ਪੁੱਛੋ: ਕੀ ਇਹ ਯੂਜ਼ਰ ਦੁਆਰਾ ਸੰਪਾਦਿਤ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਮੈਂ ਇਹ props/state/fetched data ਤੋਂ compute ਕਰ ਸਕਦਾ ਹਾਂ? ਇਹ ਵੀ ਪੁੱਛੋ: ਕੀ ਇਹ value ਇੱਥੇ own ਹੁੰਦੀ ਹੈ, ਜਾਂ ਸਿਰਫ਼ pass-through ਹੈ?
Derived values ਨੂੰ useState ਵਿੱਚ ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੀਦਾ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ function ਜਾਂ memoized selector ਵਿੱਚ move ਕਰੋ ਜਦੋਂ ਉਹ ਮਹਿੰਗੇ ہوں। ਇਹ state updates ਘਟਾਉਂਦਾ ਅਤੇ ਬਿਹਿਵਿਯਰ ਨੂੰ ਪੇਸ਼ਗੀ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ ਸੁਰੱਖਿਅਤ pattern:
useState ਵਿੱਚ ਰੱਖੋ।useMemo ਵਿੱਚ ਰੱਖੋ।Effects ਬਰਤਾਓ ਤਦ ਤੋੜਦੇ ਹਨ ਜਦੋਂ ਉਹ ਬਹੁਤ ਕੁਝ ਕਰਦੇ ਹਨ ਜਾਂ ਗਲਤ ਡੀਪੈਂਡੇਂਸੀਜ਼ 'ਤੇ ਰੀਐਕਟ ਕਰਦੇ ਹਨ। ਹਰੇਕ ਮਕਸਦ ਲਈ ਇੱਕ effect ਰੱਖੋ: ਇੱਕ localStorage ਲਈ, ਇੱਕ fetching ਲਈ, ਇੱਕ subscriptions ਲਈ। ਜੇ ਇੱਕ effect ਬਹੁਤ ਸਾਰੀਆਂ values ਪੜ੍ਹਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਵਧੇਰੇ ਜਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਛੁਪਾ ਰਿਹਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Claude Code ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਮੰਗੋ: ਇੱਕ effect ਨੂੰ ਦੋ ਵਿੱਚ ਵੰਡੋ, ਜਾਂ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ helper ਵਿੱਚ move ਕਰੋ। ਫਿਰ ਹਰ move ਤੋਂ ਬਾਅਦ characterization tests ਚਲਾਓ।
prop drilling ਦੇ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ। ਇਸਨੂੰ context ਨਾਲ ਬਦਲਣਾ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਮਦਦਗਾਰ ਹੈ ਜਦੋਂ ਇਹ ਦੋਹਰਾਈ ਹੋ ਰਹੀ wiring ਨੂੰ ਹਟਾਏ ਅਤੇ ownership ਨੂੰ ਸਪਸ਼ਟ ਕਰੇ। ਚੰਗਾ ਇशਾਰਾ ਹੈ ਜਦੋਂ context app-ਲੀਵਲ ਸੰਕਲਪ (current user, theme, feature flags) ਵਾਂਗ ਪੜ੍ਹਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ, ਨਾ ਕਿ ਇੱਕ ਕੰਪੋਨੈਂਟ ਟਰੀ ਲਈ workaround ਵਾਂਗ।
ਉਦਾਹਰਣ: ਇੱਕ ਟੇਬਲ ਕੰਪੋਨੈਂਟ rows ਅਤੇ filteredRows ਦੋਹਾਂ state ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ। rows ਨੂੰ state ਰੱਖੋ, filteredRows ਨੂੰ rows + query ਤੋਂ compute ਕਰੋ, ਅਤੇ filtering code ਨੂੰ ਇੱਕ pure function ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਉਹ ਟੈਸਟ ਕਰਨਾ ਆਸਾਨ ਅਤੇ ਤੋੜਨਾ ਔਖਾ ਹੋਵੇ।
ਰੀਫੈਕਟਰ ਸਭ ਤੋਂ ਵੱਧ ਤਬ ਗਲਤ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਬਹੁਤ ਕੁਝ ਬਦਲ ਦਿੰਦੇ ਹੋ ਜਦੋਂ ਤੱਕ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ। ਹੱਲ ਸਧਾਰਨ ਹੈ: ਛੋਟੇ checkpoint ਵਿੱਚ ਕੰਮ ਕਰੋ, ਅਤੇ ਹਰ checkpoint ਨੂੰ ਇੱਕ ਛੋਟੇ ਜਿਹੇ ਰਿਲੀਜ਼ ਵਾਂਗ ਮਾਨੋ। ਭਾਵੇਂ ਤੁਸੀਂ ਇੱਕ ਬ੍ਰਾਂਚ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਆਪਣੀਆਂ ਸੋਧਾਂ PR-ਆਕਾਰ ਦੀਆਂ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਕਿ ਕੀ ਟੁੱਟਿਆ ਅਤੇ ਕਿਉਂ।
ਹਰ ਮਹੱਤਵਪੂਰਨ move (component extraction, state flow ਬਦਲਣਾ) ਤੋਂ ਬਾਅਦ ਰੁਕੋ ਅਤੇ ਸਾਬਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਬਰਤਾਓ ਨਹੀਂ ਬਦਲਿਆ। ਇਹ ਸਬੂਤ automated (tests) ਅਤੇ manual (ਤੇਜ਼ ਚੈਕ) ਹੋ ਸਕਦਾ ਹੈ। ਲਕੜੀ ਇਹ ਨਹੀਂ ਕਿ ਸਭ ਕੁਝ ਪੂਰਨ ਹੋਵੇ—ਇਸਦਾ ਮਕਸਦ ਤੇਜ਼ ਪਤਾ ਲਾਉਣਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ checkpoint ਲੂਪ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, snapshots ਅਤੇ rollback ਤੁਹਾਡੇ ਲਈ ਸੁਰੱਖਿਅਤ ਰੇਲਾਂ ਵਾਂਗ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ। ਫਿਰ ਵੀ, ਸਧਾਰਨ commits ਪਸੰਦ ਕਰੋ, ਪਰ snapshots ਉਹ ਵੇਲੇ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਨੂੰ "known good" ਵਰਜਨ ਨਾਲ ਤੁਲਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ।
ਇੱਕ ਸਰਲ ਬਿਹੈਵਿਅਰ ਲੈਜਰ ਰੱਖੋ ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਕੀ ਵੈਰੀਫਾਈ ਕੀਤਾ—ਇਹ ਸਿਰਫ਼ ਇੱਕ ਛੋਟੀ ਨੋਟ ਹੈ ਜੋ ਇਹ ਰੋਕਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਇਕੋ ਚੀਜ਼ ਇਕੱਥੇ ਬਾਰ-ਬਾਰ ਚੈੱਕ ਕਰੋ।
ਉਦਾਹਰਣ:
ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਲੈਜਰ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਦੁਬਾਰਾ ਚੈੱਕ ਕਰਨਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ checkpoints ਰਿਵਰਟ ਕਰਨਾ ਸਸਤਾ ਬਣਾਉਂਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਰੀਫੈਕਟਰ ਛੋਟੀਆਂ, ਬੋਰਿੰਗ ਗਲਤੀਆਂ ਨਾਲ fail ਹੁੰਦੇ ਹਨ। UI ਹਾਲੇ ਵੀ ਕੰਮ ਕਰਦਾ ਦਿਖਦਾ ਹੈ, ਪਰ spacing rule ਗਾਇਬ, click handler ਦੁਬਾਰਾ ਦੋ ਵਾਰ ਫਾਇਰ, ਜਾਂ ਲਿਸਟ ਟਾਈਪ ਕਰਦੇ ਸਮੇਂ ਫੋਕਸ ਛੱਡ ਸਕਦੀ ਹੈ। ਸਹਾਇਕ ਇੱਥੇ ਹੋਰ ਖ਼ਤਰਾ ਜੋੜ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਡ ਚੰਗਾ ਲੱਗਦਾ ਹੈ ਪਰ ਬਰਤਾਓ ਬਦਲ ਰਿਹਾ ਹੈ।
ਇੱਕ ਆਮ ਕਾਰਨ structure ਬਦਲ ਰਿਹਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਕੰਪੋਨੈਂਟ ਕੱਢਦੇ ਹੋ ਅਤੇ ਵਧੇਰੇ <div> ਰੈਪ ਕਰ ਦਿੰਦੇ ਹੋ, ਜਾਂ <button> ਦੀ ਥਾਂ clickable <div> ਰੱਖ ਦੇਂਦੇ ਹੋ। CSS selectors, layout, keyboard navigation, ਅਤੇ test queries ਬਦਲ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਦੇ ਧਿਆਨ ਵਿੱਚ ਆਏ।
ਵੋ traps ਜੋ ਅਕਸਰ ਬਰਤਾਓ ਤੋੜਦੀਆਂ ਹਨ:
{} ਜਾਂ () => {} ਨਵੀਂ objects/functions ਬਣਾਉਂਦੇ ਹਨ ਜਿਹੜੀਆਂ extra re-renders ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ child state reset ਕਰ ਸਕਦੀਆਂ ਹਨ। ਉਹ props ਜਿਨ੍ਹਾਂ ਦਾ ਪਹਿਲਾਂ stable reference ਸੀ, ਉਹਨਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ।useEffect, useMemo, ਜਾਂ useCallback ਵਿੱਚ move ਕਰਨ ਨਾਲ stale values ਜਾਂ loops ਆ ਸਕਦੇ ਹਨ ਜੇ dependencies ਗਲਤ ਹੋਣ। ਜੇ ਇੱਕ effect ਪਹਿਲਾਂ "on click" ਚਲਦਾ ਸੀ, ਤਾਂ ਉਸਨੂੰ ਕਦੇ "whenever anything changes" ਬਣਾਉਣਾ ਨਹੀਂ।ਉਦਾਹਰਣ: ਇੱਕ ਟੇਬਲ ਕੰਪੋਨੈਂਟ ਨੂੰ ਵੰਡਦੇ ਸਮੇਂ row keys ਨੂੰ ID ਤੋਂ array index 'ਤੇ ਬਦਲਣਾ ਪਹਿਲੇ ਵਜੋਂ ਠੀਕ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ reorder 'ਤੇ selection state ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ। "ਸਾਫ" ਇੱਕ ਬੋਨਸ ਸਮਝੋ; "ਉਹੀ ਬਰਤਾਓ" ਲਾਜ਼ਮੀ ਹੈ।
ਮਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਸਬੂਤ ਚਾਹੀਦਾ ਹੈ ਕਿ ਰੀਫੈਕਟਰ ਨੇ ਬਰਤਾਓ ਨੂੰ ਇਕੋ ਜਿਹਾ ਰੱਖਿਆ। ਸਭ ਤੋਂ ਆਸਾਨ ਸਿਗਨਲ ਬੋਰਿੰਗ ਹੈ: ਸਭ ਕੁਝ ਹੁਣ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਟੈਸਟ "ਫਿਕਸ" ਕਰਨ ਦੀ ਲੋੜ ਪਏ।
ਆਖਰੀ ਛੋਟੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਇਹ ਤੇਜ਼ ਗੁਜ਼ਰ-ਚੇਕ ਚਲਾਓ:
onChange ਵਰਗੀ callback ਹਮੇਸ਼ਾਂ ਯੂਜ਼ਰ ਇੰਪੁੱਟ 'ਤੇ ਫਾਇਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, mount 'ਤੇ ਨਹੀਂ)।ਇੱਕ ਤੇਜ਼ sanity check: ਕੰਪੋਨੈਂਟ ਖੋਲੋ ਅਤੇ ਇੱਕ ਅਜੀਬ ਫਲੋ ਕਰੋ, ਜਿਵੇਂ error ਟ੍ਰਿਗਰ ਕਰੋ, retry ਕਰੋ, ਫਿਰ filters ਮਿਟਾਓ। ਰੀਫੈਕਟਰ ਅਕਸਰ transitions ਨੂੰ ਤੋੜਦੇ ਹਨ ਭਾਵੇਂ ਮੁੱਖ ਰਾਹ ਕੰਮ ਕਰਦਾ ਹੋਵੇ।
ਜੇ ਕੋਈ item fail ਹੁੰਦਾ ਹੈ, ਤਾਂ ਆਖਰੀ change ਰਿਵਰਟ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਹੋਰ ਛੋਟੇ ਕਦਮ ਵਿੱਚ ਦੁਬਾਰਾ ਕਰੋ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ diff ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਨਾਲੋਂ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ProductTable ਕੰਪੋਨੈਂਟ ਦਾ ਜੋ ਸਭ ਕੁਝ ਕਰਦਾ: ਡੇਟਾ ਫੈਚ ਕਰਦਾ, filters ਮੈਨੇਜ ਕਰਦਾ, pagination ਨਿਯੰਤਰਿਤ ਕਰਦਾ, delete ਲਈ confirm dialog ਖੋਲ੍ਹਦਾ, ਅਤੇ row actions (edit, duplicate, archive) ਸੰਭਾਲਦਾ। ਸ਼ੁਰੂ ਵਿੱਚ ਛੋਟਾ ਸੀ, ਫਿਰ 900-line ਫਾਇਲ ਹੋ ਗਿਆ।
ਲੱਛਣਾਂ ਪਰਿਚਿਤ ਹਨ: state useState ਵਿੱਚ ਫੈਲੀ ਹੋਈ, ਕੁਝ useEffects ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕ੍ਰਮ ਵਿੱਚ ਚਲ ਰਹੀਆਂ, ਅਤੇ ਇੱਕ "ਨਿਰਦੋਸ਼" ਬਦਲਾਅ pagination ਨੂੰ ਟੁੱਟ ਦੇਂਦਾ ਹੈ ਜਦੋਂ filter active ਹੋਵੇ। ਲੋਕ ਇਸਨੂੰ ਛੁਹਣਾ ਛੱਡ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਅਣਅਨੁਮਿਯਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਸੰਰਚਨਾ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਕੁਝ React characterization tests ਲਾਕ ਕਰੋ। ਯੂਜ਼ਰ ਕੀ ਕਰਦਾ ਹੈ, ਇਸ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਨਾ ਕਿ اندرੂਨੀ state:
ਹੁਣ ਤੁਸੀਂ ਛੋਟੇ commits ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਕ ਸਾਫ਼ extraction ਯੋਜਨਾ ਦਿਿਆਂ ਹੋ ਸਕਦੀ ਹੈ: FilterBar controls ਰੈਂਡਰ ਕਰਦਾ ਅਤੇ filter changes emit ਕਰਦਾ; TableView rows ਅਤੇ pagination ਰੈਂਡਰ ਕਰਦਾ; RowActions action menu ਅਤੇ confirm dialog UI ਨੂੰ own ਕਰਦਾ; ਅਤੇ ਇੱਕ useProductTable hook messy logic (query params, derived state, side effects) ਨੂੰ own ਕਰਦਾ।
ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਪਹਿਲਾਂ dumb UI ( TableView, FilterBar) ਕੱਢੋ ਅਤੇ props unmodified ਰੱਖੋ। ਖਤਰਨਾਕ ਹਿੱਸਾ ਆਖ਼ਿਰ ਨੂੰ ਰੱਖੋ: state ਅਤੇ effects ਨੂੰ useProductTable ਵਿੱਚ move ਕਰਨਾ। ਇਸ ਵੇਲੇ पुराने prop names ਅਤੇ event shapes ਰੱਖੋ ਤਾਂ ਕਿ tests ਪਾਸ ਰਹਿਣ। ਜੇ ਕੋਈ ਟੈਸਟ ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ behavior change ਮਿਲੀ—ਇੱਕ style issue ਨਹੀਂ।
ਜੇ ਤੁਸੀਂ Claude Code ਨਾਲ React ਕੰਪੋਨੈਂਟਾਂ ਦੀ ਰੀਫੈਕਟਰਿੰਗ ਹਰ ਵਾਰੀ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਵਾਉਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਜੋ ਕੁਝ ਤੁਸੀਂ ਹਾਲ ਹੀ ਵਿੱਚ ਕੀਤਾ ਉਸਨੂੰ ਇੱਕ ਛੋਟੀ ਟੈਮਪਲੇਟ ਬਣਾ ਲਓ। ਮਕਸਦ ਜ਼ਿਆਦਾ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ, ਘੱਟ ਅਚਾਨਕੀਆਂ ਹੈ।
ਕੋਈ ਛੋਟੀ ਪਲੇਅਬੁੱਕ ਲਿਖੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਕੰਪੋਨੈਂਟ 'ਤੇ ਫਾਲੋ ਕਰ ਸਕੋ:
ਇਸਨੂੰ ਆਪਣੇ ਨੋਟ ਜਾਂ ਰੇਪੋ ਵਿੱਚ ਸਕਿੱਪੇਟ ਵਾਂਗ ਸੇਵ ਕਰੋ ਤਾਂ ਕਿ ਅਗਲਾ ਰੀਫੈਕਟਰ ਉੱਪਰੋਂ ਹੀ ਉਸੇ ਸੁਰੱਖਿਆ ਰੇਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਵੇ।
ਜਦੋਂ ਕੰਪੋਨੈਂਟ ਸਥਿਰ ਅਤੇ ਪੜ੍ਹਨ ਲਈ ਆਸਾਨ ਹੋ ਜਾਏ, ਤਾਂ ਅਗਲਾ ਪਾਸ ਉਪਭੋਗੀ ਪ੍ਰਭਾਵ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣੋ। ਆਮ ਕ੍ਰਮ: accessibility ਪਹਿਲਾਂ (labels, focus, keyboard), ਫਿਰ performance (memoization, expensive renders), ਫਿਰ cleanup (types, naming, dead code)। ਇੱਕੀ PR ਵਿੱਚ ਇਹ ਤਿੰਨ ਇਕੱਠੇ ਨਾ ਮਿਲਾਓ।
ਜੇ ਤੁਸੀਂ vibe-coding ਵਰਕਫਲੋ ਵਰਤਦੇ ਹੋ ਜਿਵੇਂ Koder.ai (koder.ai), planning mode ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਕਦਮਾਂ ਨੂੰ ਰੂਪ ਰੇਖਾ ਦੇਣ ਵਿੱਚ, ਅਤੇ snapshots/rollback checkpoint ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਖਤਮ ਕਰ ਲਓ, source export final diff ਦੀ ਸਮੀਖਿਆ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਤਿਹਾਸ ਸਾਫ਼ ਰੱਖਦਾ ਹੈ।
ਜਦੋਂ ਟੈਸਟ ਉਹ ਰਸਤੇ ਕਵਰ ਕਰ ਲੈਂ ਜੋ ਤੁਹਾਨੂੰ ਤੋੜਣ ਤੋਂ ਡਰਾਉਂਦੇ ਸਨ, ਅਗਲਾ change feature ਹੋਵੇ, ਜਾਂ ਤੁਸੀਂ ਇੱਕੋ PR ਵਿੱਚ perfect ਕਰਨ ਦੀ ਲਾਲਸ ਮਹਿਸੂਸ ਕਰੋ—ਉਸਤੋਂ ਬਾਅਦ ਰੋਕੋ। ਜੇ ਵੱਡੇ ਫਾਰਮ ਨੂੰ ਵੰਡਣ ਨਾਲ tangled state ਹਟ ਗਿਆ ਅਤੇ ਤੁਹਾਡੇ tests validation ਅਤੇ submit ਨੂੰ ਕਵਰ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਸ਼ਿਪ ਕਰੋ। ਬਾਕੀ ਵਿਚਾਰ ਛੋਟੇ ਬੈਕਲੌਗ ਵਜੋਂ ਰੱਖੋ।
React ਰੀਫੈਕਟਰ ਅਕਸਰ ਪਛਾਣ ਅਤੇ ਟਾਈਮਿੰਗ ਨੂੰ ਬਿਨਾਂ ਧਿਆਨ ਦਿੱਤੇ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਟੁੱਟਣ ਵਾਲੀਆਂ ਬਰਤਾਵਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
key ਦੀ ਬਦਲਤੋਂ state ਰੀਸੈਟ ਹੋਣਾ।ਟੈਸਟਾਂ ਦੇ ਰਾਹੀਂ ਸਾਬਤ ਕਰਨ ਤੱਕ ਹਰ סטרਕਚਰਲ ਚੇਂਜ ਨੂੰ ਬਰਤਾਵ ਚੇਂਜ ਸਮਝੋ।
ਇੱਕ ਟਾਈਟ, ਤੇਜ਼ੀ ਨਾਲ ਚੈੱਕ ਹੋ ਸਕਣ ਵਾਲਾ ਲਕੜੀ-ਧਾਰਾ ਹੇਠਾਂ ਵਧੀਆ ਹੈ: "ਹੈੱਡਰ, ਰੋਜ਼, ਅਤੇ ਡ੍ਰਾਅਰ ਨੂੰ ਕੰਪੋਨੈਂਟਾਂ ਵਿੱਚ ਕੱਢੋ ਬਿਨਾਂ ਕੋਈ UI ਬਦਲਾਅ" ਜਾਂ "ਚੁਣਾਉਣ ਵਾਲੀ state ਨੂੰ ਇੱਕ reducer ਵਿੱਚ ਖੇਚ ਕੇ ਇਵੈਂਟਾਂ ਜਾਂ props ਨਹੀਂ ਬਦਲਣੇ।"
"ਇਹੇਟ ਕਰੋ" ਜਾਂ "ਬਿਹਤਰ ਬਣਾਓ" ਵਰਗੇ ਲਕੜੀ-ਨਿਰਧਾਰਿਤ ਟੀਚਿਆਂ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਨਾਪ-ਤੋਲੀ ਹੋਵੇ।
ਕੰਪੋਨੈਂਟ ਨੂੰ ਇੱਕ ਬਲੈਕ ਬਾਕਸ ਵਾਂਗ ਦੇਖੋ ਅਤੇ ਇਹ ਲਿਖੋ ਕਿ ਯੂਜ਼ਰ ਕੀ ਦੇਖਦਾ/ਕਰਦਾ ਹੈ:
ਜੇ ਤੁਹਾਡੇ ਨੋਟ ਵਿਸਥਾਰ ਨਾਲ ਬੋਰਿੰਗ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਉਹ ਉਪਯੋਗੀ ਹਨ।
Characterization tests ਜਿਹੜੇ ਕਹਿੰਦੇ ਹਨ ਕਿ ਕੰਪੋਨੈਂਟ ਅੱਜ ਕੀ ਕਰਦਾ ਹੈ, ਸਭ ਤੋਂ ਵਧੀਆ ਸੁਰੱਖਿਆ ਦਿੰਦੇ ਹਨ।
ਇਹਨਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ:
ਟੈਸਟ ਵਿੱਚ implementation ਨਹੀਂ, ਨਤੀਜੇ ਅਸਰ ਤੇ assert ਕਰੋ।
ਉਸਨੂੰ ਇਕ ਧਿਆਨਸ਼ੀਲ pair programmer ਵਾਂਗ ਵਰਤੋਂ:
ਵੱਡਾ "ਰੀਰਾਈਟ-ਸ਼ੈਲੀ" ਡਿਫ ਨਾ ਮਨਜ਼ੂਰ ਕਰੋ; ਇੰਕ੍ਰਿਮੇਨਟਲ ਸੋਧਾਂ ਲਈ ਦਬਾਓ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਵੈਰੀਫਾਈ ਕਰ ਸਕੋ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਪਿਓਰ ਪ੍ਰਜ਼ੇਂਟੇਸ਼ਨਲ ਹਿੱਸਿਆਂ ਨੂੰ ਕੱਢੋ:
ਪਹਿਲਾਂ copy-and-wire ਕਰੋ; ਬਾਅਦ ਵਿੱਚ cleanup ਕਰੋ। UI ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਵੰਡਣ ਤੋਂ ਬਾਅਦ ਹੀ state/effects ਨੂੰ ਹਟਾਓ।
ਸਥਿਰ ਪਛਾਣ (ਜਿਵੇਂ ID) ਵਾਲੇ keys ਵਰਤੋ, ਨਾ ਕਿ array index।
ਇੰਡੈਕਸ keys ਅਕਸਰ ਕੰਮ ਕਰਦੇ ਹਨ ਪਰ ਜਦੋਂ ਤੁਸੀਂ sort/filter/insert/remove ਕਰੋ ਤਾਂ React ਗਲਤ instance reuse ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ:
ਜੇ ਤੁਹਾਡਾ ਰੀਫੈਕਟਰ keys ਨੂੰ ਬਦਲਦਾ ਹੈ ਤਾਂ ਇਸਨੂੰ ਉੱਚ-ਖਤਰਾ ਮੰਨੋ ਅਤੇ reorder ਕੇਸਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ।
Derived value ਨੂੰ useState ਵਿੱਚ ਰੱਖਣ ਦੀ ਥਾਂ ਕੁੰਪਿਊਟ ਕਰੋ:
rows + query ਤੋਂ filteredRows ਕਪਿਉਟ ਕਰੋuseMemo ਵਰਤੋਂਇੱਕ checkpoint ਲੂਪ ਵਰਤੋਂ ਤਾਂ ਜੋ ਹਰ ਕਦਮ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਰਿਵਰਟ ਕੀਤਾ ਜਾ ਸਕੇ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ snapshots ਅਤੇ rollback ਆਮ commits ਨੂੰ ਸਹਾਇਕ ਬਣਾਉਂਦੇ ਹਨ।
ਜਦੋਂ ਬਰਤਾਓ ਲਾਕ ਹੋ ਗਿਆ ਹੋਵੇ ਅਤੇ ਕੋਡ ਬਦਲਣਾ ਆਸਾਨੀ ਨਾਲ ਹੋਵੇ ਤਾਂ ਰੋਕੋ। ਚੰਗੇ ਸੰਕੇਤ:
ਰੀਫੈਕਟਰ ਸ਼ਿਪ ਕਰੋ ਅਤੇ ਬਾਕੀ ਆਈਟਮਾਂ ਲਈ ਛੋਟਾ ਬੈਕਲੌਗ ਬਣਾਓ (ਐਕਸੈਸਬਿਲਟੀ, ਪ੍ਰਦਰਸ਼ਨ, ਸਾਫ਼-ਸੁਥਰਾ ਕਰਨਾ)।
ਇਸ ਨਾਲ ਅਪਡੇਟ ਅਚਰਿਤਰ ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕੋਡ ਅਸਾਨ ਬਣਦਾ ਹੈ।