ਡਾਟਾ ਸ਼ੇਪ (Data Shape) ਨੂੰ ਸਟੇਟ ਸ਼ੇਪ (State Shape) ਸਮਝਣ ਦੀ ਗਲਤੀ ਨਾ ਕਰੋ
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ React ਫਾਰਮ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ ਸਭ ਕੁਝ ਇੱਕ ਵੱਡੇ state object ਵਿੱਚ ਇਕੱਠਾ ਕਰ ਦਿੰਦੇ ਹੋ।
ਤੁਸੀਂ ਆਪਣੇ UI ਵਿੱਚ ਇੱਕ Address ਸੈਕਸ਼ਨ ਦੇਖਦੇ ਹੋ। ਤੁਸੀਂ ਆਪਣੇ state ਵਿੱਚ ਇੱਕ address object ਬਣਾਉਂਦੇ ਹੋ। ਇਹ ਸੰਗਠਿਤ ਲੱਗਦਾ ਹੈ। ਇਹ ਸਾਫ਼-ਸੁਥਰਾ ਲੱਗਦਾ ਹੈ।
ਇਹ ਇੱਕ ਜਾਲ ਹੈ।
ਸਮੱਸਿਆ React ਦੀ ਨਹੀਂ ਹੈ। ਸਮੱਸਿਆ ਤੁਹਾਡੇ state ਦੀ ਸ਼ੇਪ (shape) ਦੀ ਹੈ।
ਫਾਰਮ ਸਟੈਟਿਕ ਡਾਟਾ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਇੰਟਰਐਕਟਿਵ ਸਿਸਟਮ ਹੁੰਦੇ ਹਨ। ਯੂਜ਼ਰ ਫਾਰਮਾਂ ਨੂੰ ਸੈਕਸ਼ਨ-ਦਰ-ਸੈਕਸ਼ਨ ਅਪਡੇਟ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਉਹਨਾਂ ਨੂੰ ਫੀਲਡ-ਦਰ-ਫੀਲਡ ਅਪਡੇਟ ਕਰਦੇ ਹਨ।
Nested state ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਕਿਉਂ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀ ਹੈ:
- ਅਪਡੇਟਸ ਭਾਰੀ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਸ਼ਹਿਰ ਦਾ ਨਾਮ ਬਦਲਣ ਲਈ, ਤੁਹਾਨੂੰ immutability ਬਣਾਈ ਰੱਖਣ ਲਈ ਸ਼ਹਿਰ, ਐਡਰੈੱਸ ਅਤੇ ਟੌਪ-ਲੈਵਲ ਫਾਰਮ ਆਬਜੈਕਟ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਪੈਂਦਾ ਹੈ।
- ਜਟਿਲਤਾ (Complexity) ਵਧਦੀ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ ਫਾਰਮ ਵਧਦਾ ਹੈ, ਤੁਹਾਡਾ validation ਅਤੇ rendering logic ਪ੍ਰਬੰਧਿਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ।
- Re-renders ਵਧ ਜਾਂਦੇ ਹਨ। ਇੱਕ nested value ਨੂੰ ਬਦਲਣ ਨਾਲ ਨਵੇਂ object references ਬਣਦੇ ਹਨ। ਇਹ ਤੁਹਾਡੇ ਪੂਰੇ component tree ਵਿੱਚ ਬੇਲੋੜੇ ਅਪਡੇਟਸ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।
- ਮਾਨਸਿਕ ਬੋਝ ਵਧਦਾ ਹੈ। ਤੁਸੀਂ ਯੂਜ਼ਰ ਬਾਰੇ ਸੋਚਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਅਤੇ object paths ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ।
ਛੋਟੇ ਫਾਰਮਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਚੱਲ ਜਾਂਦੀਆਂ ਹਨ। ਪਰ ਪ੍ਰੋਡਕਟ ਫਾਰਮਾਂ ਵਿੱਚ ਨਹੀਂ।
ਇੱਕ production ਫਾਰਮ ਨੂੰ validation, autosave, ਅਤੇ conditional logic ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਨੂੰ ਇੱਕ ਡੂੰਘੇ nested object ਦੇ ਉੱਪਰ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਹਰ ਨਵਾਂ ਫੀਚਰ ਮਹਿੰਗਾ (ਔਖਾ) ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਹੱਲ ਇਹ ਹੈ ਕਿ state ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਵੇ ਕਿ ਡਾਟਾ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ, ਨਾ ਕਿ ਇਹ ਕਿ ਇਹ ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ।
ਇੱਕ flatter state shape ਇਹ ਫਾਇਦੇ ਦਿੰਦੀ ਹੈ:
- ਤੇਜ਼ ਅਪਡੇਟਸ। ਇੱਕ ਸਿੰਗਲ ਵੈਲਯੂ ਬਦਲਣ ਲਈ ਤੁਹਾਨੂੰ ਘੱਟ ਕੋਡ ਨੂੰ ਛੂਹਣਾ ਪੈਂਦਾ ਹੈ।
- ਡਿਬੱਗਿੰਗ (Debugging) ਆਸਾਨ ਹੁੰਦੀ ਹੈ। ਅਪਡੇਟਸ ਸਥਾਨਕ (local) ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਰਹਿੰਦੇ ਹਨ।
- ਬਿਹਤਰ component boundaries। ਤੁਸੀਂ ਵੱਡੇ ਆਬਜੈਕਟਾਂ ਦੀ ਬਜਾਏ ਡਾਟਾ ਦੇ ਛੋਟੇ ਹਿੱਸੇ ਪਾਸ ਕਰ ਸਕਦੇ ਹੋ।
ਸਭ ਕੁਝ ਅੰਨ੍ਹੇਵਾਹ ਫਲੈਟ (flatten) ਨਾ ਕਰੋ। ਜੇਕਰ ਡਾਟਾ ਬਹੁਤ ਘੱਟ ਬਦਲਦਾ ਹੈ ਅਤੇ ਹਮੇਸ਼ਾ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ nesting ਠੀਕ ਹੈ। ਪਰ ਆਪਣੇ ਫਾਰਮ ਦੇ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ nest ਨਾ ਕਰੋ ਜੋ ਲਗਾਤਾਰ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ।
ਕੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਆਪ ਨੂੰ ਇਹ ਸਵਾਲ ਪੁੱਛੋ:
- ਕਿਹੜੀਆਂ ਫੀਲਡਾਂ ਸਭ ਤੋਂ ਅਕਸਰ ਬਦਲਦੀਆਂ ਹਨ?
- ਕਿਹੜੇ ਸੈਕਸ਼ਨਾਂ ਨੂੰ ਸੁਤੰਤਰ (independent) validation ਦੀ ਲੋੜ ਹੈ?
- ਕਿਹੜੇ ਅਪਡੇਟਸ ਬਾਕੀ UI ਤੋਂ ਅਲੱਗ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ?
ਜੇਕਰ ਇੱਕ ਫੀਲਡ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਖੁਦ ਬਦਲਾਅ ਨਾਲੋਂ ਵਧੇਰੇ ਔਖਾ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ state structure ਹੀ ਸਮੱਸਿਆ ਹੈ।
ਆਪਣੇ state ਨੂੰ ਆਪਣੇ UI ਦੇ ਆਧਾਰ 'ਤੇ ਮਾਡਲ ਕਰਨਾ ਬੰਦ ਕਰੋ। ਇਸਨੂੰ ਆਪਣੇ ਯੂਜ਼ਰ ਦੇ ਵਿਵਹਾਰ (behavior) ਦੇ ਆਧਾਰ 'ਤੇ ਮਾਡਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ।