𝗗𝗼𝗻’𝘁 𝗠𝗶𝘀𝘁𝗮𝗸𝗲 𝗗𝗮𝘁𝗮 𝗦𝗵𝗮𝗽𝗲 𝗳𝗼𝗿 𝗦𝘁𝗮𝘁𝗲 𝗦𝗵𝗮𝗽𝗲
Unapounda fomu ya React, mara nyingi unakusanya kila kitu kwenye object moja kubwa ya state.
Unaona sehemu ya Anwani (Address) kwenye UI yako. Unatengeneza object ya anwani kwenye state yako. Inaonekana imepangwa vizuri. Inaonekana safi.
Hii ni mtego.
Tatizo si React. Tatizo ni muundo (shape) wa state yako.
Fomu si data tuli (static). Ni mifumo inayofanya kazi (interactive). Watumiaji hawajazi fomu sehemu kwa sehemu. Wanajaza kila sehemu (field) moja baada ya nyingine.
Kwa nini nested state inadhuru mradi wako:
- Updates zinakuwa nzito. Ili kubadilisha jina la mji mmoja, lazima utengeneze upya mji, anwani, na object ya juu kabisa ya fomu ili kudumisha immutability.
- Ugumu unavuja. Kadiri fomu inavyokua, mantiki yako ya uhakiki (validation) na uwasilishaji (rendering) inakuwa ngumu zaidi kudhibiti.
- Re-renders zinaongezeka. Kubadilisha thamani moja iliyojificha ndani (nested value) kunatengeneza marejeo mapya ya object. Hii inaweza kusababisha updates zisizo za lazima kwenye mti wako mzima wa component.
- Mzigo wa kiakili unaongezeka. Unaacha kuwaza kuhusu mtumiaji na kuanza kuwaza kuhusu njia za object (object paths).
Fomu ndogo hazina shida sana. Fomu za bidhaa (product forms) zina shida.
Fomu ya uzalishaji (production form) inahitaji uhakiki (validation), uhifadhi wa kiotomatiki (autosave), na mantiki ya masharti (conditional logic). Ukijenga hizi juu ya object iliyojificha ndani sana, kila kipengele kipya kitaonekana kuwa na gharama kubwa.
Suluhisho ni kubuni state kulingana na jinsi data inavyobadilika, si jinsi inavyoonekana.
Muundo wa state ulio tambarare (flatter state shape) unatoa faida hizi:
- Updates za haraka zaidi. Unagusa kodi kidogo zaidi ili kubadilisha thamani moja.
- Debugging rahisi zaidi. Updates zinabaki mahali pamoja na zinatabirika.
- Mipaka bora ya component. Unaweza kupitisha vipande vidogo vya data badala ya object kubwa.
Usitambarishe (flatten) kila kitu bila mpangilio. Ikiwa data haibadiliki mara kwa mara na kila wakati inasogea pamoja, nesting ni sawa. Lakini usijifiche ndani (nest) kwa sehemu za fomu yako zinazobadilika kila wakati.
Jiulize maswali haya kabla ya kuandika kodi:
- Ni sehemu (fields) zipi zinazobadilika mara nyingi zaidi?
- Ni sehemu zipi zinahitaji uhakiki (validation) wa pekee?
- Ni updates zipi zinapaswa kubaki zimetengwa na sehemu nyingine za UI?
Ikiwa kubadilisha sehemu moja kunahisi kuwa vigumu kuliko mabadiliko yenyewe, muundo wa state yako ndio tatizo.
Acha kuunda state yako kulingana na UI yako. Anza kuunda kulingana na tabia ya mtumiaji wako.