𝗗𝗼𝗻’𝘁 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 𝗗𝗮𝘁𝗮 𝗦𝗵𝗮𝗽𝗲 𝗳𝗼𝗿 𝗦𝘁𝗮𝘁𝗲 𝗦𝗵𝗮𝗽𝗲
നിങ്ങൾ ഒരു React ഫോം നിർമ്മിക്കുമ്പോൾ, പലപ്പോഴും എല്ലാ വിവരങ്ങളും ഒരൊറ്റ വലിയ സ്റ്റേറ്റ് ഒബ്ജക്റ്റിലേക്ക് (state object) ഗ്രൂപ്പ് ചെയ്യാറുണ്ട്.
നിങ്ങളുടെ UI-യിൽ ഒരു അഡ്രസ് (Address) വിഭാഗം കാണുന്നു എന്ന് കരുതുക. നിങ്ങൾ സ്റ്റേറ്റിൽ ഒരു അഡ്രസ് ഒബ്ജക്റ്റ് നിർമ്മിക്കുന്നു. അത് കാണാൻ വളരെ അടുക്കും ചിട്ടയുമുള്ളതും വൃത്തിയുള്ളതുമായി തോന്നും.
ഇതൊരു കെണിയാണ്.
പ്രശ്നം React അല്ല. പ്രശ്നം നിങ്ങളുടെ സ്റ്റേറ്റിന്റെ ഘടനയാണ് (shape).
ഫോമുകൾ എന്നത് നിശ്ചലമായ ഡാറ്റയല്ല (static data). അവ സംവേദനാത്മകമായ (interactive) സംവിധാനങ്ങളാണ്. ഉപയോക്താക്കൾ ഫോമുകൾ ഓരോ വിഭാഗമായിട്ടല്ല (section by section) അപ്ഡേറ്റ് ചെയ്യുന്നത്, മറിച്ച് ഓരോ ഫീൽഡുകളായിട്ടാണ് (field by field).
എന്തുകൊണ്ടാണ് നെസ്റ്റഡ് സ്റ്റേറ്റ് (nested state) നിങ്ങളുടെ പ്രോജക്റ്റിനെ ദോഷകരമായി ബാധിക്കുന്നത്:
- അപ്ഡേറ്റുകൾ ഭാരമേറിയതാകുന്നു. ഇമ്മ്യൂട്ടബിലിറ്റി (immutability) നിലനിർത്തുന്നതിനായി ഒരു സിറ്റിയുടെ പേര് മാറ്റണമെങ്കിൽ പോലും, നിങ്ങൾ ആ സിറ്റിയും, അഡ്രസ്സും, ടോപ്പ്-ലെവൽ ഫോം ഒബ്ജക്റ്റും വീണ്ടും നിർമ്മിക്കേണ്ടി വരും.
- സങ്കീർണ്ണത വർദ്ധിക്കുന്നു. ഫോം വലുതാകുന്തോറും, അതിന്റെ വാലിഡേഷൻ (validation), റെൻഡറിംഗ് ലോജിക് (rendering logic) എന്നിവ കൈകാര്യം ചെയ്യുന്നത് പ്രയാസകരമാകും.
- റീ-റെൻഡറുകൾ (Re-renders) കൂടുന്നു. ഒരു നെസ്റ്റഡ് വാല്യൂ മാറ്റുന്നത് പുതിയ ഒബ്ജക്റ്റ് റഫറൻസുകൾ സൃഷ്ടിക്കുന്നു. ഇത് നിങ്ങളുടെ കംപോണന്റ് ട്രീയിലുടനീളം അനാവശ്യമായ അപ്ഡേറ്റുകൾക്ക് കാരണമായേക്കാം.
- മാനസികമായ ജോലിഭാരം കൂടുന്നു. നിങ്ങൾ ഉപയോക്താവിനെക്കുറിച്ച് ചിന്തിക്കുന്നതിന് പകരം ഒബ്ജക്റ്റ് പാത്തുകളെക്കുറിച്ച് (object paths) ചിന്തിക്കാൻ തുടങ്ങുന്നു.
ചെറിയ ഫോമുകളിൽ ഇത്തരം പ്രശ്നങ്ങൾ വലിയ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കില്ല. എന്നാൽ പ്രൊഡക്ഷൻ ഫോമുകളിൽ (product forms) അത് അങ്ങനെയാകില്ല.
ഒരു പ്രൊഡക്ഷൻ ഫോമിന് വാലിഡേഷൻ, ഓട്ടോസേവ്, കണ്ടീഷണൽ ലോജിക് എന്നിവ ആവശ്യമാണ്. ഇവയെല്ലാം വളരെ ആഴത്തിലുള്ള (deeply nested) ഒരു ഒബ്ജക്റ്റിന് മുകളിൽ നിർമ്മിച്ചാൽ, ഓരോ പുതിയ ഫീച്ചറും വലിയ പ്രയാസകരമായ ജോലിയായി തോന്നും.
ഡാറ്റ എങ്ങനെ കാണപ്പെടുന്നു എന്നതിനെ അടിസ്ഥാനമാക്കിയല്ല, മറിച്ച് ഡാറ്റ എങ്ങനെ മാറുന്നു എന്നതിനെ അടിസ്ഥാനമാക്കി സ്റ്റേറ്റ് രൂപകൽപ്പന ചെയ്യുക എന്നതാണ് ഇതിനുള്ള പരിഹാരം.
ഫ്ലാറ്റ് ആയ (flatter) ഒരു സ്റ്റേറ്റ് ഘടന താഴെ പറയുന്ന ഗുണങ്ങൾ നൽകുന്നു:
- വേഗത്തിലുള്ള അപ്ഡേറ്റുകൾ. ഒരു മൂല്യം മാറ്റാൻ കുറഞ്ഞ കോഡ് മാത്രം മതിയാകും.
- എളുപ്പത്തിലുള്ള ഡീബഗ്ഗിംഗ് (debugging). അപ്ഡേറ്റുകൾ ലോക്കൽ ആയിരിക്കുകയും പ്രവചിക്കാവുന്നതാകുകയും ചെയ്യുന്നു.
- മികച്ച കംപോണന്റ് അതിരുകൾ (component boundaries). വലിയ ഒബ്ജക്റ്റുകൾക്ക് പകരം ഡാറ്റയുടെ ചെറിയ ഭാഗങ്ങൾ കൈമാറാൻ സാധിക്കും.
എല്ലാം അന്ധമായി ഫ്ലാറ്റ് ചെയ്യരുത്. ഡാറ്റ അപൂർവ്വമായി മാത്രം മാറുന്നതും എപ്പോഴും ഒന്നിച്ച് മാറുന്നതുമാണെങ്കിൽ നെസ്റ്റിംഗ് (nesting) കുഴപ്പമില്ല. എന്നാൽ നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്ന ഫോം ഭാഗങ്ങളെ നെസ്റ്റ് ചെയ്യാതിരിക്കുക.
കോഡ് ചെയ്യുന്നതിന് മുമ്പ് സ്വയം ഈ ചോദ്യങ്ങൾ ചോദിക്കുക:
- ഏതെല്ലാം ഫീൽഡുകളാണ് ഏറ്റവും കൂടുതൽ മാറുന്നത്?
- ഏതെല്ലാം വിഭാഗങ്ങൾക്കാണ് സ്വതന്ത്രമായ വാലിഡേഷൻ ആവശ്യമായിട്ടുള്ളത്?
- ഏതെല്ലാം അപ്ഡേറ്റുകളാണ് ബാക്കിയുള്ള UI-യിൽ നിന്ന് വേറിട്ട് നിൽക്കേണ്ടത്?
ഒരു ഫീൽഡ് അപ്ഡേറ്റ് ചെയ്യുന്നത് ആ മാറ്റത്തേക്കാൾ പ്രയാസകരമായി തോന്നുന്നുണ്ടെങ്കിൽ, നിങ്ങളുടെ സ്റ്റേറ്റ് ഘടനയാണ് പ്രശ്നം.
നിങ്ങളുടെ സ്റ്റേറ്റിനെ UI-ക്ക് അനുസരിച്ച് രൂപകൽപ്പന ചെയ്യുന്നത് നിർത്തുക. പകരം ഉപയോക്താവിന്റെ പെരുമാറ്റത്തിന് (user's behavior) അനുസരിച്ച് രൂപകൽപ്പന ചെയ്യാൻ തുടങ്ങുക.