डेटा शेप को स्टेट शेप समझने की गलती न करें
जब आप एक React फॉर्म बनाते हैं, तो आप अक्सर सब कुछ एक बड़े state object में समूहित कर देते हैं।
आप अपने UI में एक Address सेक्शन देखते हैं। आप अपने state में एक address object बनाते हैं। यह व्यवस्थित दिखता है। यह साफ-सुथरा दिखता है।
यह एक जाल है।
समस्या React में नहीं है। समस्या आपके state के shape में है।
फॉर्म्स static data नहीं होते। वे interactive systems होते हैं। यूज़र्स फॉर्म को सेक्शन दर सेक्शन अपडेट नहीं करते। वे उन्हें field दर field अपडेट करते हैं।
Why nested state hurts your project:
- अपडेट भारी हो जाते हैं। एक शहर का नाम बदलने के लिए, आपको immutability बनाए रखने के लिए शहर, पता (address), और top-level form object को फिर से बनाना पड़ता है।
- जटिलता बढ़ती जाती है। जैसे-जैसे फॉर्म बढ़ता है, आपके validation और rendering logic को मैनेज करना कठिन हो जाता है।
- Re-renders बढ़ जाते हैं। एक nested value को बदलने से नए object references बनते हैं। इससे आपके पूरे component tree में अनावश्यक अपडेट ट्रिगर हो सकते हैं।
- मानसिक बोझ (Mental overhead) बढ़ जाता है। आप यूज़र के बारे में सोचना बंद कर देते हैं और object paths के बारे में सोचने लगते हैं।
छोटे फॉर्म्स में यह समस्या कम होती है। प्रोडक्ट फॉर्म्स में नहीं।
एक production form को validation, autosave, और conditional logic की आवश्यकता होती है। यदि आप इन्हें एक गहरे nested object के ऊपर बनाते हैं, तो हर नया फीचर महंगा महसूस होता है।
समाधान यह है कि state को इस आधार पर डिज़ाइन किया जाए कि डेटा कैसे बदलता है, न कि इस आधार पर कि वह कैसा दिखता है।
A flatter state shape offers these benefits:
- तेज़ अपडेट। एक सिंगल वैल्यू बदलने के लिए आपको कम कोड बदलना पड़ता है।
- आसान डिबगिंग। अपडेट लोकल और प्रेडिक्टेबल रहते हैं।
- बेहतर component boundaries। आप बड़े objects के बजाय डेटा के छोटे हिस्से पास कर सकते हैं।
बिना सोचे-समझे सब कुछ flatten न करें। यदि डेटा शायद ही कभी बदलता है और हमेशा एक साथ चलता है, तो nesting ठीक है। लेकिन अपने फॉर्म के उन हिस्सों को nest न करें जो लगातार बदलते रहते हैं।
Ask yourself these questions before you code:
- कौन से fields सबसे अधिक बार बदलते हैं?
- किन sections को स्वतंत्र validation की आवश्यकता है?
- कौन से अपडेट बाकी UI से अलग रहने चाहिए?
यदि एक field को अपडेट करना स्वयं बदलाव से अधिक कठिन लगता है, तो आपकी state structure ही समस्या है।
अपने state को अपने UI के आधार पर मॉडल करना बंद करें। इसे अपने यूज़र के व्यवहार (behavior) के आधार पर मॉडल करना शुरू करें।