GraphQL Fragments: ഓരോ കമ്പോണന്റും അതിന്റെ ഡാറ്റ സ്വന്തമാക്കട്ടെ

GraphQL ക്വറികൾ (queries) തുടക്കത്തിൽ വളരെ ലളിതമായി തോന്നും. ഒരു റിക്വസ്റ്റിലൂടെ നിങ്ങൾക്ക് ആവശ്യമായ എല്ലാ ഡാറ്റയും ലഭിക്കുന്നു. എന്നാൽ നിങ്ങളുടെ ആപ്പ് വളരുന്നതിനനുസരിച്ച് കാര്യങ്ങൾ മാറുന്നു.

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

ഫ്രാഗ്മെന്റുകൾ (Fragments) ഈ പ്രശ്നം പരിഹരിക്കുന്നു. മിക്ക ടീമുകളും ഫീൽഡുകൾ കോപ്പി ചെയ്ത് പേസ്റ്റ് ചെയ്യാനുള്ള ഒരു മാർഗമായാണ് ഇവ ഉപയോഗിക്കുന്നത്. ഇത് തെറ്റായ രീതിയാണ്. കമ്പോണന്റ് ഓണർഷിപ്പിന്റെ (component ownership) ഒരു മാതൃകയായാണ് ഫ്രാഗ്മെന്റുകളെ കാണേണ്ടത്.

ഒരു പ്രത്യേക ടൈപ്പിന് (type) വേണ്ടി പേര് നൽകപ്പെട്ട ഫീൽഡുകളുടെ ഒരു കൂട്ടമാണ് ഫ്രാഗ്മെന്റ്.

ഉദാഹരണം:

fragment UserBadge on User {
  id
  name
  avatarUrl
}

ഒരു User ആവശ്യമായ ഏത് ക്വറിയിലേക്കും നിങ്ങൾക്ക് ഈ ഫ്രാഗ്മെന്റ് സ്പ്രെഡ് (spread) ചെയ്യാം.

നിങ്ങൾ ഫ്രാഗ്മെന്റ് എവിടെ സേവ് ചെയ്യുന്നു എന്നതിലാണ് ഇതിന്റെ യഥാർത്ഥ മൂല്യം ഇരിക്കുന്നത്. അവ ഒരു ഷെയർഡ് ഫയലിൽ (shared file) ഇടരുത്. പകരം, അത് ഉപയോഗിക്കുന്ന കമ്പോണന്റ് ഇരിക്കുന്ന അതേ ഫയലിൽ തന്നെ ഫ്രാഗ്മെന്റും വെക്കുക.

ഇതിനെയാണ് കോ-ലൊക്കേഷൻ (co-location) എന്ന് വിളിക്കുന്നത്. ഓരോ കമ്പോണന്റും അതിന്റെ ഡാറ്റാ ആവശ്യങ്ങൾ സ്വയം പ്രഖ്യാപിക്കുന്നു.

ഒരു കമ്പോണന്റിന് പുതിയൊരു ഫീൽഡ് ആവശ്യമായി വരുമ്പോൾ, നിങ്ങൾ അത് അതിന്റെ ഫ്രാഗ്മെന്റിൽ ചേർക്കുന്നു. അപ്പോൾ പാരന്റ് ക്വറി (parent query) തനിയെ അപ്‌ഡേറ്റ് ചെയ്യപ്പെടും. നിങ്ങൾ ഒരു കമ്പോണന്റ് നീക്കം ചെയ്യുമ്പോൾ അതിന്റെ ഫ്രാഗ്മെന്റും നീക്കം ചെയ്യുന്നു. അങ്ങനെ ക്വറി ചെറുതാകുന്നു. ചൈൽഡ് കമ്പോണന്റുകളുടെ ആന്തരിക ഫീൽഡുകളെക്കുറിച്ച് പാരന്റ് കമ്പോണന്റിന് അറിയേണ്ടതില്ല.

ഡാറ്റാ മാസ്കിംഗ് (Data masking) ഇത് കൂടുതൽ മെച്ചപ്പെടുത്തുന്നു. മാസ്കിംഗ് പ്രവർത്തനക്ഷമമാക്കിയാൽ, ഒരു കമ്പോണന്റിന് അതിന്റെ ഫ്രാഗ്മെന്റിൽ ആവശ്യപ്പെട്ട ഫീൽഡുകൾ മാത്രമേ കാണാൻ കഴിയൂ. സെർവർ അധിക ഡാറ്റ അയച്ചാൽ പോലും നിങ്ങളുടെ കമ്പോണന്റിന് അത് ഉപയോഗിക്കാൻ കഴിയില്ല.

ഇത് കൃത്യമായ ഒരു കരാർ (strict contract) സൃഷ്ടിക്കുന്നു.

  • ഓരോ കമ്പോണന്റിനും ഏത് ഡാറ്റയാണുള്ളതെന്ന് TypeScript-ന് കൃത്യമായി അറിയാം.
  • ഒരു ഫ്രാഗ്മെന്റിൽ നിന്ന് നിങ്ങൾ ഒരു ഫീൽഡ് നീക്കം ചെയ്താൽ, TypeScript എല്ലാ പിശകുകളും (errors) കാണിച്ചുതരും.
  • കോഡ്ബേസ് മുഴുവൻ തിരയുന്നതിന് പകരം, ഒരു സിമ്പിൾ ടൈപ്പ്-ചെക്ക് (type-check) വഴി റീഫാക്റ്ററിംഗ് (refactoring) എളുപ്പമാക്കാം.

താഴെ പറയുന്ന സാഹചര്യങ്ങളിൽ ഫ്രാഗ്മെന്റുകൾ ഉപയോഗിക്കുക:

  • User അല്ലെങ്കിൽ Product പോലുള്ള ഒരേ ടൈപ്പ് തന്നെ ഒന്നിലധികം കമ്പോണന്റുകൾ ഉപയോഗിക്കുമ്പോൾ.
  • നിങ്ങളുടെ പേജ് ക്വറികൾ വളരെ വലുതാകുമ്പോൾ.
  • ക്വറികളിൽ ഉപയോഗശൂന്യമായ ഫീൽഡുകൾ (dead fields) അറിയാതെ ബാക്കി നിൽക്കുമ്പോൾ.
  • നിങ്ങളുടെ ഡാറ്റയ്ക്ക് TypeScript സുരക്ഷ (safety) വേണമെന്ന് തോന്നുമ്പോൾ.

ചെറിയ രീതിയിൽ തുടങ്ങുക. ഒരു പാരന്റ് ക്വറിയിൽ നിന്ന് ഡാറ്റ സ്വീകരിക്കുന്ന ഒരു കമ്പോണന്റിനെ കണ്ടെത്തുക. അതിന്റെ ഫീൽഡുകൾ ഒരു ഫ്രാഗ്മെന്റിലേക്ക് മാറ്റുക. ആ ഫ്രാഗ്മെന്റ് കമ്പോണന്റ് ഫയലിൽ തന്നെ വെക്കുക.

ആപ്പ് വളരുന്നതിനനുസരിച്ച് നിങ്ങളുടെ ഡാറ്റാ ഫെച്ചിംഗും (data fetching) യുഐയും (UI) തമ്മിൽ പൊരുത്തപ്പെടുന്നുണ്ടെന്ന് ഫ്രാഗ്മെന്റുകൾ ഉറപ്പാക്കുന്നു.

Source: https://dev.to/grimicorn/graphql-fragments-let-each-component-own-its-data-5359