𝗗𝗼𝗻’𝘁 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 𝗗𝗮𝘁𝗮 𝗦𝗵𝗮𝗽𝗲 𝗳𝗼𝗿 𝗦𝘁𝗮𝘁𝗲 𝗦𝗵𝗮𝗽𝗲
जेव्हा तुम्ही React फॉर्म तयार करता, तेव्हा तुम्ही अनेकदा सर्व गोष्टी एका मोठ्या state object मध्ये एकत्रित करता.
तुमच्या UI मध्ये तुम्हाला एक Address विभाग दिसतो. तुम्ही तुमच्या state मध्ये एक address object तयार करता. ते व्यवस्थित आणि सुटसुटीत दिसते.
हा एक सापळा आहे.
समस्या React मध्ये नाहीये. समस्या तुमच्या state च्या आकारात (shape) आहे.
फॉर्म्स हे स्थिर (static) डेटा नसतात. ते परस्परसंवादी (interactive) प्रणाली आहेत. वापरकर्ते फॉर्म विभागानुसार (section by section) अपडेट करत नाहीत, तर ते फील्डनुसार (field by field) अपडेट करतात.
नेस्टेड स्टेट (nested state) तुमच्या प्रोजेक्टला का नुकसान पोहोचवते:
- अपडेट्स जड होतात. इम्युटेबिलिटी (immutability) राखण्यासाठी, एका शहराचे नाव बदलण्यासाठी तुम्हाला शहर, पत्ता आणि टॉप-लेव्हल फॉर्म ऑब्जेक्ट पुन्हा तयार करावा लागतो.
- गुंतागुंत वाढते. जसा फॉर्म मोठा होतो, तसे तुमचे validation आणि rendering लॉजिक हाताळणे कठीण होते.
- री-रेंडर्स (Re-renders) वाढतात. एक नेस्टेड व्हॅल्यू बदलल्यामुळे नवीन object references तयार होतात. यामुळे तुमच्या संपूर्ण component tree मध्ये अनावश्यक अपडेट्स ट्रिगर होऊ शकतात.
- मानसिक ताण वाढतो. तुम्ही वापरकर्त्याचा विचार करणे थांबवता आणि object paths चा विचार करू लागता.
लहान फॉर्म्समध्ये चालून जाते. पण प्रॉडक्ट फॉर्म्समध्ये तसे नसते.
प्रोडक्शन फॉर्मला validation, autosave आणि conditional logic ची आवश्यकता असते. जर तुम्ही हे सर्व एका खोलवर नेस्ट केलेल्या (deeply nested) ऑब्जेक्टवर आधारित बनवले, तर प्रत्येक नवीन फीचर विकसित करणे कठीण आणि खर्चिक वाटते.
उपाय म्हणजे डेटा कसा दिसतो यावर नाही, तर डेटा कसा बदलतो यावर आधारित state डिझाइन करणे.
फ्लॅट (flatter) स्टेट शेपचे हे फायदे आहेत:
- जलद अपडेट्स. एक व्हॅल्यू बदलण्यासाठी तुम्हाला कमी कोड लिहावा लागतो.
- सोपे डीबगिंग (debugging). अपडेट्स स्थानिक (local) आणि अंदाजित (predictable) राहतात.
- चांगले कंपोनंट बाउंड्रीज (component boundaries). तुम्ही मोठ्या ऑब्जेक्ट्सऐवजी डेटाचे लहान भाग पास करू शकता.
अंधाधुंदपणे सर्व काही फ्लॅट करू नका. जर डेटा क्वचितच बदलत असेल आणि नेहमी एकत्रच हलत असेल, तर नेस्टिंग ठीक आहे. परंतु, तुमच्या फॉर्मचे जे भाग सतत बदलतात, त्यांना नेस्ट करू नका.
कोड करण्यापूर्वी स्वतःला हे प्रश्न विचारा:
- कोणते फील्ड्स सर्वात जास्त वेळा बदलतात?
- कोणत्या विभागांना स्वतंत्र validation ची आवश्यकता आहे?
- कोणते अपडेट्स उर्वरित UI पासून वेगळे (isolated) ठेवणे आवश्यक आहे?
जर एक फील्ड अपडेट करणे हे त्या बदलापेक्षा कठीण वाटत असेल, तर तुमच्या state स्ट्रक्चरमध्ये समस्या आहे.
तुमच्या state ला UI प्रमाणे मॉडेल करणे थांबवा. त्याऐवजी वापरकर्त्याच्या वर्तनानुसार (user's behavior) मॉडेल करायला सुरुवात करा.