ഓരോ React ഡെവലപ്പറും ഒടുവിൽ ഒരേ ചോദ്യം നേരിടാറുണ്ട്: ഞാൻ Context ഉപയോഗിക്കണോ, അതോ ഇത് Redux ഉപയോഗിക്കേണ്ട പ്രശ്നമാണോ? നിങ്ങൾ ഏതാനും മാസങ്ങൾ മാത്രമാണ് ഡെവലപ്മെന്റ് മേഖലയിൽ ഉള്ളതെങ്കിൽ, ഇന്റർനെറ്റിലെ ചർച്ചകൾ ഇത് രണ്ടും തമ്മിലുള്ള ഒരു തിരഞ്ഞെടുപ്പ് മാത്രമാണെന്ന് തോന്നിപ്പിക്കുന്നു. ചില ട്യൂട്ടോറിയലുകൾ Redux-നെ കാലഹരണപ്പെട്ട ഒന്നായി കാണുന്നു. മറ്റുള്ളവർ Context ഉപയോഗിച്ചാൽ ഒരു to-do ലിസ്റ്റിന് അപ്പുറം കാര്യങ്ങൾ ചെയ്യാൻ കഴിയില്ലെന്ന് മുന്നറിയിപ്പ് നൽകുന്നു. ഈ രണ്ട് തീവ്രമായ അഭിപ്രായങ്ങളും ഉപകാരപ്രദമല്ല. സത്യമെന്തെന്നാൽ, ഈ ടൂളുകൾ വ്യത്യസ്ത തരത്തിലുള്ള പ്രശ്നങ്ങളാണ് പരിഹരിക്കുന്നത്, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നത് എന്നതിനെ ആശ്രയിച്ചിരിക്കും ശരിയായ തിരഞ്ഞെടുപ്പ്.
The Prop Drilling Problem
ഒരു state management രീതി തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ്, ഈ രണ്ട് ടൂളുകളും പരിഹരിക്കാൻ ശ്രമിക്കുന്ന പ്രശ്നം എന്താണെന്ന് മനസ്സിലാക്കുന്നത് നന്നായിരിക്കും. നിങ്ങൾ ഒരു e-commerce സൈറ്റ് നിർമ്മിക്കുകയാണെന്ന് സങ്കൽപ്പിക്കുക. നിങ്ങൾ ഉപയോക്താവിന്റെ പ്രൊഫൈൽ വിവരങ്ങൾ ഏറ്റവും മുകളിലുള്ള App കോംപോണന്റിൽ നിന്ന് ഫെച്ച് ചെയ്യുന്നു. എന്നാൽ താഴെയുള്ള ഫൂട്ടറിലുള്ള ഒരു ചെറിയ AccountLink കോംപോണന്റിന് ആ പ്രൊഫൈൽ ചിത്രം ആവശ്യമാണ്. ഒരു ഗ്ലോബൽ സ്റ്റോർ ഇല്ലാതെയാണെങ്കിൽ, ആ user ഒബ്ജക്റ്റ് Home, തുടർന്ന് Header, പിന്നെ NavContainer, ശേഷം UserDropdown എന്നിവയിലൂടെ കടന്നുപോയി ഒടുവിൽ AccountLink-ൽ എത്തേണ്ടി വരുന്നു. ഇടയിലുള്ള ഓരോ ലെയറും തങ്ങൾക്ക് ആവശ്യമില്ലാത്ത ഡാറ്റ കൈകാര്യം ചെയ്യേണ്ടി വരുന്നു. ഇതിനെയാണ് prop drilling എന്ന് പറയുന്നത്.
Prop drilling കോംപോണന്റുകളെ ദുർബലമാക്കുന്നു. ഒരു ഇടനിലക്കാരനെ മാറ്റിയാൽ തന്നെ ആ ഡാറ്റാ ശൃംഖല തകരാറിലാകുമെന്നതിനാൽ refactoring ചെയ്യുന്നത് അപകടകരമായി മാറുന്നു. കോംപോണന്റുകൾ തങ്ങൾക്ക് ആവശ്യമില്ലാത്ത പ്രോപ്പുകൾ താഴേക്ക് കൈമാറേണ്ടി വരുന്നതിനാൽ അവയുടെ reusability കുറയുന്നു. Context-ഉം Redux-ഉം ദൂരെയുള്ള കോംപോണന്റുകളെ നേരിട്ട് ഡാറ്റ ഉപയോഗിക്കാൻ അനുവദിക്കുന്നതിലൂടെ ഇത് ഒഴിവാക്കുന്നു. എന്നാൽ അവ ഡാറ്റ എത്തിക്കുന്ന രീതിയിലും അതിനുള്ള ചിലവിലും വലിയ വ്യത്യാസമുണ്ട്.
When React Context API Is the Right Fit
React Context ലൈബ്രറിയിൽ തന്നെ ഉൾപ്പെടുത്തിയിട്ടുള്ളതാണ്. അധികമായി npm ഇൻസ്റ്റാളേഷനുകളോ, ബിൽഡ് കോൺഫിഗറേഷനോ, ബോയിലർപ്ലേറ്റ് ഫയലുകളോ ആവശ്യമില്ല. നിങ്ങൾ ഒരു context ഒബ്ജക്റ്റ് നിർമ്മിക്കുന്നു, നിങ്ങളുടെ ട്രീയുടെ ഒരു ഭാഗം ഒരു Provider കൊണ്ട് പൊതിയുന്നു, തുടർന്ന് ഏതെങ്കിലും ഒരു നെസ്റ്റഡ് കോംപോണന്റിൽ useContext ഉപയോഗിച്ച് ആ മൂല്യം ഉപയോഗിക്കുന്നു. ഈ ലാളിത്യം കാരണം, സ്റ്റേറ്റ് മാറ്റങ്ങൾ അപൂർവ്വമായി മാത്രം സംഭവിക്കുന്നതും സ്റ്റേറ്റിന്റെ ഘടന ലളിതവുമായ ചെറിയതോ ഇടത്തരംതോ ആയ പ്രോജക്റ്റുകളിൽ Context മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു.
UI തീമുകളെക്കുറിച്ച് ചിന്തിക്കുക. ഒരു ഉപയോക്താവ് ഒരു സെഷനിൽ ഒരുപക്ഷേ ഒരു തവണയായിരിക്കും light mode-ൽ നിന്നും dark mode-ലേക്ക് മാറുന്നത്. ആ മൂല്യം എല്ലാ styled കോംപോണന്റുകളിലേക്കും എത്തുന്നുണ്ടെങ്കിലും, അത് വളരെ അപൂർവ്വമായി മാത്രം മാറുന്നതിനാൽ പെർഫോമൻസ് പ്രശ്നങ്ങൾ ഉണ്ടാകില്ല. Authentication സ്റ്റാറ്റസ് മറ്റൊരു ഉദാഹരണമാണ്. ഒരു ഉപയോക്താവ് ലോഗിൻ ചെയ്തുകഴിഞ്ഞാൽ, isAuthenticated ഫ്ലാഗും user ഒബ്ജക്റ്റും ഡസൻ കണക്കിന് പേജ് നാവിഗേഷനുകളിലും സ്ഥിരമായിരിക്കും. ഭാഷാ ക്രമീകരണങ്ങളും (Language or localization settings) ഇതേപോലെയാണ് പ്രവർത്തിക്കുന്നത്. ഇവ പല കോംപോണന്റുകൾക്കും ആവശ്യമായതും എന്നാൽ വളരെ കുറച്ചു കോംപോണന്റുകൾ മാത്രം മാറ്റം വരുത്തുന്നതുമായ സിഗ്നലുകളാണ്.
എന്നാൽ Context അപ്ഡേറ്റുകൾ കൈകാര്യം ചെയ്യുന്ന രീതിയിൽ ഒരു പ്രശ്നമുണ്ട്. ഒരു Context Provider-ന്റെ മൂല്യം മാറുമ്പോൾ, ആ കോൺടെക്സ്റ്റ് ഉപയോഗിക്കുന്ന എല്ലാ കോംപോണന്റുകളും React വീണ്ടും റെൻഡർ ചെയ്യുന്നു. ഒരു ചെറിയ ആപ്ലിക്കേഷനിൽ ഇത് വലിയ പ്രശ്നമാകില്ല. എന്നാൽ വലിയൊരു ആപ്ലിക്കേഷനിൽ, വേഗത്തിൽ മാറിക്കൊണ്ടിരിക്കുന്ന ഡാറ്റ ഒരു വ്യാപകമായി ഉപയോഗിക്കുന്ന Context-ൽ നൽകിയാൽ, അത് അനാവശ്യമായ റെൻഡറുകളുടെ ഒരു പരമ്പരയ്ക്ക് കാരണമാകും. മാറ്റങ്ങൾ കുറഞ്ഞ ഡാറ്റകൾക്കായി കോൺടെക്സ്റ്റുകൾ വേർതിരിക്കാൻ സാധിക്കുമെങ്കിലും, ആ ഘട്ടത്തിൽ നിങ്ങൾ മറ്റൊരു ടൂൾ എളുപ്പത്തിൽ പരിഹരിക്കുന്ന കാര്യങ്ങൾ മാനുവലായി ഒപ്റ്റിമൈസ് ചെയ്യാൻ ശ്രമിക്കുകയാണ് ചെയ്യുന്നത്.
When Redux Toolkit Earns Its Place
സങ്കീർണ്ണമായ സ്റ്റേറ്റും, ഇടയ്ക്കിടെയുള്ള അപ്ഡേറ്റുകളും, ഒരേ ഡാറ്റ തന്നെ പല ദൂരസ്ഥലങ്ങളിൽ നിന്ന് ഒരേസമയം വായിക്കാനും എഴുതാനും ആവശ്യമായ ആപ്ലിക്കേഷനുകൾക്കായിട്ടാണ് Redux Toolkit രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഒരു ഷോപ്പിംഗ് കാർട്ട് സങ്കൽപ്പിക്കുക. ഉപയോക്താവ് ഒരു പ്രൊഡക്റ്റ് കാർഡിൽ നിന്ന് ഒരു ഐറ്റം ചേർക്കുന്നു. ഹെഡറിലുള്ള കാർട്ട് ഐക്കൺ അതിന്റെ ബഡ്ജ് കൗണ്ട് അപ്ഡേറ്റ് ചെയ്യണം. ഐറ്റംസ് കാണിക്കാൻ ഒരു സൈഡ്ബാർ വരുന്നു. ഒരു ഡിസ്കൗണ്ട് കോഡ് ഇൻപുട്ട് വാലിഡേഷൻ നടത്തുന്നു. പിന്നീട് ചെക്ക്ഔട്ട് പേജ് കാർട്ടിലെ വിവരങ്ങൾ വായിക്കുന്നു. ഈ സ്റ്റേറ്റ് ട്രീയിലുടനീളമുള്ള ബന്ധമില്ലാത്ത കോംപോണന്റുകൾ ഉപയോഗിക്കുന്നുണ്ടാവുകയും അത് പലപ്പോഴും മാറിക്കൊണ്ടിരിക്കുകയും ചെയ്യുന്നു.
ഒരു സെൻട്രലൈസ്ഡ് സ്റ്റോറിലൂടെയും സ്റ്റേറ്റിന്റെ വ്യക്തമായ സ്ലൈസുകളിലൂടെയും (slices) Redux Toolkit ഇത് പരിഹരിക്കുന്നു. കോംപോണന്റുകൾക്ക് ആവശ്യമുള്ള ഡാറ്റയുടെ ചെറിയ ഭാഗങ്ങൾ മാത്രം useSelector ഉപയോഗിച്ച് തിരഞ്ഞെടുക്കാം. ഒരു റിയൽ ടൈം ഡാഷ്ബോർഡിൽ സ്റ്റോക്ക് വില മാറുന്നുണ്ടെങ്കിൽ, യൂസർ പ്രൊഫൈൽ സെറ്റിംഗ്സ് കാണിക്കുന്ന കോംപോണന്റ് റെൻഡർ ആകേണ്ടതില്ല. സബ്സ്ക്രിപ്ഷനുകൾ കൃത്യമായിരിക്കാൻ Redux അതിന്റെ ഉള്ളിൽ reference equality ചെക്കുകൾ ഉപയോഗിക്കുന്നു. കോംപോണന്റുകളുടെ എണ്ണം നൂറുകണക്കിന് ആയി ഉയരുമ്പോൾ ഇത് വളരെ പ്രധാനമാണ്.
Redux നിങ്ങൾക്ക് പ്രവചിക്കാവുന്ന (predictable) ഒരു ഡാറ്റാ ഫ്ലോ നൽകുന്നു. റെഡ്യൂസറുകൾ (reducers) കൈകാര്യം ചെയ്യുന്ന ഡിസ്പാച്ച് ചെയ്ത ആക്ഷനുകളിലൂടെയാണ് (dispatched actions) സ്റ്റേറ്റ് മാറ്റങ്ങൾ സംഭവിക്കുന്നത്. ഇത് കേൾക്കുമ്പോൾ സാങ്കേതിക പദമായി തോന്നാമെങ്കിലും, പ്രായോഗികമായി പറഞ്ഞാൽ നിങ്ങളുടെ കോഡ്ബേസിൽ addToCart എന്ന് സെർച്ച് ചെയ്താൽ കാർട്ട് മാറ്റം വരുത്തുന്ന എല്ലാ കോഡ് പാത്തുകളും നിങ്ങൾക്ക് കണ്ടെത്താൻ കഴിയും. ഒരു വലിയ ടീമിനെ സംബന്ധിച്ചിടത്തോളം, ഈ രീതി ബഗുകൾ ഒഴിവാക്കാൻ സഹായിക്കുന്നു. നേരെമറിച്ച്, Context എന്നത് വെറുമൊരു മൂല്യവും (value) ഒരു സെറ്ററും (setter) മാത്രമാണ്. ഏതൊരു കോംപോണന്റിനും setState വിളിക്കാം, അതിനാൽ ഒരു തെറ്റായ മൂല്യത്തിന്റെ ഉറവിടം കണ്ടെത്തുക എന്നത് പല കോംപോണന്റുകളിലായി ബ്രേക്ക് പോയിന്റുകൾ വെച്ച് പരിശോധിക്കേണ്ടി വരുന്ന പ്രയാസകരമായ ജോലിയാണ്.
Where They Really Diverge
പ്രകടന സവിശേഷതകൾ (Performance characteristics) മറ്റെന്തിനേക്കാളും ഈ ടൂളുകളെ വേർതിരിക്കുന്നത് ഇവയാണ്. Context എല്ലാ ഉപഭോക്താക്കൾക്കും (consumers) പുതിയ മൂല്യം നിബന്ധനകളില്ലാതെ നൽകുന്നു. എന്നാൽ തിരഞ്ഞെടുത്ത സ്ലൈസ് (slice) മാറിയ സബ്സ്ക്രൈബർമാരെ മാത്രമേ Redux അറിയിക്കുന്നുള്ളൂ. ഓരോ സെക്കൻഡിലും ക്വോട്ടുകൾ പുതുക്കപ്പെടുന്ന ഒരു റിയൽ-ടൈം സ്റ്റോക്ക് ഡാഷ്ബോർഡ് നിർമ്മിക്കുകയാണെങ്കിൽ, Context ഒരു ഗ്ലോബൽ റീ-റെൻഡർ (global re-render) തിരമാലയ്ക്ക് കാരണമാകും. എന്നാൽ Redux ഉപയോഗിക്കുമ്പോൾ ടിക്കർ സെല്ലും (ticker cell) സ്പാർക്ക്ലൈൻ ചാർട്ടും (sparkline chart) മാത്രം വീണ്ടും കണക്കുകൂട്ടാൻ (recompute) സാധിക്കും.
സങ്കീർണ്ണമായ ആപ്പുകളിൽ Redux മുന്നിട്ടുനിൽക്കുന്ന മറ്റൊരു മേഖലയാണ് ഡീബഗ്ഗിംഗ് (Debugging). Redux DevTools നിങ്ങൾക്ക് 'ടൈം-ട്രാവൽ ഡീബഗ്ഗിംഗ്' (time-travel debugging) നൽകുന്നു. ഓരോ ഡിസ്പാച്ച് ചെയ്ത ആക്ഷനിലൂടെയും (dispatched action) പിന്നോട്ട് സഞ്ചരിക്കാനും സ്റ്റേറ്റ് (state) പഴയപടിയാകുന്നത് കാണാനും നിങ്ങൾക്ക് കഴിയും. ഷിപ്പിംഗ് കണക്കുകൂട്ടലുകൾ, പേയ്മെന്റ് വാലിഡേഷൻ, എറർ റിക്കവറി എന്നിവയുള്ള ഒരു മൾട്ടി-സ്റ്റെപ്പ് ചെക്ക്ഔട്ട് ഫ്ലോയിൽ, ഒരു ബഗ്ഗിലേക്ക് നയിച്ച കൃത്യമായ ക്രമം വീണ്ടും പ്ലേ ചെയ്യാൻ കഴിയുന്നത് വളരെ വിലപ്പെട്ടതാണ്. Context സാധാരണ React DevTools-നെയാണ് ആശ്രയിക്കുന്നത്. നിങ്ങൾക്ക് നിലവിലെ കോൺടെക്സ്റ്റ് മൂല്യങ്ങൾ പരിശോധിക്കാം, പക്ഷേ ഇതിൽ ഇൻബിൽറ്റ് ആക്ഷൻ ലോഗോ (action log) അല്ലെങ്കിൽ സ്റ്റേറ്റ് ഡിഫ് വ്യൂവറോ (state diff viewer) ഇല്ല. നിങ്ങൾ വീണ്ടും കൺസോൾ ലോഗുകൾ (console logs) ഉപയോഗിക്കേണ്ടി വരും.
മിഡിൽവെയറുകളും സൈഡ് ഇഫക്റ്റുകളും (Middleware and side effects) Redux-ന്റെ അടിസ്ഥാന ഭാഗമാണ്. Redux Toolkit-ൽ createAsyncThunk ഉൾപ്പെടുന്നു, കൂടാതെ ഇത് ഡാറ്റാ ഫെച്ചിംഗ് ലൈബ്രറികളുമായി (data-fetching libraries) സുഗമമായി സംയോജിക്കുന്നു. ഒരു API കോൾ ക്രമീകരിക്കാനും, ലോഡിംഗ് സ്പിന്നർ കാണിക്കാനും, നെറ്റ്വർക്ക് പരാജയം കൈകാര്യം ചെയ്യാനും, ഫലം കാഷെ (cache) ചെയ്യാനും Redux ഡാറ്റാ ഫ്ലോയ്ക്കുള്ളിൽ തന്നെ സാധിക്കും. അസിൻക്രണസ് ലോജിക്കിനായി (asynchronous logic) Context-ൽ ഇൻബിൽറ്റ് പാറ്റേണുകൾ ഇല്ല. ഒന്നുകിൽ നിങ്ങൾ കംപോണന്റുകൾക്കുള്ളിൽ ഡാറ്റ ഫെച്ച് ചെയ്ത് ഫലം Context-ലേക്ക് നൽകണം, അല്ലെങ്കിൽ സ്വന്തമായി നിർമ്മിച്ച അസിങ്ക് യൂട്ടിലിറ്റികൾ ഉപയോഗിച്ച് പ്രൊവൈഡറുകളെ (providers) പൊതിയണം. ഇത് പ്രവർത്തിക്കും, പക്ഷേ ഇത് താൽക്കാലികമായ ഒരു രീതിയാണ് (ad hoc).
സെറ്റപ്പ് ചിലവ് (Setup cost) എന്ന കാര്യത്തിൽ Context വ്യക്തമായി വിജയിക്കുന്നു. ഒരു തീം പ്രൊവൈഡർ (theme provider) നിർമ്മിക്കാൻ ഏകദേശം അഞ്ച് മിനിറ്റ് മതിയാകും. Redux Toolkit ഉപയോഗിക്കാൻ ഒരു സ്റ്റോർ ഫയൽ നിർമ്മിക്കാനും, സ്ലൈസുകൾ (slices) നിർവചിക്കാനും, നിങ്ങളുടെ ആപ്ലിക്കേഷനെ ഒരു Provider-ൽ പൊതിയേണ്ടതുമുണ്ട്. പഴയ Redux-ലെപ്പോലെ വലിയ അളവിൽ ബോയ്ലർപ്ലേറ്റ് (boilerplate) കോഡുകൾ എഴുതി ഒരാഴ്ചയോളം എടുക്കുന്ന പ്രക്രിയയല്ല ഇത്, എങ്കിലും Context-നെ അപേക്ഷിച്ച് ഇതിന് കൂടുതൽ സെറ്റപ്പ് ആവശ്യമാണ്. ഒരു വീക്കെൻഡ് സൈഡ് പ്രോജക്റ്റിനോ മൂന്ന് റൂട്ടുകളുള്ള ഒരു ഡാഷ്ബോർഡിനോ ഈ അധിക ജോലി ആവശ്യമില്ലായിരിക്കാം.
ഒരേ ആപ്ലിക്കേഷനിൽ രണ്ടും ഉപയോഗിക്കുമ്പോൾ
നിങ്ങൾ ഏതെങ്കിലും ഒരു വിഭാഗത്തോടു മാത്രം കൂറ് കാണിക്കേണ്ടതില്ല. ഒട്ടനവധി പ്രൊഡക്ഷൻ ആപ്ലിക്കേഷനുകൾ ഗ്ലോബൽ UI ഷെൽ കാര്യങ്ങൾക്കായി Context-ഉം, ഡൊമെയ്ൻ അധിഷ്ഠിത ബിസിനസ് ഡാറ്റയ്ക്കായി Redux-ഉം ഉപയോഗിക്കുന്നു. തീം, ലോക്കൽ (locale), ഒരു ലഘുവായ ഓത്ത് ഫ്ലാഗ് (auth flag) എന്നിവ Context-ൽ സൂക്ഷിക്കുക എന്നത് ഒരു സാധാരണ രീതിയാണ്, കാരണം എല്ലാ റൂട്ടുകൾക്കും ഇവ ആവശ്യമാണ് കൂടാതെ ഇവ അപൂർവ്വമായി മാത്രമേ മാറുന്നുള്ളൂ. അതേസമയം, ഓർഡർ മാനേജ്മെന്റ് സിസ്റ്റം, നോട്ടിഫിക്കേഷൻ സെന്റർ, ഡാറ്റാ ടേബിളുകൾ എന്നിവ Redux-ൽ സൂക്ഷിക്കുന്നു; കാരണം ഇവയിൽ നിരന്തരമായ അപ്ഡേറ്റുകളും കംപോണന്റുകൾക്കിടയിലുള്ള ലോജിക്കും കൃത്യമായ നിയന്ത്രണം ആവശ്യപ്പെടുന്നു.
ഈ ഹൈബ്രിഡ് സമീപനം, ഒരു സ്റ്റാറ്റിക് തീം ഒബ്ജക്റ്റിന് ചുറ്റും മുഴുവൻ Redux സ്റ്റോറും നിർബന്ധിക്കാതെ തന്നെ ലളിതമായ കാര്യങ്ങൾ ലളിതമായി നിലനിർത്തുന്നു. കൂടാതെ, വ്യവസായ നിലവാരത്തിലുള്ള സ്റ്റേറ്റ് മാനേജ്മെന്റ് ആവശ്യമില്ലാത്ത UI ഘടകങ്ങൾ കൊണ്ട് നിങ്ങളുടെ Redux സ്ലൈസുകൾ നിറയുന്നത് ഇത് തടയുന്നു.
യഥാർത്ഥ പാഠം
കൂടുതൽ സങ്കീർണ്ണമായ ടൂൾ തിരഞ്ഞെടുക്കുന്നത് ഒരു വലിയ നേട്ടമായി കാണേണ്ടതില്ല. നിങ്ങളുടെ സ്റ്റേറ്റ് എത്ര തവണ മാറുന്നു, എത്ര കംപോണന്റുകൾ അതിനെ ഉപയോഗിക്കുന്നു, ടീം അതിരുകൾക്കപ്പുറമുള്ള മാറ്റങ്ങൾ (mutations) ട്രാക്ക് ചെയ്യേണ്ടതുണ്ടോ എന്നിവ പരിശോധിച്ചുകൊണ്ട് തുടങ്ങുക. മിതമായ വലിപ്പമുള്ള ഒരു ആപ്പിൽ സാവധാനം മാറുന്നതും വ്യാപകമായി പങ്കിടപ്പെടുന്നതുമായ മൂല്യങ്ങളാണ് നിങ്ങൾ കൈകാര്യം ചെയ്യുന്നതെങ്കിൽ, Context മതിയെന്ന് പറയാം. നിങ്ങളുടെ സ്റ്റേറ്റ് നിരന്തരം മാറിക്കൊണ്ടിരിക്കുകയും, പരസ്പരബന്ധമില്ലാത്ത ഫീച്ചറുകളിൽ വ്യാപിച്ചുനിൽക്കുകയും, വ്യക്തമായ ഒരു ഓഡിറ്റ് ട്രയൽ (audit trail) ആവശ്യപ്പെടുകയും ചെയ്യുന്നുണ്ടെങ്കിൽ, Redux Toolkit ഉപയോഗിക്കുന്നത് നിങ്ങളുടെ ജോലി എളുപ്പമാക്കും.
കോൺഫറൻസ് സംസാരങ്ങളുടെയോ GitHub സ്റ്റാറുകളുടെയോ അടിസ്ഥാനത്തിലല്ല, മറിച്ച് നിങ്ങളുടെ പ്രോജക്റ്റിന്റെ സ്വഭാവമനുസരിച്ച് ടൂൾ തിരഞ്ഞെടുക്കുക. അൻപതോളം ഐറ്റങ്ങൾ ഉള്ള ഒരു ഷോപ്പിംഗ് കാർട്ടിന് അർത്ഥമാക്കുന്നത് Redux വേണമെന്നല്ല, അതുപോലെ ഒരു തീം ടോഗിളിന് ഒരു ഗ്ലോബൽ സ്റ്റോറും ആവശ്യമില്ല. പ്രശ്നത്തിനനുസരിച്ച് ടൂൾ തിരഞ്ഞെടുക്കുക, അങ്ങനെ നിങ്ങളുടെ കോഡ്ബേസ് (codebase) ദീർഘകാലം പരിപാലിക്കാൻ എളുപ്പമുള്ളതായിരിക്കും.