GraphQL Fragments: ہر Component کو اس کے ڈیٹا کا مالک بنائیں

GraphQL queries شروع میں صاف ستھری نظر آتی ہیں۔ ایک ہی ریکویسٹ سے آپ کا سارا ڈیٹا مل جاتا ہے۔ پھر جیسے جیسے آپ کی ایپ بڑھتی ہے...

آپ کی پیج کوئری (page query) بہت سے مختلف چائلڈ کمپوننٹس (child components) کے لیے فیلڈز جمع کرنے لگتی ہے۔ آپ ایک نئے کمپوننٹ کے لیے ایک فیلڈ شامل کرتے ہیں۔ چھ ہفتے بعد آپ اس کمپوننٹ کو ڈیلیٹ کر دیتے ہیں۔ آپ مین کوئری سے اس فیلڈ کو ہٹانا بھول جاتے ہیں۔ اب کسی کو معلوم نہیں ہوتا کہ کیا اسے ڈیلیٹ کرنا محفوظ ہے۔ کوئری ہمیشہ کے لیے بڑھتی جاتی ہے۔

Fragments اس مسئلے کو حل کرتے ہیں۔ زیادہ تر ٹیمیں انہیں فیلڈز کو کاپی اور پیسٹ کرنے کے طریقے کے طور پر استعمال کرتی ہیں۔ یہ غلط طریقہ ہے۔ Fragments کو کمپوننٹ کی ملکیت (ownership) کے ماڈل کے طور پر استعمال ہونا چاہیے۔

ایک fragment کسی مخصوص type کے لیے فیلڈز کا ایک نام شدہ گروپ ہوتا ہے۔

مثال:

fragment UserBadge on User {
  id
  name
  avatarUrl
}

آپ اس fragment کو کسی بھی ایسی کوئری میں spread کرتے ہیں جسے User کی ضرورت ہو۔

اصل اہمیت اس بات سے آتی ہے کہ آپ fragment کو کہاں محفوظ کرتے ہیں۔ انہیں کسی مشترکہ (shared) فائل میں نہ رکھیں۔ Fragment کو اسی فائل میں رکھیں جس میں وہ component موجود ہے جو اسے استعمال کرتا ہے۔

اسے co-location کہا جاتا ہے۔ ہر component اپنی ڈیٹا کی ضروریات خود بیان کرتا ہے۔

جب کسی component کو ایک نئی فیلڈ کی ضرورت ہوتی ہے، تو آپ اسے اس کے fragment میں شامل کر دیتے ہیں۔ Parent query خود بخود اپ ڈیٹ ہو جاتی ہے۔ جب آپ کسی component کو ڈیلیٹ کرتے ہیں، تو آپ اس کا fragment بھی ڈیلیٹ کر دیتے ہیں۔ کوئری چھوٹی ہو جاتی ہے۔ Parent component کو اپنے بچوں (children) کی اندرونی فیلڈز کے بارے میں جاننے کی ضرورت نہیں ہوتی۔

Data masking اسے مزید بہتر بنا دیتی ہے۔ Masking فعال ہونے کے ساتھ، ایک component صرف وہی فیلڈز دیکھ سکتا ہے جن کے لیے اس نے اپنے fragment میں درخواست کی تھی۔ اگر سرور اضافی ڈیٹا بھی بھیجتا ہے، تب بھی آپ کا component اسے حاصل نہیں کر سکتا۔

یہ ایک سخت معاہدہ (strict contract) تخلیق کرتا ہے۔

• TypeScript کو بالکل معلوم ہوتا ہے کہ ہر component کے پاس کون سا ڈیٹا ہے۔
• اگر آپ کسی fragment سے کوئی فیلڈ ہٹاتے ہیں، تو TypeScript آپ کو ہر غلطی (error) دکھاتا ہے۔
• Refactoring پورے codebase میں تلاش کرنے کے بجائے محض ایک سادہ type-check بن جاتی ہے۔

Fragments کا استعمال تب کریں جب:

• متعدد components ایک ہی type جیسے User یا Product استعمال کرتے ہوں۔
• آپ کی پیج کوئریز بہت لمبی ہو رہی ہوں۔
• آپ غلطی سے اپنی کوئریز میں غیر ضروری (dead) فیلڈز چھوڑ دیتے ہیں۔
• آپ اپنے ڈیٹا کے لیے TypeScript safety چاہتے ہوں۔

چھوٹی شروعات کریں۔ کوئی ایسا component تلاش کریں جو parent query سے ڈیٹا حاصل کرتا ہو۔ اس کی فیلڈز کو ایک fragment میں منتقل کریں۔ اس fragment کو component فائل میں رکھیں۔

Fragments اس بات کو یقینی بناتے ہیں کہ جیسے جیسے آپ کی ایپ بڑھتی ہے، آپ کا data fetching آپ کے UI کے مطابق رہے۔

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