റിയാക്റ്റിന്റെ `useSyncExternalStore` (മുൻപ് എക്സ്പെരിമെന്റൽ): ഗ്ലോബൽ ആപ്ലിക്കേഷനുകൾക്കായുള്ള എക്സ്റ്റേണൽ സ്റ്റോർ സിൻക്രൊണൈസേഷൻ മാസ്റ്റർ ചെയ്യാം

വെബ് ഡെവലപ്‌മെന്റിന്റെ ചലനാത്മകമായ ലോകത്ത്, സ്റ്റേറ്റ് ഫലപ്രദമായി കൈകാര്യം ചെയ്യേണ്ടത് അത്യാവശ്യമാണ്, പ്രത്യേകിച്ചും റിയാക്റ്റ് പോലുള്ള കമ്പോണന്റ്-ബേസ്ഡ് ആർക്കിടെക്ചറുകളിൽ. ഇന്റെർണൽ കമ്പോണന്റ് സ്റ്റേറ്റിനായി റിയാക്റ്റ് ശക്തമായ ടൂളുകൾ നൽകുമ്പോൾ തന്നെ, റിയാക്റ്റ് നേരിട്ട് നിയന്ത്രിക്കാത്ത എക്സ്റ്റേണൽ, മ്യൂട്ടബിൾ ഡാറ്റാ സോഴ്‌സുകളുമായി സംയോജിപ്പിക്കുന്നത് പലപ്പോഴും വെല്ലുവിളികൾ ഉയർത്തിയിരുന്നു. റെൻഡറിംഗ് തടസ്സപ്പെടുത്താനും പുനരാരംഭിക്കാനും അല്ലെങ്കിൽ സമാന്തരമായി നടപ്പിലാക്കാനും കഴിയുന്ന കോൺകറന്റ് മോഡിലേക്ക് റിയാക്റ്റ് മാറുമ്പോൾ ഈ വെല്ലുവിളികൾ കൂടുതൽ രൂക്ഷമാകുന്നു. ഇവിടെയാണ് `experimental_useSyncExternalStore` എന്ന ഹുക്ക്, ഇപ്പോൾ റിയാക്റ്റ് 18-ലും അതിനുശേഷമുള്ള പതിപ്പുകളിലും `useSyncExternalStore` എന്ന പേരിൽ അറിയപ്പെടുന്നത്, ശക്തവും സ്ഥിരതയുള്ളതുമായ സ്റ്റേറ്റ് സിൻക്രൊണൈസേഷന് ഒരു നിർണായക പരിഹാരമായി മാറുന്നത്.

ഈ സമഗ്രമായ ഗൈഡ് `useSyncExternalStore`-നെക്കുറിച്ച് ആഴത്തിൽ ചർച്ചചെയ്യുന്നു. അതിന്റെ ആവശ്യകത, പ്രവർത്തനരീതി, കൂടാതെ ലോകമെമ്പാടുമുള്ള ഡെവലപ്പർമാർക്ക് ഉയർന്ന പ്രകടനക്ഷമതയുള്ളതും 'ടിയറിംഗ്' ഇല്ലാത്തതുമായ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കാൻ ഇത് എങ്ങനെ ഉപയോഗിക്കാം എന്നും ഈ ഗൈഡ് പര്യവേക്ഷണം ചെയ്യുന്നു. നിങ്ങൾ ഒരു ലെഗസി കോഡ്, ഒരു തേർഡ്-പാർട്ടി ലൈബ്രറി, അല്ലെങ്കിൽ ഒരു കസ്റ്റം ഗ്ലോബൽ സ്റ്റോറുമായി സംയോജിപ്പിക്കുകയാണെങ്കിലും, നിങ്ങളുടെ റിയാക്റ്റ് പ്രോജക്റ്റുകളെ ഭാവിയിലേക്ക് സജ്ജമാക്കുന്നതിന് ഈ ഹുക്ക് മനസ്സിലാക്കേണ്ടത് അത്യാവശ്യമാണ്.

കോൺകറന്റ് റിയാക്റ്റിലെ എക്സ്റ്റേണൽ സ്റ്റേറ്റിന്റെ വെല്ലുവിളി: "ടിയറിംഗ്" തടയുന്നു

റിയാക്റ്റിന്റെ ഡിക്ലറേറ്റീവ് സ്വഭാവം അതിന്റെ ഇന്റെർണൽ സ്റ്റേറ്റിന് ഒരൊറ്റ ഉറവിടം (single source of truth) എന്ന ആശയത്തെ ആശ്രയിച്ചാണ് പ്രവർത്തിക്കുന്നത്. എന്നിരുന്നാലും, പല യഥാർത്ഥ ആപ്ലിക്കേഷനുകളും എക്സ്റ്റേണൽ സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് സിസ്റ്റങ്ങളുമായി സംവദിക്കുന്നു. ഇത് ഒരു ലളിതമായ ഗ്ലോബൽ ജാവാസ്ക്രിപ്റ്റ് ഒബ്ജക്റ്റ്, ഒരു കസ്റ്റം ഇവന്റ് എമിറ്റർ, localStorage അല്ലെങ്കിൽ matchMedia പോലുള്ള ബ്രൗസർ API-കൾ, അല്ലെങ്കിൽ തേർഡ്-പാർട്ടി ലൈബ്രറികൾ നൽകുന്ന സങ്കീർണ്ണമായ ഡാറ്റ ലെയറുകൾ (ഉദാഹരണത്തിന്, RxJS, MobX, അല്ലെങ്കിൽ പഴയ, ഹുക്ക് അടിസ്ഥാനമല്ലാത്ത Redux ഇന്റഗ്രേഷനുകൾ) വരെയാകാം.

റിയാക്റ്റുമായി എക്സ്റ്റേണൽ സ്റ്റേറ്റ് സിൻക്രൊണൈസ് ചെയ്യുന്നതിനുള്ള പരമ്പരാഗത രീതികളിൽ പലപ്പോഴും useState, useEffect എന്നിവയുടെ സംയോജനം ഉൾപ്പെടുന്നു. ഒരു useEffect ഹുക്കിൽ ഒരു എക്സ്റ്റേണൽ സ്റ്റോറിലേക്ക് സബ്‌സ്‌ക്രൈബുചെയ്യുക, എക്സ്റ്റേണൽ സ്റ്റോർ മാറുമ്പോൾ റിയാക്റ്റ് സ്റ്റേറ്റിന്റെ ഒരു ഭാഗം അപ്‌ഡേറ്റ് ചെയ്യുക, തുടർന്ന് ക്ലീനപ്പ് ഫംഗ്‌ഷനിൽ അൺസബ്‌സ്‌ക്രൈബ് ചെയ്യുക എന്നതാണ് ഒരു സാധാരണ പാറ്റേൺ. ഈ സമീപനം പല സാഹചര്യങ്ങളിലും പ്രവർത്തിക്കുമെങ്കിലും, കോൺകറന്റ് റെൻഡറിംഗ് എൻവയോൺമെന്റിൽ ഇത് സൂക്ഷ്മവും എന്നാൽ പ്രാധാന്യമർഹിക്കുന്നതുമായ ഒരു പ്രശ്നം സൃഷ്ടിക്കുന്നു: "ടിയറിംഗ്" (tearing).

"ടിയറിംഗ്" എന്ന പ്രശ്നം മനസ്സിലാക്കാം

ഒരൊറ്റ കോൺകറന്റ് റെൻഡർ പാസിനിടെ, നിങ്ങളുടെ യൂസർ ഇന്റർഫേസിന്റെ (UI) വിവിധ ഭാഗങ്ങൾ ഒരു മ്യൂട്ടബിൾ എക്സ്റ്റേണൽ സ്റ്റോറിൽ നിന്ന് വ്യത്യസ്ത മൂല്യങ്ങൾ വായിക്കുമ്പോഴാണ് ടിയറിംഗ് സംഭവിക്കുന്നത്. റിയാക്റ്റ് ഒരു കമ്പോണന്റ് റെൻഡർ ചെയ്യാൻ തുടങ്ങുകയും, ഒരു എക്സ്റ്റേണൽ സ്റ്റോറിൽ നിന്ന് ഒരു മൂല്യം വായിക്കുകയും, എന്നാൽ ആ റെൻഡർ പാസ് പൂർത്തിയാകുന്നതിന് മുമ്പ് എക്സ്റ്റേണൽ സ്റ്റോറിന്റെ മൂല്യം മാറുകയും ചെയ്യുന്ന ഒരു സാഹചര്യം സങ്കൽപ്പിക്കുക. അതേ പാസിൽ പിന്നീട് റെൻഡർ ചെയ്യുന്ന മറ്റൊരു കമ്പോണന്റ് (അല്ലെങ്കിൽ അതേ കമ്പോണന്റിന്റെ മറ്റൊരു ഭാഗം) പുതിയ മൂല്യം വായിച്ചാൽ, നിങ്ങളുടെ UI പൊരുത്തമില്ലാത്ത ഡാറ്റ പ്രദർശിപ്പിക്കും. ഇത് അക്ഷരാർത്ഥത്തിൽ എക്സ്റ്റേണൽ സ്റ്റോറിന്റെ രണ്ട് വ്യത്യസ്ത സ്റ്റേറ്റുകൾക്കിടയിൽ "കീറിപ്പോയത്" (torn) പോലെ കാണപ്പെടും.

ഒരു സിൻക്രണസ് റെൻഡറിംഗ് മോഡലിൽ, ഇത് ഒരു വലിയ പ്രശ്‌നമല്ല, കാരണം റെൻഡറുകൾ സാധാരണയായി അറ്റോമിക് ആണ്: മറ്റൊന്നും സംഭവിക്കുന്നതിന് മുമ്പ് അവ പൂർണ്ണമായി പ്രവർത്തിക്കുന്നു. എന്നാൽ അപ്‌ഡേറ്റുകളെ തടസ്സപ്പെടുത്തിയും മുൻഗണന നൽകിയും UI റെസ്പോൺസീവ് ആയി നിലനിർത്താൻ രൂപകൽപ്പന ചെയ്ത കോൺകറന്റ് റിയാക്റ്റ്, ടിയറിംഗ് ഒരു യഥാർത്ഥ ആശങ്കയാക്കുന്നു. ഒരു റെൻഡറിനായി ഒരു എക്സ്റ്റേണൽ സ്റ്റോറിൽ നിന്ന് വായിക്കാൻ തീരുമാനിച്ചാൽ, ആ റെൻഡറിനുള്ളിലെ തുടർന്നുള്ള എല്ലാ റീഡുകളും ഡാറ്റയുടെ ഒരേ പതിപ്പ് തന്നെ കാണുമെന്ന് ഉറപ്പുനൽകാൻ റിയാക്റ്റിന് ഒരു മാർഗ്ഗം ആവശ്യമാണ്, റെൻഡറിംഗിനിടെ എക്സ്റ്റേണൽ സ്റ്റോർ മാറിയാൽ പോലും.

ഈ വെല്ലുവിളി ആഗോളതലത്തിൽ വ്യാപിക്കുന്നു. നിങ്ങളുടെ ഡെവലപ്മെന്റ് ടീം എവിടെയാണെന്നോ നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ടാർഗെറ്റ് പ്രേക്ഷകർ ആരാണെന്നോ പരിഗണിക്കാതെ, UI സ്ഥിരത ഉറപ്പാക്കുകയും സ്റ്റേറ്റിലെ പൊരുത്തക്കേടുകൾ മൂലമുള്ള വിഷ്വൽ തകരാറുകൾ തടയുകയും ചെയ്യുന്നത് ഉയർന്ന നിലവാരമുള്ള സോഫ്റ്റ്‌വെയറിന് ഒരു സാർവത്രിക ആവശ്യകതയാണ്. പരസ്പരവിരുദ്ധമായ നമ്പറുകൾ കാണിക്കുന്ന ഒരു ഫിനാൻഷ്യൽ ഡാഷ്‌ബോർഡ്, സന്ദേശങ്ങൾ ക്രമം തെറ്റി കാണിക്കുന്ന ഒരു തത്സമയ ചാറ്റ് ആപ്ലിക്കേഷൻ, അല്ലെങ്കിൽ വിവിധ UI ഘടകങ്ങളിൽ പൊരുത്തമില്ലാത്ത ഇൻവെന്ററി കൗണ്ടുകളുള്ള ഒരു ഇ-കൊമേഴ്‌സ് പ്ലാറ്റ്‌ഫോം എന്നിവയെല്ലാം ടിയറിംഗിൽ നിന്ന് ഉണ്ടാകാവുന്ന ഗുരുതരമായ പരാജയങ്ങളുടെ ഉദാഹരണങ്ങളാണ്.

`useSyncExternalStore` അവതരിപ്പിക്കുന്നു: ഒരു സമർപ്പിത പരിഹാരം

കോൺകറന്റ് ലോകത്ത് എക്സ്റ്റേണൽ സ്റ്റേറ്റ് സിൻക്രൊണൈസേഷനായി നിലവിലുള്ള ഹുക്കുകളുടെ പരിമിതികൾ തിരിച്ചറിഞ്ഞ്, റിയാക്റ്റ് ടീം `useSyncExternalStore` അവതരിപ്പിച്ചു. തുടക്കത്തിൽ ഫീഡ്‌ബ্যাক ശേഖരിക്കുന്നതിനും മെച്ചപ്പെടുത്തലുകൾ വരുത്തുന്നതിനും `experimental_useSyncExternalStore` എന്ന പേരിൽ പുറത്തിറക്കിയ ഇത്, പിന്നീട് റിയാക്റ്റ് 18-ൽ ഒരു സ്ഥിരതയുള്ളതും അടിസ്ഥാനപരവുമായ ഹുക്കായി മാറി. ഇത് റിയാക്റ്റ് ഡെവലപ്‌മെന്റിന്റെ ഭാവിയിൽ അതിന്റെ പ്രാധാന്യം വ്യക്തമാക്കുന്നു.

`useSyncExternalStore` എന്നത് റിയാക്റ്റിന്റെ കോൺകറന്റ് റെൻഡററുമായി പൊരുത്തപ്പെടുന്ന രീതിയിൽ എക്സ്റ്റേണൽ, മ്യൂട്ടബിൾ ഡാറ്റാ സോഴ്‌സുകളിൽ നിന്ന് വായിക്കാനും സബ്‌സ്‌ക്രൈബുചെയ്യാനും വേണ്ടി രൂപകൽപ്പന ചെയ്ത ഒരു പ്രത്യേക റിയാക്റ്റ് ഹുക്കാണ്. ടിയറിംഗ് ഇല്ലാതാക്കുക എന്നതാണ് ഇതിന്റെ പ്രധാന ലക്ഷ്യം, നിങ്ങളുടെ റെൻഡറിംഗ് ശ്രേണി എത്ര സങ്കീർണ്ണമാണെങ്കിലും അല്ലെങ്കിൽ നിങ്ങളുടെ അപ്‌ഡേറ്റുകൾ എത്ര കോൺകറന്റ് ആണെങ്കിലും, നിങ്ങളുടെ റിയാക്റ്റ് കമ്പോണന്റുകൾ എല്ലായ്പ്പോഴും ഏത് എക്സ്റ്റേണൽ സ്റ്റോറിന്റെയും സ്ഥിരതയുള്ളതും ഏറ്റവും പുതിയതുമായ ഒരു കാഴ്ച പ്രദർശിപ്പിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക.

ഒരു റെൻഡർ പാസിനിടെ എക്സ്റ്റേണൽ സ്റ്റോറിൽ നിന്നുള്ള "റീഡ്" ഓപ്പറേഷന്റെ താൽക്കാലിക ഉടമസ്ഥാവകാശം ഏറ്റെടുക്കാൻ റിയാക്റ്റിനെ അനുവദിക്കുന്ന ഒരു പാലമായി ഇത് പ്രവർത്തിക്കുന്നു. റിയാക്റ്റ് ഒരു റെൻഡർ ആരംഭിക്കുമ്പോൾ, എക്സ്റ്റേണൽ സ്റ്റോറിന്റെ നിലവിലെ സ്നാപ്പ്ഷോട്ട് ലഭിക്കുന്നതിന് നൽകിയിട്ടുള്ള ഒരു ഫംഗ്ഷനെ അത് വിളിക്കും. റെൻഡർ പൂർത്തിയാകുന്നതിന് മുമ്പ് എക്സ്റ്റേണൽ സ്റ്റോർ മാറിയാലും, ആ നിർദ്ദിഷ്ട പാസിനുള്ളിൽ റെൻഡർ ചെയ്യുന്ന എല്ലാ കമ്പോണന്റുകളും ഡാറ്റയുടെ *യഥാർത്ഥ* സ്നാപ്പ്ഷോട്ട് തന്നെ കാണുന്നത് തുടരുന്നുവെന്ന് റിയാക്റ്റ് ഉറപ്പാക്കും, ഇത് ടിയറിംഗ് പ്രശ്നം ഫലപ്രദമായി തടയുന്നു. എക്സ്റ്റേണൽ സ്റ്റോർ മാറുകയാണെങ്കിൽ, ഏറ്റവും പുതിയ സ്റ്റേറ്റ് എടുക്കുന്നതിനായി റിയാക്റ്റ് ഒരു പുതിയ റെൻഡർ ഷെഡ്യൂൾ ചെയ്യും.

`useSyncExternalStore` എങ്ങനെ പ്രവർത്തിക്കുന്നു: പ്രധാന തത്വങ്ങൾ

`useSyncExternalStore` ഹുക്ക് മൂന്ന് നിർണായക ആർഗ്യുമെന്റുകൾ എടുക്കുന്നു, ഓരോന്നും അതിന്റെ സിൻക്രൊണൈസേഷൻ മെക്കാനിസത്തിൽ ഒരു പ്രത്യേക പങ്ക് വഹിക്കുന്നു:

1. subscribe (function): ഇതൊരു ഫംഗ്‌ഷനാണ്, അത് ഒരൊറ്റ ആർഗ്യുമെന്റായി callback എടുക്കുന്നു. നിങ്ങളുടെ എക്സ്റ്റേണൽ സ്റ്റോറിലെ മാറ്റങ്ങൾക്കായി റിയാക്റ്റിന് ശ്രദ്ധിക്കേണ്ടിവരുമ്പോൾ, അത് നിങ്ങളുടെ subscribe ഫംഗ്‌ഷനെ വിളിക്കുകയും ഒരു കോൾബാക്ക് പാസ് ചെയ്യുകയും ചെയ്യും. നിങ്ങളുടെ subscribe ഫംഗ്‌ഷൻ ഈ കോൾബാക്കിനെ നിങ്ങളുടെ എക്സ്റ്റേണൽ സ്റ്റോറിൽ രജിസ്റ്റർ ചെയ്യണം, അതുവഴി സ്റ്റോർ മാറുമ്പോഴെല്ലാം കോൾബാക്ക് വിളിക്കപ്പെടും. പ്രധാനമായും, നിങ്ങളുടെ subscribe ഫംഗ്‌ഷൻ ഒരു unsubscribe ഫംഗ്‌ഷൻ തിരികെ നൽകണം. റിയാക്റ്റിന് ഇനി ശ്രദ്ധിക്കേണ്ട ആവശ്യമില്ലാത്തപ്പോൾ (ഉദാഹരണത്തിന്, കമ്പോണന്റ് അൺമൗണ്ട് ചെയ്യുമ്പോൾ), സബ്‌സ്‌ക്രിപ്‌ഷൻ ക്ലീൻ അപ്പ് ചെയ്യുന്നതിനായി അത് ഈ അൺസബ്‌സ്‌ക്രൈബ് ഫംഗ്‌ഷനെ വിളിക്കും.
2. getSnapshot (function): നിങ്ങളുടെ എക്സ്റ്റേണൽ സ്റ്റോറിന്റെ നിലവിലെ മൂല്യം സിൻക്രണസായി തിരികെ നൽകുന്നതിനുള്ള ഉത്തരവാദിത്തം ഈ ഫംഗ്‌ഷനാണ്. റെൻഡറിംഗ് സമയത്ത് പ്രദർശിപ്പിക്കേണ്ട നിലവിലെ സ്റ്റേറ്റ് ലഭിക്കുന്നതിന് റിയാക്റ്റ് getSnapshot-നെ വിളിക്കും. ഈ ഫംഗ്‌ഷൻ സ്റ്റോറിന്റെ സ്റ്റേറ്റിന്റെ ഒരു ഇമ്മ്യൂട്ടബിൾ സ്നാപ്പ്ഷോട്ട് തിരികെ നൽകേണ്ടത് അത്യാവശ്യമാണ്. റെൻഡറുകൾക്കിടയിൽ തിരികെ ലഭിക്കുന്ന മൂല്യം മാറുകയാണെങ്കിൽ (സ്ട്രിക്റ്റ് ഇക്വാളിറ്റി കംപാരിസൺ === വഴി), റിയാക്റ്റ് കമ്പോണന്റിനെ വീണ്ടും റെൻഡർ ചെയ്യും. getSnapshot ഒരേ മൂല്യം തിരികെ നൽകുകയാണെങ്കിൽ, റിയാക്റ്റിന് റീ-റെൻഡറുകൾ ഒപ്റ്റിമൈസ് ചെയ്യാൻ കഴിയും.
3. getServerSnapshot (function, optional): ഈ ഫംഗ്‌ഷൻ പ്രത്യേകമായി സെർവർ-സൈഡ് റെൻഡറിംഗിന് (SSR) വേണ്ടിയുള്ളതാണ്. സെർവറിൽ കമ്പോണന്റ് റെൻഡർ ചെയ്യാൻ ഉപയോഗിച്ച സ്റ്റോറിന്റെ പ്രാരംഭ സ്നാപ്പ്ഷോട്ട് ഇത് തിരികെ നൽകണം. ഹൈഡ്രേഷൻ പൊരുത്തക്കേടുകൾ (hydration mismatches) തടയുന്നതിന് ഇത് നിർണായകമാണ്. സെർവർ-സൈഡ് ജനറേറ്റുചെയ്ത HTML-മായി ക്ലയിന്റ്-സൈഡ് റെൻഡർ ചെയ്ത UI പൊരുത്തപ്പെടാത്ത അവസ്ഥയാണിത്. ഇത് ഫ്ലിക്കറിംഗിനോ പിശകുകൾക്കോ കാരണമാകും. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ SSR ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഈ ആർഗ്യുമെന്റ് ഒഴിവാക്കുകയോ null പാസ് ചെയ്യുകയോ ചെയ്യാം. ഇത് ഉപയോഗിക്കുകയാണെങ്കിൽ, പ്രാരംഭ റെൻഡറിനായി ക്ലയിന്റിൽ getSnapshot തിരികെ നൽകുന്ന അതേ മൂല്യം തന്നെ സെർവറിലും ഇത് തിരികെ നൽകണം.

റിയാക്റ്റ് ഈ ഫംഗ്ഷനുകളെ വളരെ ബുദ്ധിപരമായ രീതിയിൽ ഉപയോഗിക്കുന്നു:

• ഒരു കോൺകറന്റ് റെൻഡറിനിടെ, സ്ഥിരത ഉറപ്പാക്കാൻ റിയാക്റ്റ് getSnapshot-നെ ഒന്നിലധികം തവണ വിളിച്ചേക്കാം. ഒരു റെൻഡർ ആരംഭിക്കുന്നതിനും ഒരു കമ്പോണന്റിന് അതിന്റെ മൂല്യം വായിക്കേണ്ടി വരുന്നതിനും ഇടയിൽ സ്റ്റോർ മാറിയിട്ടുണ്ടോ എന്ന് അതിന് കണ്ടെത്താനാകും. ഒരു മാറ്റം കണ്ടെത്തിയാൽ, റിയാക്റ്റ് നിലവിലുള്ള റെൻഡർ ഉപേക്ഷിച്ച് ഏറ്റവും പുതിയ സ്നാപ്പ്ഷോട്ട് ഉപയോഗിച്ച് അത് പുനരാരംഭിക്കും, അതുവഴി ടിയറിംഗ് തടയുന്നു.
• എക്സ്റ്റേണൽ സ്റ്റോറിന്റെ സ്റ്റേറ്റ് മാറുമ്പോൾ റിയാക്റ്റിനെ അറിയിക്കാൻ subscribe ഫംഗ്‌ഷൻ ഉപയോഗിക്കുന്നു, ഇത് ഒരു പുതിയ റെൻഡർ ഷെഡ്യൂൾ ചെയ്യാൻ റിയാക്റ്റിനെ പ്രേരിപ്പിക്കുന്നു.
• സെർവർ-റെൻഡർ ചെയ്ത HTML-ൽ നിന്ന് ക്ലയിന്റ്-സൈഡ് ഇന്ററാക്റ്റിവിറ്റിയിലേക്ക് സുഗമമായ ഒരു മാറ്റം `getServerSnapshot` ഉറപ്പാക്കുന്നു. ഇത് പെർസീവ്ഡ് പെർഫോമൻസിനും എസ്.ഇ.ഒ-യ്ക്കും നിർണായകമാണ്, പ്രത്യേകിച്ചും വിവിധ പ്രദേശങ്ങളിലെ ഉപയോക്താക്കൾക്ക് സേവനം നൽകുന്ന ആഗോളതലത്തിൽ വിതരണം ചെയ്യപ്പെട്ട ആപ്ലിക്കേഷനുകൾക്ക്.

പ്രായോഗിക നിർവ്വഹണം: ഒരു ഘട്ടം ഘട്ടമായുള്ള ഗൈഡ്

നമുക്ക് ഒരു പ്രായോഗിക ഉദാഹരണത്തിലൂടെ കടന്നുപോകാം. നമ്മൾ ഒരു ലളിതമായ, കസ്റ്റം ഗ്ലോബൽ സ്റ്റോർ ഉണ്ടാക്കുകയും തുടർന്ന് `useSyncExternalStore` ഉപയോഗിച്ച് റിയാക്റ്റുമായി അതിനെ സുഗമമായി സംയോജിപ്പിക്കുകയും ചെയ്യും.

ഒരു ലളിതമായ എക്സ്റ്റേണൽ സ്റ്റോർ നിർമ്മിക്കുന്നു

നമ്മുടെ കസ്റ്റം സ്റ്റോർ ഒരു ലളിതമായ കൗണ്ടർ ആയിരിക്കും. ഇതിന് സ്റ്റേറ്റ് സംഭരിക്കാനും, സ്റ്റേറ്റ് വീണ്ടെടുക്കാനും, മാറ്റങ്ങളെക്കുറിച്ച് സബ്‌സ്‌ക്രൈബർമാരെ അറിയിക്കാനും ഒരു മാർഗ്ഗം ആവശ്യമാണ്.

            
let globalCounter = 0;
const listeners = new Set();

const createExternalCounterStore = () => ({
  getState() {
    return globalCounter;
  },
  
  increment() {
    globalCounter++;
    listeners.forEach(listener => listener());
  },

  decrement() {
    globalCounter--;
    listeners.forEach(listener => listener());
  },

  subscribe(callback) {
    listeners.add(callback);
    return () => {
      listeners.delete(callback);
    };
  },

  // For SSR, provide a consistent initial snapshot if needed
  getInitialSnapshot() {
    return 0; // Or whatever your initial server-side value should be
  }
});

const counterStore = createExternalCounterStore();

            

              
                Copy
              
            
          

വിശദീകരണം:

• globalCounter: നമ്മുടെ മ്യൂട്ടബിൾ, എക്സ്റ്റേണൽ സ്റ്റേറ്റ് വേരിയബിൾ.
• listeners: സബ്‌സ്‌ക്രൈബ് ചെയ്ത എല്ലാ കോൾബാക്ക് ഫംഗ്ഷനുകളും സംഭരിക്കുന്നതിനുള്ള ഒരു Set.
• createExternalCounterStore(): നമ്മുടെ സ്റ്റോർ ലോജിക്ക് ഉൾക്കൊള്ളുന്ന ഒരു ഫാക്ടറി ഫംഗ്ഷൻ.
• getState(): globalCounter-ന്റെ നിലവിലെ മൂല്യം തിരികെ നൽകുന്നു. ഇത് `useSyncExternalStore`-നുള്ള getSnapshot ആർഗ്യുമെന്റുമായി യോജിക്കുന്നു.
• increment(), decrement(): globalCounter-ൽ മാറ്റം വരുത്താനുള്ള ഫംഗ്ഷനുകൾ. മാറ്റം വരുത്തിയ ശേഷം, രജിസ്റ്റർ ചെയ്ത എല്ലാ listeners-നെയും വിളിച്ച് ഒരു മാറ്റം സൂചിപ്പിക്കുന്നു.
• subscribe(callback): ഇത് `useSyncExternalStore`-ന്റെ നിർണായക ഭാഗമാണ്. ഇത് നൽകിയിട്ടുള്ള callback-നെ നമ്മുടെ listeners സെറ്റിലേക്ക് ചേർക്കുകയും, വിളിക്കുമ്പോൾ callback-നെ സെറ്റിൽ നിന്ന് നീക്കം ചെയ്യുന്ന ഒരു ഫംഗ്ഷൻ തിരികെ നൽകുകയും ചെയ്യുന്നു.
• getInitialSnapshot(): SSR-നുള്ള ഒരു സഹായകൻ, ഡിഫോൾട്ട് പ്രാരംഭ സ്റ്റേറ്റ് തിരികെ നൽകുന്നു.

`useSyncExternalStore`-മായി സംയോജിപ്പിക്കുന്നു

ഇപ്പോൾ, `useSyncExternalStore` ഉപയോഗിച്ച് നമ്മുടെ counterStore ഉപയോഗിക്കുന്ന ഒരു റിയാക്റ്റ് കമ്പോണന്റ് ഉണ്ടാക്കാം.

            
import React, { useSyncExternalStore } from 'react';

// Assuming counterStore is defined as above

function CounterDisplay() {
  const count = useSyncExternalStore(
    counterStore.subscribe,
    counterStore.getState,
    counterStore.getInitialSnapshot // Optional, for SSR
  );

  return (
    <div style={{ border: '1px solid #ccc', padding: '15px', margin: '10px', borderRadius: '8px' }}>
      <h3>Global Counter (via useSyncExternalStore)</h3>
      <p>Current Count: <strong>{count}</strong></p>
      <button onClick={counterStore.increment} style={{ marginRight: '10px', padding: '8px 15px', backgroundColor: '#4CAF50', color: 'white', border: 'none', borderRadius: '4px', cursor: 'pointer' }}>
        Increment
      </button>
      <button onClick={counterStore.decrement} style={{ padding: '8px 15px', backgroundColor: '#f44336', color: 'white', border: 'none', borderRadius: '4px', cursor: 'pointer' }}>
        Decrement
      </button>
    </div>
  );
}

// Example of another component that might use the same store
function DoubleCounterDisplay() {
  const count = useSyncExternalStore(
    counterStore.subscribe,
    counterStore.getState,
    counterStore.getInitialSnapshot
  );

  return (
    <div style={{ border: '1px solid #ddd', padding: '15px', margin: '10px', borderRadius: '8px', backgroundColor: '#f9f9f9' }}>
      <h4>Double Count Display</h4>
      <p>Count x 2: <strong>{count * 2}</strong></p>
    </div>
  );
}

// In your main App component:
function App() {
  return (
    <div>
      <h1>React useSyncExternalStore Demo</h1>
      <CounterDisplay />
      <DoubleCounterDisplay />
      <p>Both components are synchronized with the same external store, guaranteed without tearing.</p>
    </div>
  );
}

export default App;

            

              
                Copy
              
            
          

വിശദീകരണം:

• നമ്മൾ റിയാക്റ്റിൽ നിന്ന് useSyncExternalStore ഇമ്പോർട്ട് ചെയ്യുന്നു.
• CounterDisplay, DoubleCounterDisplay എന്നിവയ്ക്കുള്ളിൽ, നമ്മുടെ സ്റ്റോറിന്റെ subscribe, getState മെത്തേഡുകൾ നേരിട്ട് പാസ് ചെയ്തുകൊണ്ട് useSyncExternalStore വിളിക്കുന്നു.
• SSR അനുയോജ്യതയ്ക്കായി മൂന്നാമത്തെ ആർഗ്യുമെന്റായി counterStore.getInitialSnapshot നൽകിയിരിക്കുന്നു.
• increment അല്ലെങ്കിൽ decrement ബട്ടണുകൾ ക്ലിക്ക് ചെയ്യുമ്പോൾ, അവ നേരിട്ട് നമ്മുടെ counterStore-ലെ മെത്തേഡുകളെ വിളിക്കുന്നു, ഇത് `useSyncExternalStore`-നുള്ള റിയാക്റ്റിന്റെ ഇന്റെർണൽ കോൾബാക്ക് ഉൾപ്പെടെ എല്ലാ ലിസണർമാരെയും അറിയിക്കുന്നു. ഇത് നമ്മുടെ കമ്പോണന്റുകളിൽ ഒരു റീ-റെൻഡറിന് കാരണമാവുകയും കൗണ്ടിന്റെ ഏറ്റവും പുതിയ സ്നാപ്പ്ഷോട്ട് എടുക്കുകയും ചെയ്യുന്നു.
• useSyncExternalStore-ന്റെ ഉറപ്പുകൾക്ക് നന്ദി, കോൺകറന്റ് സാഹചര്യങ്ങളിൽ പോലും CounterDisplay, DoubleCounterDisplay എന്നിവ രണ്ടും എപ്പോഴും globalCounter-ന്റെ ഒരു സ്ഥിരമായ കാഴ്ച കാണിക്കുമെന്ന് ശ്രദ്ധിക്കുക.

സെർവർ-സൈഡ് റെൻഡറിംഗ് (SSR) കൈകാര്യം ചെയ്യൽ

വേഗതയേറിയ പ്രാരംഭ ലോഡുകൾക്കും മെച്ചപ്പെട്ട എസ്.ഇ.ഒ-യ്ക്കും വൈവിധ്യമാർന്ന നെറ്റ്‌വർക്കുകളിലുടനീളമുള്ള മികച്ച ഉപയോക്തൃ അനുഭവത്തിനും വേണ്ടി സെർവർ-സൈഡ് റെൻഡറിംഗിനെ ആശ്രയിക്കുന്ന ആപ്ലിക്കേഷനുകൾക്ക്, `getServerSnapshot` എന്ന ആർഗ്യുമെന്റ് ഒഴിച്ചുകൂടാനാവാത്തതാണ്. അതില്ലാതെ, "ഹൈഡ്രേഷൻ മിസ്മാച്ച്" എന്നറിയപ്പെടുന്ന ഒരു സാധാരണ പ്രശ്നം ഉണ്ടാകാം.

സെർവറിൽ ജനറേറ്റ് ചെയ്ത HTML (അത് എക്സ്റ്റേണൽ സ്റ്റോറിൽ നിന്ന് ഒരു നിശ്ചിത സ്റ്റേറ്റ് വായിച്ചേക്കാം) ക്ലയിന്റിൽ റിയാക്റ്റ് അതിന്റെ പ്രാരംഭ ഹൈഡ്രേഷൻ പ്രക്രിയയിൽ റെൻഡർ ചെയ്യുന്ന HTML-മായി (അത് അതേ എക്സ്റ്റേണൽ സ്റ്റോറിൽ നിന്ന് വ്യത്യസ്തവും അപ്ഡേറ്റ് ചെയ്തതുമായ ഒരു സ്റ്റേറ്റ് വായിച്ചേക്കാം) കൃത്യമായി പൊരുത്തപ്പെടാത്തപ്പോഴാണ് ഒരു ഹൈഡ്രേഷൻ മിസ്മാച്ച് സംഭവിക്കുന്നത്. ഈ പൊരുത്തക്കേട് പിശകുകൾക്കോ വിഷ്വൽ തകരാറുകൾക്കോ അല്ലെങ്കിൽ നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ചില ഭാഗങ്ങൾ ഇന്ററാക്ടീവ് ആകുന്നതിൽ പരാജയപ്പെടുന്നതിനോ ഇടയാക്കും.

`getServerSnapshot` നൽകുന്നതിലൂടെ, കമ്പോണന്റ് സെർവറിൽ റെൻഡർ ചെയ്തപ്പോൾ നിങ്ങളുടെ എക്സ്റ്റേണൽ സ്റ്റോറിന്റെ പ്രാരംഭ സ്റ്റേറ്റ് എന്തായിരുന്നുവെന്ന് നിങ്ങൾ റിയാക്റ്റിനോട് കൃത്യമായി പറയുന്നു. ക്ലയിന്റിൽ, പ്രാരംഭ റെൻഡറിനായി റിയാക്റ്റ് ആദ്യം `getServerSnapshot` ഉപയോഗിക്കും, ഇത് സെർവറിന്റെ ഔട്ട്പുട്ടുമായി പൊരുത്തപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുന്നു. ഹൈഡ്രേഷൻ പൂർത്തിയായതിനുശേഷം മാത്രമേ തുടർന്നുള്ള അപ്‌ഡേറ്റുകൾക്കായി `getSnapshot` ഉപയോഗിക്കുന്നതിലേക്ക് മാറുകയുള്ളൂ. ഇത് സെർവർ ലൊക്കേഷനോ ക്ലയിന്റ് നെറ്റ്‌വർക്ക് അവസ്ഥകളോ പരിഗണിക്കാതെ, ആഗോളതലത്തിൽ തടസ്സമില്ലാത്ത ഒരു മാറ്റവും സ്ഥിരതയുള്ള ഉപയോക്തൃ അനുഭവവും ഉറപ്പ് നൽകുന്നു.

നമ്മുടെ ഉദാഹരണത്തിൽ, counterStore.getInitialSnapshot ഈ ഉദ്ദേശ്യം നിറവേറ്റുന്നു. സെർവർ റെൻഡർ ചെയ്ത കൗണ്ട് (ഉദാഹരണത്തിന്, 0) ക്ലയിന്റിൽ ആരംഭിക്കുമ്പോൾ റിയാക്റ്റ് പ്രതീക്ഷിക്കുന്നത് തന്നെയാണെന്ന് ഇത് ഉറപ്പാക്കുന്നു, ഹൈഡ്രേഷൻ സമയത്ത് സ്റ്റേറ്റിലെ പൊരുത്തക്കേടുകൾ കാരണം ഉണ്ടാകുന്ന ഫ്ലിക്കറിംഗോ റീ-റെൻഡറിംഗോ തടയുന്നു.

എപ്പോൾ `useSyncExternalStore` ഉപയോഗിക്കണം

ശക്തമാണെങ്കിലും, `useSyncExternalStore` ഒരു പ്രത്യേക ഹുക്കാണ്, എല്ലാ സ്റ്റേറ്റ് മാനേജ്‌മെന്റിനുമുള്ള ഒരു പൊതുവായ പകരക്കാരനല്ല. ഇത് ശരിക്കും തിളങ്ങുന്ന സാഹചര്യങ്ങൾ താഴെ പറയുന്നവയാണ്:

• ലെഗസി കോഡ്‌ബേസുകളുമായി സംയോജിപ്പിക്കുമ്പോൾ: നിങ്ങൾ ഒരു പഴയ ആപ്ലിക്കേഷനെ ക്രമേണ റിയാക്റ്റിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുകയോ അല്ലെങ്കിൽ സ്വന്തം മ്യൂട്ടബിൾ ഗ്ലോബൽ സ്റ്റേറ്റ് ഉപയോഗിക്കുന്ന നിലവിലുള്ള ഒരു ജാവാസ്ക്രിപ്റ്റ് കോഡ്‌ബേസുമായി പ്രവർത്തിക്കുകയോ ചെയ്യുമ്പോൾ, `useSyncExternalStore` ആ സ്റ്റേറ്റിനെ എല്ലാം മാറ്റിയെഴുതാതെ തന്നെ നിങ്ങളുടെ റിയാക്റ്റ് കമ്പോണന്റുകളിലേക്ക് സുരക്ഷിതവും ശക്തവുമായ രീതിയിൽ കൊണ്ടുവരാൻ സഹായിക്കുന്നു. ലോകമെമ്പാടുമുള്ള വലിയ സംരംഭങ്ങൾക്കും നിലവിലുള്ള പ്രോജക്റ്റുകൾക്കും ഇത് വളരെ മൂല്യവത്താണ്.
• റിയാക്റ്റ് ഇതര സ്റ്റേറ്റ് ലൈബ്രറികളുമായി പ്രവർത്തിക്കുമ്പോൾ: റിയാക്ടീവ് പ്രോഗ്രാമിംഗിനായുള്ള RxJS പോലുള്ള ലൈബ്രറികൾ, കസ്റ്റം ഇവന്റ് എമിറ്ററുകൾ, അല്ലെങ്കിൽ നേരിട്ടുള്ള ബ്രൗസർ API-കൾ (ഉദാഹരണത്തിന്, റെസ്പോൺസീവ് ഡിസൈനിനായി window.matchMedia, പെർസിസ്റ്റന്റ് ക്ലയിന്റ്-സൈഡ് ഡാറ്റയ്ക്കായി localStorage, അല്ലെങ്കിൽ തത്സമയ ഡാറ്റയ്ക്കായി വെബ്സോക്കറ്റുകൾ) എന്നിവ പ്രധാന ഉദാഹരണങ്ങളാണ്. `useSyncExternalStore`-ന് ഈ എക്സ്റ്റേണൽ ഡാറ്റാ സ്ട്രീമുകളെ നിങ്ങളുടെ റിയാക്റ്റ് കമ്പോണന്റുകളിലേക്ക് നേരിട്ട് ബന്ധിപ്പിക്കാൻ കഴിയും.
• പ്രകടന-നിർണ്ണായക സാഹചര്യങ്ങളും കോൺകറന്റ് മോഡ് സ്വീകരണവും: ഒരു കോൺകറന്റ് റിയാക്റ്റ് എൻവയോൺമെന്റിൽ പൂർണ്ണമായ സ്ഥിരതയും കുറഞ്ഞ ടിയറിംഗും ആവശ്യമുള്ള ആപ്ലിക്കേഷനുകൾക്ക്, `useSyncExternalStore` ഒരു മികച്ച പരിഹാരമാണ്. ടിയറിംഗ് തടയുന്നതിനും ഭാവിയിലെ റിയാക്റ്റ് പതിപ്പുകളിൽ ഒപ്റ്റിമൽ പ്രകടനം ഉറപ്പാക്കുന്നതിനും ഇത് അടിത്തറയിട്ട് നിർമ്മിച്ചതാണ്.
• നിങ്ങളുടെ സ്വന്തം സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് ലൈബ്രറി നിർമ്മിക്കുമ്പോൾ: നിങ്ങൾ ഒരു ഓപ്പൺ സോഴ്‌സ് കോൺട്രിബ്യൂട്ടറോ അല്ലെങ്കിൽ നിങ്ങളുടെ ഓർഗനൈസേഷനായി ഒരു കസ്റ്റം സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് സൊല്യൂഷൻ ഉണ്ടാക്കുന്ന ഡെവലപ്പറോ ആണെങ്കിൽ, `useSyncExternalStore` നിങ്ങളുടെ ലൈബ്രറിയെ റിയാക്റ്റിന്റെ റെൻഡറിംഗ് മോഡലുമായി ശക്തമായി സംയോജിപ്പിക്കുന്നതിന് ആവശ്യമായ ലോ-ലെവൽ പ്രിമിറ്റീവ് നൽകുന്നു, ഇത് നിങ്ങളുടെ ഉപയോക്താക്കൾക്ക് മികച്ച അനുഭവം നൽകുന്നു. Zustand പോലുള്ള പല ആധുനിക സ്റ്റേറ്റ് ലൈബ്രറികളും ഇതിനകം തന്നെ `useSyncExternalStore` ആന്തരികമായി ഉപയോഗിക്കുന്നുണ്ട്.
• ഗ്ലോബൽ കോൺഫിഗറേഷൻ അല്ലെങ്കിൽ ഫീച്ചർ ഫ്ലാഗുകൾ: ചലനാത്മകമായി മാറാൻ സാധ്യതയുള്ളതും UI-ൽ ഉടനീളം സ്ഥിരമായി പ്രതിഫലിക്കേണ്ടതുമായ ഗ്ലോബൽ സെറ്റിംഗ്‌സിനോ ഫീച്ചർ ഫ്ലാഗുകൾക്കോ, `useSyncExternalStore` കൈകാര്യം ചെയ്യുന്ന ഒരു എക്സ്റ്റേണൽ സ്റ്റോർ കാര്യക്ഷമമായ ഒരു തിരഞ്ഞെടുപ്പായിരിക്കും.

`useSyncExternalStore`-ഉം മറ്റ് സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് സമീപനങ്ങളും

വിശാലമായ റിയാക്റ്റ് സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് ലാൻഡ്‌സ്‌കേപ്പിൽ `useSyncExternalStore` എവിടെയാണ് യോജിക്കുന്നത് എന്ന് മനസ്സിലാക്കുന്നത് അത് ഫലപ്രദമായി ഉപയോഗിക്കുന്നതിന് പ്രധാനമാണ്.

vs. `useState`/`useEffect`

ചർച്ച ചെയ്തതുപോലെ, `useState`-ഉം `useEffect`-ഉം ഇന്റെർണൽ കമ്പോണന്റ് സ്റ്റേറ്റ് കൈകാര്യം ചെയ്യുന്നതിനും സൈഡ് എഫക്റ്റുകൾ കൈകാര്യം ചെയ്യുന്നതിനുമുള്ള റിയാക്റ്റിന്റെ അടിസ്ഥാന ഹുക്കുകളാണ്. എക്സ്റ്റേണൽ സ്റ്റോറുകളിലേക്ക് സബ്‌സ്‌ക്രൈബ് ചെയ്യാൻ നിങ്ങൾക്ക് അവ ഉപയോഗിക്കാൻ കഴിയും, എന്നാൽ കോൺകറന്റ് റിയാക്റ്റിൽ ടിയറിംഗിനെതിരെ അവ അതേ ഉറപ്പുകൾ നൽകുന്നില്ല.

• `useState`/`useEffect` ഗുണങ്ങൾ: കമ്പോണന്റ്-ലോക്കൽ സ്റ്റേറ്റിനോ അല്ലെങ്കിൽ ടിയറിംഗ് ഒരു നിർണായക ആശങ്കയല്ലാത്ത ലളിതമായ എക്സ്റ്റേണൽ സബ്‌സ്‌ക്രിപ്ഷനുകൾക്കോ (ഉദാഹരണത്തിന്, എക്സ്റ്റേണൽ സ്റ്റോർ അപൂർവ്വമായി മാറുമ്പോൾ അല്ലെങ്കിൽ ഒരു കോൺകറന്റ് അപ്‌ഡേറ്റ് പാഥിന്റെ ഭാഗമല്ലാത്തപ്പോൾ) ലളിതമാണ്.
• `useState`/`useEffect` ദോഷങ്ങൾ: മ്യൂട്ടബിൾ എക്സ്റ്റേണൽ സ്റ്റോറുകളുമായി ഇടപെടുമ്പോൾ കോൺകറന്റ് റിയാക്റ്റിൽ ടിയറിംഗിന് സാധ്യതയുണ്ട്. മാനുവൽ ക്ലീനപ്പ് ആവശ്യമാണ്.
• `useSyncExternalStore` പ്രയോജനം: ഒരു റെൻഡർ പാസിൽ സ്ഥിരമായ ഒരു സ്നാപ്പ്ഷോട്ട് വായിക്കാൻ റിയാക്റ്റിനെ നിർബന്ധിച്ചുകൊണ്ട് ടിയറിംഗ് തടയുന്നതിനായി പ്രത്യേകം രൂപകൽപ്പന ചെയ്തതാണ്, ഇത് കോൺകറന്റ് എൻവയോൺമെന്റുകളിൽ എക്സ്റ്റേണൽ, മ്യൂട്ടബിൾ സ്റ്റേറ്റിന് ശക്തമായ തിരഞ്ഞെടുപ്പായി മാറുന്നു. ഇത് സിൻക്രൊണൈസേഷൻ ലോജിക്കിന്റെ സങ്കീർണ്ണത റിയാക്റ്റിന്റെ കോറിലേക്ക് ഓഫ്‌ലോഡ് ചെയ്യുന്നു.

vs. Context API

പ്രോപ്പ് ഡ്രില്ലിംഗ് ഇല്ലാതെ കമ്പോണന്റ് ട്രീയിലൂടെ ഡാറ്റ ആഴത്തിൽ കൈമാറാൻ കോൺടെക്സ്റ്റ് API മികച്ചതാണ്. ഇത് റിയാക്റ്റിന്റെ റെൻഡറിംഗ് സൈക്കിളിന് ഉള്ളിലുള്ള സ്റ്റേറ്റ് കൈകാര്യം ചെയ്യുന്നു. എന്നിരുന്നാലും, റിയാക്റ്റിൽ നിന്ന് സ്വതന്ത്രമായി മാറാൻ കഴിയുന്ന എക്സ്റ്റേണൽ മ്യൂട്ടബിൾ സ്റ്റോറുകളുമായി സിൻക്രൊണൈസ് ചെയ്യാൻ ഇത് രൂപകൽപ്പന ചെയ്തിട്ടില്ല.

• Context API ഗുണങ്ങൾ: തീമിംഗ്, യൂസർ ഓതന്റിക്കേഷൻ, അല്ലെങ്കിൽ ട്രീയുടെ വിവിധ തലങ്ങളിലുള്ള നിരവധി കമ്പോണന്റുകൾക്ക് ആക്‌സസ് ചെയ്യേണ്ടതും പ്രാഥമികമായി റിയാക്റ്റ് തന്നെ കൈകാര്യം ചെയ്യുന്നതുമായ മറ്റ് ഡാറ്റകൾക്ക് മികച്ചതാണ്.
• Context API ദോഷങ്ങൾ: കോൺടെക്സ്റ്റിലെ അപ്‌ഡേറ്റുകൾ ഇപ്പോഴും റിയാക്റ്റിന്റെ റെൻഡറിംഗ് മോഡൽ പിന്തുടരുന്നു, കോൺടെക്സ്റ്റ് മൂല്യത്തിലെ മാറ്റങ്ങൾ കാരണം ഉപഭോക്താക്കൾ ഇടയ്ക്കിടെ റീ-റെൻഡർ ചെയ്യുകയാണെങ്കിൽ പ്രകടന പ്രശ്നങ്ങൾ ഉണ്ടാകാം. എക്സ്റ്റേണൽ, മ്യൂട്ടബിൾ ഡാറ്റാ സോഴ്‌സുകൾക്കുള്ള ടിയറിംഗ് പ്രശ്നം ഇത് പരിഹരിക്കുന്നില്ല.
• `useSyncExternalStore` പ്രയോജനം: എക്സ്റ്റേണൽ, മ്യൂട്ടബിൾ ഡാറ്റയെ റിയാക്റ്റുമായി സുരക്ഷിതമായി ബന്ധിപ്പിക്കുന്നതിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു, കോൺടെക്സ്റ്റ് നൽകാത്ത ലോ-ലെവൽ സിൻക്രൊണൈസേഷൻ പ്രിമിറ്റീവുകൾ നൽകുന്നു. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ആർക്കിടെക്ചറിന് അനുയോജ്യമാണെങ്കിൽ, കോൺടെക്സ്റ്റ് വഴി അതിന്റെ മൂല്യം നൽകുന്ന ഒരു കസ്റ്റം ഹുക്കിനുള്ളിൽ നിങ്ങൾക്ക് `useSyncExternalStore` ഉപയോഗിക്കാൻ പോലും കഴിയും.

vs. സമർപ്പിത സ്റ്റേറ്റ് ലൈബ്രറികൾ (Redux, Zustand, Jotai, Recoil, etc.)

ആധുനിക, സമർപ്പിത സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് ലൈബ്രറികൾ പലപ്പോഴും സങ്കീർണ്ണമായ ആപ്ലിക്കേഷൻ സ്റ്റേറ്റിനായി കൂടുതൽ സമ്പൂർണ്ണമായ ഒരു പരിഹാരം നൽകുന്നു, അതിൽ മിഡിൽവെയർ, ഇമ്മ്യൂട്ടബിലിറ്റി ഉറപ്പുകൾ, ഡെവലപ്പർ ടൂളുകൾ, അസിൻക്രണസ് ഓപ്പറേഷനുകൾക്കുള്ള പാറ്റേണുകൾ എന്നിവ പോലുള്ള ഫീച്ചറുകൾ ഉൾപ്പെടുന്നു. ഈ ലൈബ്രറികളും `useSyncExternalStore`-ഉം തമ്മിലുള്ള ബന്ധം പലപ്പോഴും പരസ്പരം പൂരകമാണ്, ശത്രുതാപരമല്ല.

• സമർപ്പിത ലൈബ്രറികളുടെ ഗുണങ്ങൾ: ഗ്ലോബൽ സ്റ്റേറ്റിനായി സമഗ്രമായ പരിഹാരങ്ങൾ വാഗ്ദാനം ചെയ്യുന്നു, പലപ്പോഴും സ്റ്റേറ്റ് എങ്ങനെ ഘടനാപരമാക്കണം, അപ്‌ഡേറ്റ് ചെയ്യണം, ആക്‌സസ് ചെയ്യണം എന്നതിനെക്കുറിച്ച് ശക്തമായ അഭിപ്രായങ്ങളുണ്ട്. വലിയ ആപ്ലിക്കേഷനുകൾക്ക് ബോയിലർപ്ലേറ്റ് കുറയ്ക്കാനും മികച്ച രീതികൾ നടപ്പിലാക്കാനും അവയ്ക്ക് കഴിയും.
• സമർപ്പിത ലൈബ്രറികളുടെ ദോഷങ്ങൾ: അവയ്ക്ക് അവരുടേതായ പഠനരീതികളും ബോയിലർപ്ലേറ്റുകളും ഉണ്ടാകാം. ചില പഴയ നിർവ്വഹണങ്ങൾ ആന്തരിക റീഫാക്റ്ററിംഗ് ഇല്ലാതെ കോൺകറന്റ് റിയാക്റ്റിനായി പൂർണ്ണമായി ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കില്ല.
• `useSyncExternalStore` സിനർജി: പല ആധുനിക ലൈബ്രറികളും, പ്രത്യേകിച്ച് ഹുക്കുകൾ മനസ്സിൽ വെച്ച് രൂപകൽപ്പന ചെയ്തവ (Zustand, Jotai, അല്ലെങ്കിൽ Redux-ന്റെ പുതിയ പതിപ്പുകൾ പോലും), ഇതിനകം `useSyncExternalStore` ആന്തരികമായി ഉപയോഗിക്കുകയോ ഉപയോഗിക്കാൻ പദ്ധതിയിടുകയോ ചെയ്യുന്നു. ഈ ഹുക്ക് ഈ ലൈബ്രറികൾക്ക് കോൺകറന്റ് റിയാക്റ്റുമായി തടസ്സങ്ങളില്ലാതെ സംയോജിക്കുന്നതിനുള്ള അടിസ്ഥാന മെക്കാനിസം നൽകുന്നു, അവയുടെ ഉയർന്ന തലത്തിലുള്ള ഫീച്ചറുകൾ വാഗ്ദാനം ചെയ്യുമ്പോൾ തന്നെ ടിയറിംഗ് ഇല്ലാത്ത സിൻക്രൊണൈസേഷൻ ഉറപ്പ് നൽകുന്നു. നിങ്ങൾ ഒരു സ്റ്റേറ്റ് ലൈബ്രറി നിർമ്മിക്കുകയാണെങ്കിൽ, `useSyncExternalStore` ഒരു ശക്തമായ പ്രിമിറ്റീവാണ്. നിങ്ങൾ ഒരു ഉപയോക്താവാണെങ്കിൽ, നിങ്ങൾ അത് അറിയാതെ തന്നെ അതിന്റെ പ്രയോജനം നേടുന്നുണ്ടാകാം!

വിപുലമായ പരിഗണനകളും മികച്ച രീതികളും

`useSyncExternalStore`-ന്റെ പ്രയോജനങ്ങൾ പരമാവധിയാക്കുന്നതിനും നിങ്ങളുടെ ആഗോള ഉപയോക്താക്കൾക്കായി ശക്തമായ ഒരു നിർവ്വഹണം ഉറപ്പാക്കുന്നതിനും, ഈ വിപുലമായ കാര്യങ്ങൾ പരിഗണിക്കുക:

• `getSnapshot` ഫലങ്ങളുടെ മെമ്മോയിസേഷൻ: getSnapshot ഫംഗ്ഷൻ അനുയോജ്യമായി ഒരു സ്ഥിരതയുള്ള, ഒരുപക്ഷേ മെമ്മോയിസ് ചെയ്ത മൂല്യം തിരികെ നൽകണം. getSnapshot ഓരോ കോളിലും സങ്കീർണ്ണമായ കണക്കുകൂട്ടലുകൾ നടത്തുകയോ പുതിയ ഒബ്ജക്റ്റ്/അറേ റഫറൻസുകൾ ഉണ്ടാക്കുകയോ ചെയ്യുകയും, ഈ റഫറൻസുകൾ മൂല്യത്തിൽ കർശനമായി മാറുന്നില്ലെങ്കിൽ, അത് അനാവശ്യമായ റീ-റെൻഡറുകൾക്ക് ഇടയാക്കും. നിങ്ങളുടെ അടിസ്ഥാന സ്റ്റോറിന്റെ getState അല്ലെങ്കിൽ നിങ്ങളുടെ getSnapshot റാപ്പർ യഥാർത്ഥ ഡാറ്റ മാറുമ്പോൾ മാത്രം ഒരു പുതിയ മൂല്യം തിരികെ നൽകുന്നുവെന്ന് ഉറപ്പാക്കുക.
  

              
  const memoizedGetState = React.useCallback(() => {
    // Perform some expensive computation or transformation
    // For simplicity, let's just return the raw state
    return store.getState(); 
  }, []);
  
  const count = useSyncExternalStore(store.subscribe, memoizedGetState);
      
              
  
                
                  Copy
                
              
            

  നിങ്ങളുടെ getState സ്വാഭാവികമായി ഒരു ഇമ്മ്യൂട്ടബിൾ മൂല്യമോ പ്രിമിറ്റീവോ തിരികെ നൽകുകയാണെങ്കിൽ, ഇത് കർശനമായി ആവശ്യമില്ലായിരിക്കാം, പക്ഷേ ഇത് അറിഞ്ഞിരിക്കേണ്ട ഒരു നല്ല ശീലമാണ്.
• സ്നാപ്പ്ഷോട്ടിന്റെ ഇമ്മ്യൂട്ടബിലിറ്റി: നിങ്ങളുടെ എക്സ്റ്റേണൽ സ്റ്റോർ തന്നെ മ്യൂട്ടബിൾ ആകാമെങ്കിലും, `getSnapshot` തിരികെ നൽകുന്ന മൂല്യം റിയാക്റ്റ് കമ്പോണന്റുകൾ ഇമ്മ്യൂട്ടബിൾ ആയി കണക്കാക്കണം. `getSnapshot` ഒരു ഒബ്ജക്റ്റോ അറേയോ തിരികെ നൽകുകയും, റിയാക്റ്റ് അത് വായിച്ചതിനു ശേഷം (എന്നാൽ അടുത്ത റെൻഡർ സൈക്കിളിന് മുമ്പ്) നിങ്ങൾ ആ ഒബ്ജക്റ്റ്/അറേ മ്യൂട്ടേറ്റ് ചെയ്യുകയാണെങ്കിൽ, നിങ്ങൾ പൊരുത്തക്കേടുകൾ ഉണ്ടാക്കിയേക്കാം. അടിസ്ഥാന ഡാറ്റ ശരിക്കും മാറുകയാണെങ്കിൽ ഒരു പുതിയ ഒബ്ജക്റ്റ്/അറേ റഫറൻസ് തിരികെ നൽകുന്നത് സുരക്ഷിതമാണ്, അല്ലെങ്കിൽ സ്റ്റോറിനുള്ളിൽ മ്യൂട്ടേഷൻ ഒഴിവാക്കാനാവാത്തതും സ്നാപ്പ്ഷോട്ട് ഒറ്റപ്പെടുത്തേണ്ടതും ആവശ്യമാണെങ്കിൽ ആഴത്തിൽ ക്ലോൺ ചെയ്ത ഒരു പകർപ്പ് തിരികെ നൽകുക.
• സബ്‌സ്‌ക്രിപ്‌ഷൻ സ്ഥിരത: subscribe ഫംഗ്ഷൻ തന്നെ റെൻഡറുകളിലുടനീളം സ്ഥിരമായിരിക്കണം. ഓരോ റെൻഡറിലും റിയാക്റ്റ് അനാവശ്യമായി വീണ്ടും സബ്‌സ്‌ക്രൈബ് ചെയ്യുന്നത് തടയാൻ, ഇത് സാധാരണയായി നിങ്ങളുടെ കമ്പോണന്റിന് പുറത്ത് നിർവചിക്കുകയോ അല്ലെങ്കിൽ കമ്പോണന്റ് പ്രോപ്പുകളെയോ സ്റ്റേറ്റിനെയോ ആശ്രയിച്ചിരിക്കുകയാണെങ്കിൽ useCallback ഉപയോഗിക്കുകയോ ചെയ്യണം. നമ്മുടെ counterStore.subscribe ആഗോളതലത്തിൽ നിർവചിക്കപ്പെട്ട ഒരു ഒബ്ജക്റ്റിലെ മെത്തേഡ് ആയതിനാൽ സ്വാഭാവികമായും സ്ഥിരതയുള്ളതാണ്.
• പിശകുകൾ കൈകാര്യം ചെയ്യൽ: നിങ്ങളുടെ എക്സ്റ്റേണൽ സ്റ്റോർ പിശകുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നുവെന്ന് പരിഗണിക്കുക. സ്റ്റോറിന് തന്നെ `getState` അല്ലെങ്കിൽ `subscribe` സമയത്ത് പിശകുകൾ ഉണ്ടാക്കാൻ കഴിയുമെങ്കിൽ, ആപ്ലിക്കേഷൻ ക്രാഷുകൾ തടയുന്നതിന് നിങ്ങളുടെ `getSnapshot`, `subscribe` നിർവ്വഹണങ്ങൾക്കുള്ളിൽ ഈ കോളുകളെ ഉചിതമായ എറർ ബൗണ്ടറികളിലോ `try...catch` ബ്ലോക്കുകളിലോ പൊതിയുക. ഒരു ഗ്ലോബൽ ആപ്ലിക്കേഷന്, അപ്രതീക്ഷിതമായ ഡാറ്റാ പ്രശ്നങ്ങളുടെ മുന്നിലും സ്ഥിരമായ ഉപയോക്തൃ അനുഭവം ഉറപ്പാക്കാൻ ശക്തമായ എറർ ഹാൻഡ്ലിംഗ് സഹായിക്കുന്നു.
• ടെസ്റ്റിംഗ്: `useSyncExternalStore` ഉപയോഗിക്കുന്ന കമ്പോണന്റുകൾ ടെസ്റ്റ് ചെയ്യുമ്പോൾ, നിങ്ങൾ സാധാരണയായി നിങ്ങളുടെ എക്സ്റ്റേണൽ സ്റ്റോർ മോക്ക് ചെയ്യും. റിയാക്റ്റ് സ്റ്റോറുമായി എങ്ങനെ സംവദിക്കുന്നുവെന്ന് നിങ്ങളുടെ ടെസ്റ്റുകൾ കൃത്യമായി പ്രതിഫലിപ്പിക്കുന്നതിനായി നിങ്ങളുടെ മോക്കുകൾ `subscribe`, `getState`, `getServerSnapshot` മെത്തേഡുകൾ ശരിയായി നടപ്പിലാക്കുന്നുവെന്ന് ഉറപ്പാക്കുക.
• ബണ്ടിൽ വലുപ്പം: `useSyncExternalStore` ഒരു ബിൽറ്റ്-ഇൻ റിയാക്റ്റ് ഹുക്കാണ്, അതായത് ഇത് നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ബണ്ടിൽ വലുപ്പത്തിൽ കാര്യമായ ഓവർഹെഡ് ചേർക്കുന്നില്ല, പ്രത്യേകിച്ചും ഒരു വലിയ തേർഡ്-പാർട്ടി സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് ലൈബ്രറി ഉൾപ്പെടുത്തുന്നതുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ. വ്യത്യസ്ത നെറ്റ്‌വർക്ക് വേഗതയിലുള്ള ഉപയോക്താക്കൾക്ക് പ്രാരംഭ ലോഡ് സമയം കുറയ്ക്കുന്നത് നിർണായകമായ ഗ്ലോബൽ ആപ്ലിക്കേഷനുകൾക്ക് ഇത് ഒരു നേട്ടമാണ്.
• ക്രോസ്-ഫ്രെയിംവർക്ക് അനുയോജ്യത (ആശയപരമായി): `useSyncExternalStore` ഒരു റിയാക്റ്റ്-നിർദ്ദിഷ്ട പ്രിമിറ്റീവ് ആണെങ്കിലും, അത് പരിഹരിക്കുന്ന അടിസ്ഥാന പ്രശ്നം - ഒരു കോൺകറന്റ് UI ഫ്രെയിംവർക്കിൽ എക്സ്റ്റേണൽ മ്യൂട്ടബിൾ സ്റ്റേറ്റുമായി സിൻക്രൊണൈസ് ചെയ്യുക - റിയാക്റ്റിന് മാത്രം ബാധകമല്ല. ഈ ഹുക്ക് മനസ്സിലാക്കുന്നത് മറ്റ് ഫ്രെയിംവർക്കുകൾ സമാനമായ വെല്ലുവിളികളെ എങ്ങനെ നേരിടാമെന്നതിനെക്കുറിച്ചുള്ള ഉൾക്കാഴ്ചകൾ നൽകാനും ഫ്രണ്ട്-എൻഡ് ആർക്കിടെക്ചറിനെക്കുറിച്ച് ആഴത്തിലുള്ള ധാരണ വളർത്താനും സഹായിക്കും.

റിയാക്റ്റിലെ സ്റ്റേറ്റ് മാനേജ്‌മെന്റിന്റെ ഭാവി

`useSyncExternalStore` ഒരു സൗകര്യപ്രദമായ ഹുക്ക് എന്നതിലുപരി, റിയാക്റ്റിന്റെ ഭാവിക്കായുള്ള പസിലിന്റെ ഒരു അടിസ്ഥാന ഭാഗമാണ്. അതിന്റെ നിലനിൽപ്പും രൂപകൽപ്പനയും കോൺകറന്റ് മോഡ്, ഡാറ്റാ ഫെച്ചിംഗിനുള്ള സസ്പെൻസ് പോലുള്ള ശക്തമായ ഫീച്ചറുകൾ പ്രവർത്തനക്ഷമമാക്കുന്നതിനുള്ള റിയാക്റ്റിന്റെ പ്രതിബദ്ധതയെ സൂചിപ്പിക്കുന്നു. എക്സ്റ്റേണൽ സ്റ്റേറ്റ് സിൻക്രൊണൈസേഷനായി ഒരു വിശ്വസനീയമായ പ്രിമിറ്റീവ് നൽകുന്നതിലൂടെ, റിയാക്റ്റ് ഡെവലപ്പർമാരെയും ലൈബ്രറി രചയിതാക്കളെയും കൂടുതൽ പ്രതിരോധശേഷിയുള്ളതും ഉയർന്ന പ്രകടനക്ഷമതയുള്ളതും ഭാവിക്ക് അനുയോജ്യവുമായ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കാൻ പ്രാപ്തരാക്കുന്നു.

റിയാക്റ്റ് വികസിക്കുന്നത് തുടരുമ്പോൾ, ഓഫ്‌സ്‌ക്രീൻ റെൻഡറിംഗ്, ഓട്ടോമാറ്റിക് ബാച്ചിംഗ്, മുൻഗണനാക്രമത്തിലുള്ള അപ്‌ഡേറ്റുകൾ തുടങ്ങിയ ഫീച്ചറുകൾ കൂടുതൽ പ്രചാരത്തിലാകും. `useSyncExternalStore` ഏറ്റവും സങ്കീർണ്ണമായ എക്സ്റ്റേണൽ ഡാറ്റാ ഇടപെടലുകൾ പോലും ഈ നൂതന റെൻഡറിംഗ് മാതൃകയ്ക്കുള്ളിൽ സ്ഥിരതയുള്ളതും പ്രകടനക്ഷമതയുള്ളതുമായി നിലനിൽക്കുമെന്ന് ഉറപ്പാക്കുന്നു. കോൺകറന്റ്-സേഫ് സിൻക്രൊണൈസേഷന്റെ സങ്കീർണ്ണതകൾ ഒഴിവാക്കി ഡെവലപ്പർ അനുഭവം ഇത് ലളിതമാക്കുന്നു, ടിയറിംഗ് പ്രശ്നങ്ങളുമായി മല്ലിടുന്നതിനുപകരം ഫീച്ചറുകൾ നിർമ്മിക്കുന്നതിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ഉപസംഹാരം

`useSyncExternalStore` ഹുക്ക് (മുൻപ് `experimental_useSyncExternalStore`) സ്റ്റേറ്റ് മാനേജ്‌മെന്റിലെ റിയാക്റ്റിന്റെ തുടർച്ചയായ നവീകരണത്തിന്റെ ഒരു തെളിവായി നിലകൊള്ളുന്നു. ഇത് ആഗോളതലത്തിൽ ആപ്ലിക്കേഷനുകളുടെ സ്ഥിരതയെയും വിശ്വാസ്യതയെയും ബാധിക്കുന്ന ഒരു നിർണായക പ്രശ്നത്തെ - കോൺകറന്റ് റെൻഡറിംഗിലെ ടിയറിംഗ് - അഭിസംബോധന ചെയ്യുന്നു. എക്സ്റ്റേണൽ, മ്യൂട്ടബിൾ സ്റ്റോറുകളുമായി സിൻക്രൊണൈസ് ചെയ്യുന്നതിനായി ഒരു സമർപ്പിത, ലോ-ലെവൽ പ്രിമിറ്റീവ് നൽകുന്നതിലൂടെ, ഇത് ഡെവലപ്പർമാരെ കൂടുതൽ ശക്തവും പ്രകടനക്ഷമതയുള്ളതും ഭാവിക്ക് അനുയോജ്യവുമായ റിയാക്റ്റ് ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കാൻ പ്രാപ്തരാക്കുന്നു.

നിങ്ങൾ ഒരു ലെഗസി സിസ്റ്റവുമായി ഇടപെടുകയാണെങ്കിലും, ഒരു നോൺ-റിയാക്റ്റ് ലൈബ്രറി സംയോജിപ്പിക്കുകയാണെങ്കിലും, അല്ലെങ്കിൽ നിങ്ങളുടെ സ്വന്തം സ്റ്റേറ്റ് മാനേജ്‌മെന്റ് സൊല്യൂഷൻ ഉണ്ടാക്കുകയാണെങ്കിലും, `useSyncExternalStore` മനസ്സിലാക്കുകയും പ്രയോജനപ്പെടുത്തുകയും ചെയ്യേണ്ടത് നിർണായകമാണ്. ഇത് സ്ഥിരതയില്ലാത്ത സ്റ്റേറ്റിന്റെ വിഷ്വൽ തകരാറുകളിൽ നിന്ന് മുക്തമായ, തടസ്സമില്ലാത്തതും സ്ഥിരതയുള്ളതുമായ ഒരു ഉപയോക്തൃ അനുഭവം ഉറപ്പ് നൽകുന്നു, ലോകത്തിന്റെ എല്ലാ കോണുകളിൽ നിന്നുമുള്ള ഉപയോക്താക്കൾക്ക് ആക്‌സസ് ചെയ്യാവുന്ന അടുത്ത തലമുറയിലെ ഉയർന്ന ഇന്ററാക്ടീവും റെസ്പോൺസീവുമായ വെബ് ആപ്ലിക്കേഷനുകൾക്ക് വഴിയൊരുക്കുന്നു.

നിങ്ങളുടെ പ്രോജക്റ്റുകളിൽ `useSyncExternalStore` ഉപയോഗിച്ച് പരീക്ഷിക്കാനും അതിന്റെ സാധ്യതകൾ പര്യവേക്ഷണം ചെയ്യാനും റിയാക്റ്റ് സ്റ്റേറ്റ് മാനേജ്‌മെന്റിലെ മികച്ച രീതികളെക്കുറിച്ചുള്ള നിലവിലുള്ള ചർച്ചകളിൽ സംഭാവന നൽകാനും ഞങ്ങൾ നിങ്ങളെ പ്രോത്സാഹിപ്പിക്കുന്നു. കൂടുതൽ വിവരങ്ങൾക്ക്, എല്ലായ്പ്പോഴും ഔദ്യോഗിക റിയാക്റ്റ് ഡോക്യുമെന്റേഷൻ പരിശോധിക്കുക.