GraphQL Fragments: תנו לכל רכיב להיות הבעלים של הנתונים שלו
שאילתות GraphQL נראות נקיות בהתחלה. בקשה אחת מביאה את כל הנתונים שלכם. ואז האפליקציה שלכם גדלה.
שאילתת הדף שלכם מתחילה לאסוף שדות עבור רכיבי בן (child components) רבים ושונים. אתם מוסיפים שדה עבור רכיב חדש. שישה שבועות לאחר מכן אתם מוחקים את הרכיב הזה. אתם שוכחים להסיר את השדה מהשאילתה הראשית. עכשיו אף אחד לא יודע אם בטוח למחוק אותו. השאילתה גדלה ללא סוף.
Fragments פותרים את זה. רוב הצוותים משתמשים בהם כדרך להעתקה והדבקה של שדות. זו הדרך הלא נכונה. Fragments צריכים להיות מודל לבעלות של רכיבים (component ownership).
Fragment הוא קבוצה בשם של שדות עבור type ספציפי.
Example: fragment UserBadge on User { id name avatarUrl }
אתם פורסים (spread) את ה-fragment הזה לתוך כל שאילתה שזקוקה ל-User.
הערך האמיתי מגיע מהמקום שבו אתם שומרים את ה-fragment. אל תשימו אותם בקובץ משותף. שימו את ה-fragment באותו קובץ שבו נמצא הרכיב שמשתמש בו.
זה נקרא co-location. כל רכיב מצהיר על צרכי הנתונים שלו.
כשרכיב זקוק לשדה חדש, אתם מוסיפים אותו ל-fragment שלו. שאילתת האב מתעדכנת אוטומטית. כשאתם מוחקים רכיב, אתם מוחקים את ה-fragment שלו. השאילתה מצטמצמת. רכיב האב לא צריך להכיר את השדות הפנימיים של רכיבי הבן שלו.
Data masking הופך את זה לעוד יותר טוב. כאשר masking מופעל, רכיב רואה רק את השדות שהוא ביקש ב-fragment שלו. גם אם השרת שולח נתונים נוספים, הרכיב שלכם לא יכול לגשת אליהם.
זה יוצר חוזה (contract) קשיח.
- TypeScript יודע בדיוק אילו נתונים יש לכל רכיב.
- אם תסירו שדה מ-fragment, TypeScript יציג לכם כל שגיאה.
- Refactoring הופך לבדיקת טיפוסים (type-check) פשוטה במקום חיפוש בכל בסיס הקוד שלכם.
השתמשו ב-fragments כאשר:
- מספר רכיבים משתמשים באותו type כמו User או Product.
- שאילתות הדף שלכם ארוכות מדי.
- אתם משאירים בטעות שדות מתים בשאילתות שלכם.
- אתם רוצים בטיחות של TypeScript עבור הנתונים שלכם.
התחילו בקטן. מצאו רכיב אחד שמקבל נתונים משאילתת אב. העבירו את השדות שלו לתוך fragment. שימו את ה-fragment הזה בקובץ של הרכיב.
Fragments מבטיחים ששליפת הנתונים שלכם תתאים ל-UI שלכם ככל שהאפליקציה גדלה.
Source: https://dev.to/grimicorn/graphql-fragments-let-each-component-own-its-data-5359